คำถามติดแท็ก dbcc-checkdb

1
การเสียหายของดัชนีเชิงพื้นที่ที่ไม่สามารถแก้ไขได้ถือว่าเป็นเรื่องปกติหรือไม่
ฉันมีดัชนีเชิงพื้นที่ซึ่งDBCC CHECKDBรายงานความเสียหาย: DBCC CHECKDB(MyDB) WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS ดัชนีเชิงพื้นที่ดัชนี XML หรือมุมมองที่จัดทำดัชนี 'sys.extended_index_xxx_384000' (ID วัตถุ xxx) ไม่มีแถวทั้งหมดที่นิยามมุมมองสร้างขึ้น สิ่งนี้ไม่จำเป็นต้องแสดงถึงปัญหาด้านความสมบูรณ์ของข้อมูลในฐานข้อมูลนี้ ดัชนีปริภูมิดัชนี XML หรือมุมมองที่จัดทำดัชนี 'sys.extended_index_xxx_384000' (ID อ็อบเจ็กต์ xxx) มีแถวที่ไม่ได้สร้างขึ้นโดยการกำหนดมุมมอง สิ่งนี้ไม่จำเป็นต้องแสดงถึงปัญหาด้านความสมบูรณ์ของข้อมูลในฐานข้อมูลนี้ CHECKDB พบข้อผิดพลาดในการจัดสรร 0 ข้อและข้อผิดพลาดที่สอดคล้องกัน 2 ข้อในตาราง 'sys.extended_index_xxx_384000' (รหัสวัตถุ xxx) repair_rebuildระดับการซ่อมเป็น การปล่อยและสร้างดัชนีใหม่จะไม่ลบรายงานความเสียหายเหล่านี้ หากไม่มีEXTENDED_LOGICAL_CHECKSแต่ด้วยDATA_PURITYข้อผิดพลาดจะไม่ถูกรายงาน นอกจากนี้CHECKTABLEใช้เวลา 45 นาทีสำหรับตารางนี้แม้ว่า CI ของมันจะมีขนาด 30 MB และมีแถวประมาณ 30k ข้อมูลทั้งหมดในตารางนั้นเป็นgeographyข้อมูลจุด …

