DBCC CHECKDB มีความสำคัญสำหรับฐานข้อมูล SQL Server ที่จะแน่ใจ 100% ว่าไม่มีความเสียหาย อย่างไรก็ตามเนื่องจากฐานข้อมูลมีขนาดใหญ่ขึ้นเรื่อย ๆ เป็นเรื่องยากมากที่จะพบหน้าต่างการบำรุงรักษาเมื่อคุณอ้างว่า 24x7 ขึ้นไป ในช่วงหลายปีที่ผ่านมาทีม SQL Server ได้ใช้กลไกต่าง ๆ ที่จะตรวจจับความเสียหายในรูปแบบที่พบบ่อยที่สุดโดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับความเสียหายทางกายภาพที่เกิดจากฮาร์ดแวร์
SQL Server 2005 และใหม่กว่ามีPAGE_VERIFY = CHECKSUMซึ่งสามารถช่วยคุณตรวจสอบความเสียหายทางกายภาพในหน้าฐานข้อมูลซึ่งจะเป็นการเพิ่มการตรวจสอบในแต่ละหน้าตามที่เขียนไปยังระบบ I / O และตรวจสอบการตรวจสอบตามที่อ่านจากดิสก์
นอกจากนี้การสำรองข้อมูล (เต็มหรือส่วนต่าง) ด้วย CHECKSUMจะรับประกันในการตรวจสอบความเสียหายของ I / O ที่เกิดจากฮาร์ดแวร์
ดังนั้นจากด้านฮาร์ดแวร์ของความเสียหาย SQL Server ทำงานได้ดีในการตรวจจับและรายงาน (ตรวจสอบให้แน่ใจว่าได้ตั้งค่าการแจ้งเตือนความเสียหายที่สำคัญเช่นกัน)
ที่ถูกกล่าวว่ายังคงเสียหายตรรกะ , ข้อผิดพลาด Scribbler เหนี่ยวนำ - ที่ในหน่วยความจำหน้าจะเสียหายอย่างใดอย่างหนึ่งตามรหัสของบุคคลที่สามที่ทำงานภายในกระบวนการ SQL Server หรือโดยไดรเวอร์หรือซอฟต์แวร์อื่น ๆ ที่มีสิทธิ์เพียงพอที่รันในโหมดเคอร์เนลของ Windows และ / หรือSQL Server ข้อบกพร่องฯลฯ ไม่สามารถตรวจจับได้โดยใช้วิธีการด้านบนและด้วยเหตุนี้CHECKDBจึงเข้ามาในรูปภาพ
DBCC CHECKDB ทำการตรวจสอบอย่างละเอียดยิ่งขึ้นซึ่งรวมถึงการตรวจสอบส่วนหัวของหน้าสำหรับความเสียหายที่อาจเกิดขึ้นซึ่งไม่สามารถตรวจพบได้ด้วยวิธีการอื่น
สคริปต์ที่มีอยู่ออกมี?
ฉันขอแนะนำให้คุณลองดูวิธีการตรวจสอบความถูกต้องสมบูรณ์ของเซิร์ฟเวอร์ SQL ของ Ola
รัน DBCC CHECKDB อย่างมีประสิทธิภาพ:
คุณต้องสร้างสรรค์เมื่อคุณเข้มงวดในการบำรุงรักษาโดยมีฐานข้อมูลขนาดใหญ่หรือมีฐานข้อมูลจำนวนมากเพื่อเปิดใช้งาน CHECKDB
หลังจากเข้าร่วมการฝึกอบรม SQLSkills สิ่งที่ฉันได้นำไปใช้ในสภาพแวดล้อมของฉันคือ:
- จัดลำดับความสำคัญกับสิ่งที่ตารางมีความสำคัญต่อการตรวจสอบ
- แยกตารางออกเป็นกลุ่มที่มีลำดับความสำคัญต่างกันจากนั้นเรียกใช้
DBCC CHECKTABLEพร้อมกับการรันDBCC CHECKALLOCและDBCC CHECKCATALOG
- สร้างตารางผู้ปฏิบัติงานที่จะจัดเก็บชื่อตารางด้วยลำดับความสำคัญ เพียงตรวจสอบให้แน่ใจว่าตารางลำดับความสำคัญสูงทั้งหมด (ซึ่งมีขนาดใหญ่มาก) ไม่ได้อยู่ในกลุ่มเดียว CHECKDB ของคุณจะไม่สมบูรณ์เลย
- คุณยังสามารถมีคอลัมน์ไทม์เอาต์ในตารางงานของคุณที่จะประสานเมื่อ CHECKDB ของคุณจะถูกฆ่าเมื่อมันผ่านหน้าต่างการบำรุงรักษา
- เพิ่มนานเท่าใดจึงต่อตารางการทำงาน
DBCC CHECKTABLE, และDBCC CHECKALLOC DBCC CHECKCATALOGเพื่อให้คุณสามารถรับความรู้สึกอยู่กับระยะเวลามันจะมักจะพาสำหรับการตรวจสอบการทำงานของคุณไป
- คุณสามารถเรียกใช้
NOINDEXตัวเลือกได้เพราะจะทำให้การดำเนินการเร็วขึ้นเนื่องจากไม่ได้ตรวจสอบดัชนีที่ไม่เป็นคลัสเตอร์บนตารางผู้ใช้ สิ่งนี้มีข้อได้เปรียบเนื่องจากไม่สำคัญเท่ากับความเสียหายของข้อมูลเนื่องจากไม่มีข้อมูลสูญหายและคุณสามารถปล่อยและสร้างดัชนีใหม่หากจำเป็น
เห็นได้ชัดว่ารุ่น Enterprise สามารถใช้ประโยชน์จากการประมวลผลคำสั่ง DBCC แบบขนาน แต่ระวังการตั้งค่า MAXDOP เนื่องจากอาจทำให้ CPU ของคุณหมด สิ่งนี้อาจถูก จำกัด อย่างหนักโดยผู้ว่าการทรัพยากร
หมายเหตุ:หากคุณมีคอลัมน์เบาบางแล้ว CHECKDB ของคุณจะตายช้าตามที่อธิบายไว้ที่นี่
ในที่สุดวิธีการป้องกันความเสียหายของฐานข้อมูลโดยใช้ชุดเครื่องมือที่มีอยู่ทั้งหมด + ความเชื่อมั่นในระบบฮาร์ดแวร์เซิร์ฟเวอร์ฐานข้อมูลของคุณและที่สำคัญที่สุดคือคุณค่าของข้อมูลของคุณ
บางแหล่งอ้างอิงที่ยอดเยี่ยม: