(เดิมทีโพสต์บน DBA.StackExchange.com แต่ปิดไปแล้ว หวังว่าจะมีความเกี่ยวข้องมากกว่านี้)
Alexander and the Terrible, Horrible, ไม่ดี, แย่มาก ... ข้อมูลสำรอง
ฉันมีในสถานที่ SQL Server 2016 รุ่นมาตรฐาน อินสแตนซ์ที่ทำงานบน a เครื่องเสมือน จาก VMWare
@@เวอร์ชั่น:
Microsoft SQL Server 2016 (SP2-CU17) (KB5001092) - 13.0.5888.11 (X64) 19 มีนาคม 2021 19:41:38 ลิขสิทธิ์ (c) Microsoft Corporation Standard รุ่น (64 บิต) บน Windows Server 2016 Datacenter 10.0 (รุ่น 14393: ) (ไฮเปอร์ไวเซอร์)
ขณะนี้มีการจัดสรรเซิร์ฟเวอร์เอง 8 โปรเซสเซอร์เสมือน, มี หน่วยความจำ 32 GB, และทั้งหมด ดิสก์เป็น NVMe ซึ่งได้รับรอบ I/O 1 GB/วินาที. ฐานข้อมูลนั้นอยู่บนไดรฟ์ G: และข้อมูลสำรองจะถูกจัดเก็บไว้ในไดรฟ์ P: แยกต่างหาก ขนาดรวมของฐานข้อมูลทั้งหมดคือประมาณ 500 GB (ก่อนที่จะถูกบีบอัดลงในไฟล์สำรอง)
แผนการบำรุงรักษาจะทำงานคืนละครั้ง (ประมาณ 22:30 น.) เพื่อสำรองข้อมูลทั้งหมดบนทุกฐานข้อมูลบนเซิร์ฟเวอร์ ไม่มีสิ่งอื่นใดที่ผิดปกติกำลังทำงานบนเซิร์ฟเวอร์ และไม่มีอะไรอื่นที่กำลังทำงานอยู่ในขณะนั้นโดยเฉพาะ แผนการใช้พลังงานปิดเซิร์ฟเวอร์ถูกตั้งค่าเป็น "สมดุล" (และ "ปิดฮาร์ดดิสก์หลังจาก" ถูกตั้งค่าเป็น 0 นาทีหรือที่เรียกว่าไม่เคยปิดเลย)
สำหรับปีที่ผ่านมา รันไทม์ทั้งหมดสำหรับงานแผนการบำรุงรักษาใช้เวลาประมาณ 15 นาที รวมให้เสร็จสมบูรณ์ ตั้งแต่สัปดาห์ที่แล้ว มันพุ่งสูงขึ้นถึง 40x ยาวประมาณ 15 ชั่วโมง ทำให้สำเร็จ.
สิ่งเดียวที่ฉันทราบเกี่ยวกับการเปลี่ยนแปลงในวันเดียวกับที่แผนการบำรุงรักษาช้าลงคือการอัปเดต Windows ต่อไปนี้ได้รับการติดตั้งในเครื่องก่อนที่แผนการบำรุงรักษาจะทำงาน:
นอกจากนี้ เรายังมีอินสแตนซ์ SQL Server ที่เตรียมใช้งานในทำนองเดียวกันบน VM อื่นซึ่งผ่านการอัปเดต Windows เดียวกัน จากนั้นจึงพบการสำรองข้อมูลที่ช้าลงเช่นกันหลังจากนั้น เมื่อคิดว่าการอัปเดต Windows เป็นสาเหตุโดยตรง เราจึงยกเลิกการอัปเดตทั้งหมด และแผนการบำรุงรักษาการสำรองข้อมูลยังคงทำงานช้ามากอยู่ดี น่าแปลกที่การกู้คืนข้อมูลสำรองสำหรับฐานข้อมูลหนึ่งๆ เกิดขึ้นอย่างรวดเร็ว และใช้ I/O เกือบเต็ม 1 GB/วินาทีบน NVMe
เมื่อใช้ sp_whoisactive ของ Adam Mechanic ฉันได้ระบุว่า Last Wait Types ของกระบวนการสำรองข้อมูลมักจะบ่งบอกถึงปัญหาประสิทธิภาพของดิสก์ฉันมักจะเห็น แบ็คอัพบัฟเฟอร์ และ แบ็คอัพ ประเภทรอนอกเหนือจาก ASYNC_IO_COMPLETION:
เมื่อดูที่ตัวตรวจสอบทรัพยากรบนเซิร์ฟเวอร์เอง ในระหว่างการสำรองข้อมูล ส่วนดิสก์ I/O แสดงให้เห็นว่า I/O ทั้งหมดที่ใช้อยู่ประมาณ 14 MB/วินาทีเท่านั้น (ส่วนใหญ่ที่ฉันเคยเจอตั้งแต่เกิดปัญหานี้คือ 30 เมกะไบต์/วินาที):
หลังจากสะดุดกับสิ่งนี้ที่เป็นประโยชน์ บทความ Brent Ozar เกี่ยวกับการใช้ DiskSpdฉันลองรันด้วยตัวเองภายใต้พารามิเตอร์ที่คล้ายกัน (ลดจำนวนเธรดลงเหลือ 8 เท่านั้น เนื่องจากฉันมีตัวประมวลผลเสมือน 8 ตัวบนเซิร์ฟเวอร์และตั้งค่าการเขียนเป็น 50%) นี่คือคำสั่งที่แน่นอน diskspd.exe -b2M -d60 -o32 -h -L -t8 -W -w50 "C:\Users\...\Desktop\Microsoft DiskSpd\Test\LargeFile.txt". ฉันใช้ไฟล์ข้อความที่ฉันสร้างขึ้นเองซึ่งมีขนาดไม่เกิน 1 GB ฉันเชื่อว่า I/O ที่วัดได้ดูเหมือนจะใช้ได้ แต่เวลาแฝงของดิสก์แสดงตัวเลขที่น่าหัวเราะ:
ผลลัพธ์ของ DiskSpd นั้นดูเหลือเชื่อจริงๆ หลังจากอ่านเพิ่มเติม ฉันพบข้อความค้นหาจาก Paul Randall ที่ส่งคืนเมตริกเวลาแฝงของดิสก์ต่อฐานข้อมูล นี่คือผลลัพธ์:
เวลาแฝงในการเขียนที่แย่ที่สุดคือ 63 มิลลิวินาที และเวลาแฝงในการอ่านที่แย่ที่สุดคือ 6 มิลลิวินาที ซึ่งดูเหมือนว่าจะแตกต่างจาก DiskSpd อย่างมาก และดูไม่น่ากลัวพอที่จะเป็นสาเหตุของปัญหาของฉัน จากการตรวจสอบเพิ่มเติม ฉันใช้ตัวนับ PerfMon สองสามตัวบนเซิร์ฟเวอร์เอง ต่อ บทความนี้ของ Microsoftและนี่คือผลลัพธ์:
ไม่มีอะไรพิเศษที่นี่ ค่าสูงสุดของตัวนับทั้งหมดที่ฉันวัดได้คือ 0.007 (ซึ่งฉันเชื่อว่าเป็นมิลลิวินาที?) สุดท้าย ฉันให้ทีมโครงสร้างพื้นฐานตรวจสอบเมตริกเวลาแฝงของดิสก์ที่ VMWare กำลังบันทึกระหว่างงานสำรองข้อมูล และนี่คือผลลัพธ์:
ดูเหมือนว่าที่เลวร้ายที่สุดคือมีเวลาแฝงเพิ่มขึ้นประมาณ 200 มิลลิวินาทีประมาณเที่ยงคืน และ I/O สูงสุดคือ 600 KB/วินาที (ซึ่งฉันไม่เข้าใจจริงๆ เนื่องจากตัวตรวจสอบทรัพยากรแสดงว่าการสำรองข้อมูลอย่างน้อยใช้ ประมาณ 14 MB/วินาที ของ I/O)
ฉันเพิ่งลองกู้คืนหนึ่งในฐานข้อมูลที่ใหญ่กว่า (ประมาณ 250 GB) และใช้เวลาทั้งหมดประมาณ 8 นาทีในการกู้คืน จากนั้นฉันก็พยายามวิ่ง DBCC CHECKDB และใช้เวลาทั้งหมด 16 นาทีในการรัน (ไม่แน่ใจว่าเป็นเรื่องปกติหรือไม่) แต่ Resource Monitor แสดงปัญหา I/O ที่คล้ายกัน (I/O สูงสุดที่เคยใช้คือ 100 MB/s) โดยไม่มีอะไรทำงาน:
นี่คือ sp_whoisactive ผลลัพธ์เมื่อฉันวิ่งครั้งแรก DBCC CHECKDB และหลังจากเสร็จสิ้น 5% ให้สังเกตว่าเวลาที่เหลือโดยประมาณเพิ่มขึ้นประมาณ 5 นาทีแม้ว่าจะทำไปแล้ว 5% ก็ตาม
เริ่ม:
เสร็จ 5%:
ฉันเดาว่านี่เป็นเรื่องปกติโดยเป็นเพียงการประมาณการ และ 16 นาทีก็ดูไม่เลวสำหรับฐานข้อมูลขนาด 250 GB (แม้ว่าฉันจะไม่แน่ใจว่าเป็นเรื่องปกติหรือไม่) แต่อีกครั้ง I/O กำลังสูงสุดที่ ประมาณ 10% ของความสามารถของไดรฟ์ โดยไม่มีอะไรทำงานบนเซิร์ฟเวอร์หรืออินสแตนซ์ SQL
นี่คือผลลัพธ์ ของ DBCC CHECKDBไม่มีรายงานข้อผิดพลาด
ฉันยังประสบปัญหาความเชื่องช้าแปลกๆ กับ หด สั่งการ. ฉันแค่พยายามที่จะ หด ฐานข้อมูลที่มีพื้นที่ 5% ที่จะปล่อย (ประมาณ 14 GB) ใช้เวลาเพียงประมาณ 1 นาทีก็เสร็จ 90% ของทั้งหมด หด:
ประมาณ 5 นาทีต่อมา และยังคงติดอยู่ที่เปอร์เซ็นต์เดิมที่เสร็จสมบูรณ์ และการสำรองข้อมูลบันทึกธุรกรรมของฉัน (ซึ่งมักจะเสร็จใน 1-2 วินาที) อยู่ภายใต้การโต้แย้งเป็นเวลาประมาณ 30 วินาที:
15 นาทีต่อมาและ หด เสร็จสิ้นในขณะที่การสำรองข้อมูลบันทึกธุรกรรมยังอยู่ภายใต้การโต้แย้งประมาณ 6 นาทีในขณะนี้ และเสร็จสมบูรณ์เพียง 50% ฉันเชื่อว่าพวกเขาทำเสร็จทันทีหลังจากนั้นตั้งแต่ หด เสร็จ. ตลอดเวลาที่ Resource Monitor แสดง I/O ที่ยังดูดอยู่:
จากนั้นฉันได้รับข้อผิดพลาดกับ หด คำสั่งเมื่อเสร็จสิ้น:
ฉันลองใหม่ หด อีกครั้งและส่งผลให้ผลลัพธ์เหมือนกันทุกประการกับข้างต้น
จากนั้นฉันลองเขียนสคริปต์การสำรองข้อมูล T-SQL ไปยังไฟล์บนไดรฟ์ P: ด้วยตนเอง และนั่นทำงานช้าเช่นเดียวกับงานสำรองแผนการบำรุงรักษา:
ฉันลงเอยด้วยการยกเลิกหลังจากนั้นประมาณ 3 นาที และมันก็ย้อนกลับทันที
บังเอิญ งานแผนการบำรุงรักษาการสำรองข้อมูลทำงานช้าลงประมาณ 40 เท่า (จาก 15 นาทีเป็น 15 ชั่วโมง) ทุกคืน ทันทีหลังจากติดตั้งการอัปเดต Windows การย้อนกลับการอัปเดต Windows เหล่านั้นไม่สามารถแก้ไขปัญหาได้ SQL Server Wait Types, Resource Monitor และ Microsoft DiskSpd บ่งชี้ถึงปัญหาของดิสก์ (โดยเฉพาะ I/O) แต่การวัดอื่นๆ ทั้งหมดจากการสืบค้นของ Paul Randall, PerfMon และ VMWare Logs ไม่ได้รายงานปัญหาใดๆ กับดิสก์ การกู้คืนข้อมูลสำรองสำหรับฐานข้อมูลใดฐานข้อมูลหนึ่งทำได้อย่างรวดเร็ว และใช้ I/O เกือบเต็ม 1 GB/วินาที ผมเกาหัว...
ในกรณีนี้ เรามีปัญหาเกี่ยวกับดิสก์จริงๆ และไม่ใช่ปัญหาภายใน SQL Server สำหรับ VM นี้โดยเฉพาะ จริงๆแล้วมันจบลงด้วยการเป็นกรณีบั๊กที่เราพบเจอกับ Veeam และ VMWare
เพื่อสรุปความเข้าใจของฉันเกี่ยวกับสิ่งที่เกิดขึ้น เห็นได้ชัดว่าการสำรองข้อมูล Veeam ของเราไม่ได้รับการยอมรับว่าเสร็จสมบูรณ์โดย VMWare ดังนั้น ทุกวันเมื่อถึงเวลาต้องสำรองข้อมูลเซิร์ฟเวอร์ VMWare จึงสั่งให้ Veeam สำรองข้อมูลใหม่เมื่อวันก่อน ซึ่งกลายเป็นปัญหาที่เพิ่มขึ้นสะสมในช่วงสองสัปดาห์ (ฉันแน่ใจว่าฉันฆ่าคำอธิบายนั้น แต่นั่นก็เพียงพอแล้วสำหรับสิ่งที่ฉันรู้)
Veeam / VMWare ต้องลบไฟล์สแน็ปช็อตแต่ละไฟล์ ซึ่งไฟล์ของแต่ละวันมีขนาดใหญ่กว่าไฟล์ก่อนหน้า ดังนั้นการสนับสนุนระดับ 3 จึงใช้เวลาประมาณ 26 ชั่วโมงจึงจะเสร็จสิ้น หลังจากนั้น VM ก็ทำงานได้ดีอีกครั้ง เห็นได้ชัดว่านี่ไม่ใช่ปัญหาทั่วไปตามการสนับสนุนทางเทคนิคของพวกเขา
ขออภัย นี่เป็นปัญหาที่เฉพาะเจาะจงมาก และอาจช่วยอะไรคนอื่นๆ ไม่ได้มากนัก แต่หวังว่าจะช่วยได้
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