2
สร้างบันทึกการทำธุรกรรมขึ้นใหม่
เรามีฐานข้อมูลขนาดใหญ่มาก (~ 6TB) ซึ่งไฟล์บันทึกธุรกรรมถูกลบ (ในขณะที่ SQL Server ปิดตัวลงเราได้ลอง: การถอดและติดตั้งฐานข้อมูลอีกครั้ง และ การยกเลิกการลบไฟล์บันทึกธุรกรรม ... แต่ยังไม่มีอะไรทำงาน เรากำลังทำงานอยู่: ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>') ... แต่ด้วยขนาดของฐานข้อมูลอาจใช้เวลาสองสามวันจึงจะเสร็จสมบูรณ์ คำถาม มีความแตกต่างระหว่างคำสั่งด้านบนและคำสั่งต่อไปนี้หรือไม่? DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) เราควรจะดำเนินการREPAIR_ALLOW_DATA_LOSSแทนหรือไม่ เป็นที่น่าสังเกตว่าข้อมูลนั้นมาจากแหล่งอื่น ๆ เพื่อให้สามารถสร้างฐานข้อมูลใหม่ได้อย่างไรก็ตามเราสงสัยว่าจะซ่อมแซมฐานข้อมูลได้เร็วกว่าการแทรกข้อมูลทั้งหมดอีกครั้ง ปรับปรุง สำหรับคะแนนการรักษาเหล่านั้น: ALTER DATABASE/REBUILD LOGคำสั่งเสร็จสิ้นหลังจากประมาณ 36 ชั่วโมงและรายงาน: คำเตือน: บันทึกสำหรับฐานข้อมูล 'dbname' ได้ถูกสร้างขึ้นใหม่ ความสอดคล้องของธุรกรรมสูญหายไป สายโซ่ RESTORE ใช้งานไม่ได้และเซิร์ฟเวอร์ไม่มีบริบทในไฟล์บันทึกก่อนหน้านี้อีกต่อไปดังนั้นคุณจะต้องรู้ว่าไฟล์เหล่านั้นคืออะไร คุณควรรัน DBCC …

1
เหตุใด CHECKDB จึงอ่านไฟล์บันทึกธุรกรรมบนฐานข้อมูลที่มีตารางปรับแต่งหน่วยความจำ
tl; dr : เหตุใด CHECKDB จึงอ่านบันทึกธุรกรรมสำหรับฐานข้อมูลผู้ใช้ที่มีตารางเพิ่มประสิทธิภาพหน่วยความจำ ปรากฏว่า CHECKDB กำลังอ่านไฟล์บันทึกธุรกรรมของฐานข้อมูลผู้ใช้เมื่อตรวจสอบฐานข้อมูลของฉันโดยเฉพาะฐานข้อมูลที่ใช้ตาราง OLTP ในหน่วยความจำ CHECKDB สำหรับฐานข้อมูลนี้ยังคงเสร็จสิ้นในระยะเวลาที่เหมาะสมดังนั้นฉันจึงอยากรู้เกี่ยวกับพฤติกรรม แต่มันเป็นระยะเวลายาวนานที่สุดสำหรับ CHECKDB ของฐานข้อมูลทั้งหมดในอินสแตนซ์นี้ ในการตรวจสอบCHECKDB จากทุกมุมมองของมหากาพย์ Paul Paulal : คำอธิบายที่สมบูรณ์ของขั้นตอน CHECKDB ทั้งหมดฉันเห็นว่า CHECKDB pre-SQL 2005 CHECKDB ใช้ในการอ่านบันทึกเพื่อให้ได้มุมมองที่สอดคล้องกันของฐานข้อมูล แต่เนื่องจากนี่เป็น 2016 จึงใช้สแน็ปช็อตฐานข้อมูลภายใน อย่างไรก็ตามหนึ่งในข้อกำหนดเบื้องต้นสำหรับสแน็ปช็อตคือ: ฐานข้อมูลต้นทางต้องไม่มีกลุ่มไฟล์ MEMORY_OPTIMIZED_DATA ฐานข้อมูลผู้ใช้ของฉันมีหนึ่งในกลุ่มไฟล์เหล่านี้ดังนั้นจึงดูเหมือนว่าสแน็ปช็อตอยู่นอกตาราง ตามเอกสาร CHECKDB : หากไม่สามารถสร้างสแน็ปช็อตหรือระบุ TABLOCK ได้ DBCC CHECKDB จะได้รับการล็อกเพื่อให้ได้ความสอดคล้องที่จำเป็น ในกรณีนี้จำเป็นต้องใช้การล็อกฐานข้อมูลแบบเอกสิทธิ์เฉพาะบุคคลเพื่อทำการตรวจสอบการจัดสรรและจำเป็นต้องใช้การล็อกตารางแบบแบ่งใช้เพื่อทำการตรวจสอบตาราง โอเคเรากำลังทำการล็อกฐานข้อมูลและล็อคตารางแทนสแนปชอต แต่นั่นก็ไม่ได้อธิบายว่าทำไมมันต้องอ่านบันทึกการทำธุรกรรม แล้วอะไรล่ะ ฉันได้จัดทำสคริปต์ด้านล่างเพื่อจำลองสถานการณ์ …

2
ดัชนี Columnstore ในกลุ่มไฟล์ read_only ป้องกัน CheckDB
จะปรากฏการตั้งค่ากลุ่มไฟล์เพื่อread_onlyป้องกันdbcc checkdbฐานข้อมูลทั้งหมดหากกลุ่มไฟล์มีดัชนี columnstore เมื่อพยายามเรียกใช้checkdbหรือcheckfilegroup( สำหรับกลุ่มไฟล์ใด ๆในฐานข้อมูลรวมถึงการอ่านเขียนที่สองและ[PRIMARY] ) ข้อผิดพลาดด้านล่างจะถูกส่งกลับ ... Msg 8921, Level 16, State 1, Line 24 Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors. มีวิธีการที่รองรับการมีข้อมูล columnstore ในกลุ่มไฟล์แบบอ่านอย่างเดียวหรือไม่? หรือฉันถูกกีดกันจากการตรวจสอบความสมบูรณ์ในสถานการณ์นี้? Repro create database check_fg_ro go use …

2
DBCC CHECKDB ความเสียหายที่ไม่สามารถแก้ไขได้: มุมมองที่จัดทำดัชนีมีแถวที่ไม่ได้สร้างขึ้นโดยการกำหนดมุมมอง
TL; DR: ฉันมีความเสียหายที่ไม่สามารถแก้ไขได้ในมุมมองที่จัดทำดัชนี นี่คือรายละเอียด: วิ่ง DBCC CHECKDB([DbName]) WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS บนหนึ่งในฐานข้อมูลของฉันสร้างข้อผิดพลาดต่อไปนี้: เกี่ยวกับข่าวสาร 8907 ระดับ 16 สถานะ 1 บรรทัด 1 ดัชนีเชิงพื้นที่ดัชนี XML หรือมุมมองที่จัดทำดัชนี 'ViewName' (ID วัตถุ 784109934) ประกอบด้วยแถวที่ไม่ได้สร้างขึ้นโดยการกำหนดมุมมอง สิ่งนี้ไม่จำเป็นต้องแสดงถึงปัญหาด้านความสมบูรณ์ของข้อมูลในฐานข้อมูลนี้ ( ... ) CHECKDB พบข้อผิดพลาดในการจัดสรร 0 ข้อและข้อผิดพลาดความสอดคล้อง 1 ข้อในตาราง 'ViewName' repair_rebuild เป็นระดับการซ่อมแซมขั้นต่ำ (... ) ฉันเข้าใจว่าข้อความนี้บ่งชี้ว่าข้อมูลที่เป็นรูปธรรมของมุมมองที่จัดทำดัชนี 'ViewName' ไม่เหมือนกับสิ่งที่สร้างข้อความค้นหาต้นแบบ อย่างไรก็ตามการตรวจสอบข้อมูลด้วยตนเองไม่ได้ทำให้เกิดความคลาดเคลื่อน: SELECT * …

1
การตรวจสอบทางกายภาพเท่านั้นล้มเหลว แต่เต็มไปด้วยความสำเร็จ
ฉันกำลังดำเนินการ checkdb พร้อมตัวเลือก physical_only และล้มเหลวโดยมีข้อผิดพลาดหลายอย่างเช่นด้านล่าง: ข่าวสารเกี่ยวกับ 8965 ระดับ 16 สถานะ 1 บรรทัด 1 ข้อผิดพลาดของตาราง: ID วัตถุ 1557580587, ดัชนี ID 1, ID พาร์ติชัน 72057594088456192, ID หน่วยจัดสรร 72057594177454080 (พิมพ์ข้อมูลในแถว) โหนดข้อมูลแบบปิดแถวที่หน้า (1: 13282192), ช่อง 3, ข้อความ ID 6370769698816 ถูกอ้างอิงโดยหน้า (0: 0), ช่อง 0 แต่ไม่เห็นในการสแกน ข่าวสารเกี่ยวกับ 8965 ระดับ 16 สถานะ 1 บรรทัด 1 ข้อผิดพลาดของตาราง: …

1
การสำรองข้อมูลตรวจพบความเสียหาย แต่ CHECKDB ไม่ได้
ฉันมีฐานข้อมูลที่เมื่อฉันรันคำสั่ง backup BACKUP DATABASE [MyDatabase] TO DISK = 'G:\Backup\MyDatabase_01_01_2018.bak' WITH NOFORMAT, NOSKIP, COMPRESSION, INIT, BUFFERCOUNT = 100 ฉันได้รับข้อความแสดงข้อผิดพลาด เกี่ยวกับ 3043 ระดับ 16 สถานะ 1 บรรทัด 8 สำรอง 'MyDatabase' ตรวจพบข้อผิดพลาดในหน้า (1: 745345) ในแฟ้ม 'F: \ Data \ MyDatabase_1.ndf' ข่าวสารเกี่ยวกับ 3013, ระดับ 16, สถานะ 1, ฐานข้อมูลการสำรอง8 บรรทัดถูกยกเลิกอย่างผิดปกติ ฉันใช้ CHECKDB เต็ม แต่กลับมาสะอาด ฉันสังเกตเห็นว่าตัวเลือก …

2
แบ่ง DBCC CHECKDB ในช่วงหลายวัน
ฉันทำงานเกี่ยวกับการใช้วิธีการของ Paul Randal ในการกระจาย DBCC CHECKDB ด้วยตนเองไปหลายวันสำหรับฐานข้อมูลขนาดใหญ่มากซึ่งโดยทั่วไปประกอบด้วย: การแบ่งตารางในฐานข้อมูลอย่างคร่าว ๆ ระหว่าง 7 ถังข้อมูล รัน DBCC CHECKALLOC สองครั้งต่อสัปดาห์ รัน DBCC CHECKCATALOG สัปดาห์ละครั้ง รัน DBCC CHECKTABLE ในหนึ่งถังในแต่ละวันของสัปดาห์ มีใครใช้เทคนิคนี้หรือไม่? สคริปต์ที่มีอยู่ออกมี? ฉันกังวลว่าสิ่งนี้อาจไม่ครอบคลุมทุกอย่างที่ CHECKDB ทำ หนังสือ Books Online สำหรับ CHECKDBกล่าวว่านอกเหนือจาก CHECKALLOC, CHECKCATALOG และ CHECKTABLE แล้วยัง: ตรวจสอบเนื้อหาของทุกมุมมองที่จัดทำดัชนีในฐานข้อมูล ตรวจสอบความสอดคล้องระดับลิงก์ระหว่างตารางเมตาดาต้าและไดเรกทอรีระบบไฟล์และไฟล์เมื่อเก็บข้อมูล varbinary (สูงสุด) ในระบบไฟล์โดยใช้ FILESTREAM (SQL 2008 เท่านั้น) ตรวจสอบข้อมูล Service …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.