ต่อไปนี้เป็นการรวบรวมผลลัพธ์ที่ฉันอ่าน คุณจะพบข้อมูลเพิ่มเติมอย่างมากมายในบล็อกและเอกสารที่เชื่อมโยง
ประการแรกมันสามารถเกิดขึ้นได้ DBCC CHECKDBจะไม่ตรวจพบความไม่สอดคล้องกันหากคุณปิดการตรวจสอบการตรวจสอบหรือการตรวจสอบ torn_page คำพูดจาก Paul Randal ในโพสต์นี้ :
คุณพูดถูก - หากไม่ได้เปิดใช้งานหน้าเช็คหรือเช็คซัมไม่มีอะไรที่สามารถตรวจพบได้เท่าที่มีตัวเลือกในการป้องกันหน้าอยู่ CHECKDB อาจยังคงรับความเสียหายที่พบจากการตรวจสอบความสอดคล้องทั้งหมดที่ทำ - แต่จะไม่เห็นความเสียหายในค่ากลางของข้อมูลตัวอย่างเช่น
ฮะ - นั่นเป็นสิ่งที่คนเกียจคร้านเกี่ยวกับการเปิดการตรวจสอบหน้า - ไม่มีอะไรเกิดขึ้นจนกว่าจะมีการอ่านหน้าเปลี่ยนและเขียน วิธีเดียวที่จะบังคับให้หน้าเว็บเพื่อรับ checksum คือการทำให้หน้าเปลี่ยนแปลง - เช่นการสร้างดัชนีทั้งหมดของคุณใหม่ซึ่งอาจไม่ปลอดภัย - ไม่มีเครื่องมือ 'สัมผัส' เลย
สถานการณ์ข้างต้นอาจทำให้คุณพลาดหากคุณอัปเกรดฐานข้อมูลจาก SQL Server 2000 หรือก่อนหน้าเป็น 2005 หรือใหม่กว่า จากนั้นคุณต้องเปิดใช้งานการตรวจสอบหน้าด้วยตนเองด้วยการเปลี่ยนแปลงฐานข้อมูลเพื่อให้พวกเขาใช้งานได้ แต่จากนั้นย่อหน้าที่ 2 ของข้อความที่กล่าวมาจะทำให้คุณเดือดร้อน
BACKUP WITH CHECKSUMจะตรวจสอบความไม่สอดคล้องกันของ checksum แต่เฉพาะในกรณีที่หน้านั้นมีการตรวจสอบการเขียนไปแล้วเมื่อมีการสำรองข้อมูล โดยปกติDBCC CHECKDBจะตรวจพบข้อผิดพลาดเหล่านี้ด้วยไม่ใช่ความคิดที่ดีที่จะใช้การสำรองข้อมูลด้วย CHECKSUM เพื่อแทนที่ DBCC CHECKDB
ขณะนี้มีความเป็นไปได้ที่สองที่จะDBCC CHECKDBไม่แสดงความไม่สอดคล้องกันแม้ว่าจะมีบางอย่างก็ตาม สำหรับเรื่องนี้ฉันแค่อ้างอีกครั้ง Paul Randal ในความเข้าใจผิดเกี่ยวกับการทุจริต: พวกเขาจะหายไป?:
แล้วการคอร์รัปชั่นที่หายไปจะเป็นอย่างไร? นี่เป็นการตรวจสอบความสอดคล้องของการทำงาน การตรวจสอบความสอดคล้องจะเรียกใช้บนหน้าต่างๆในฐานข้อมูลที่ได้รับการจัดสรรเท่านั้น หากเพจไม่ได้ถูกจัดสรรให้กับสิ่งใด ๆ เลยไบต์ 8192 นั้นจะไม่มีความหมายและไม่สามารถตีความได้ อย่าสับสนระหว่างการจองและการจัดสรร - ฉันอธิบายว่าในการโพสต์ความเข้าใจผิดครั้งแรกที่นี่ ตราบเท่าที่มีการจัดสรรหน้ามันจะถูกตรวจสอบความสอดคล้องโดย DBCC CHECKDB รวมถึงการทดสอบการตรวจสอบหน้าถ้ามันมีอยู่ ความเสียหายดูเหมือนจะ 'หายไป' หากเพจที่เสียหายได้รับการจัดสรรในเวลาที่ DBCC CHECKDB ทำงาน แต่จะถูกจัดสรรคืนเมื่อเวลาที่ DBCC CHECKDB ถัดไปทำงาน ครั้งแรกมันจะถูกรายงานว่าเสียหาย แต่ครั้งที่สองมันไม่ได้ถูกจัดสรรดังนั้นจึงไม่ได้รับการตรวจสอบอย่างสม่ำเสมอและจะไม่ถูกรายงานว่าเสียหาย การทุจริตดูเหมือนว่าจะหายไปอย่างลึกลับ แต่มันไม่ใช่ - มันเป็นแค่หน้าเสียหายที่ไม่ได้รับการจัดสรรอีกต่อไป ไม่มีสิ่งใดที่จะหยุดการทำงานของ SQL Server เพื่อยกเลิกการจัดสรรหน้าเสียหาย - อันที่จริงนั่นคือสิ่งที่ DBCC CHECKDB ซ่อมทำ - ทำการจัดสรรคืนสิ่งที่เสียหายและแก้ไขการเชื่อมโยงทั้งหมด
ฉันไม่มีคำตอบสุดท้ายสำหรับคำถามของคุณ แต่เป็นDBCC CHECKDBเพียงการตรวจสอบหน้าที่จัดสรรเท่านั้นมันจะไม่แสดงความไม่สอดคล้องกันในหน้าที่จัดสรรคืน สถานการณ์เดียวที่ฉันสามารถคิดตอนนี้คือการสำรองข้อมูลสำรองข้อมูลหน้า deallocated DBCC CHECKDBผู้แสดงข้อผิดพลาดที่อาจเกิดขึ้นการตรวจสอบที่ถูกข้ามไปโดย