DBCC CHECKDB: คู่มือ MS ฉบับสมบูรณ์ SQL Server ฐานข้อมูลสุขภาพ (2026)

DBCC CHECKDB คือ SQL Serverเครื่องมือหลักสำหรับตรวจสอบความสมบูรณ์ของฐานข้อมูล เรียนรู้วิธีใช้พร้อมตัวอย่าง การแก้ไขปัญหา และเพิ่มประสิทธิภาพการทำงาน

3. การเรียกใช้ DBCC CHECKDB: ทีละขั้นตอน

ข้อกำหนดเบื้องต้น 3.1

ด้านล่างนี้เป็นรายการตรวจสอบก่อนดำเนินการ DBCC CHECKDB ใด ๆ:

• สำรองฐานข้อมูลให้สมบูรณ์ – สร้างการสำรองข้อมูลเต็มรูปแบบก่อนที่จะเรียกใช้การตรวจสอบความสมบูรณ์ เพื่อเป็นตาข่ายนิรภัยหากพบการทุจริตหรือต้องดำเนินการซ่อมแซม
• การอนุญาตที่ถูกต้อง – คุณต้องมีสิทธิ์ sysadmin หรือ db_owner จึงจะดำเนินการคำสั่ง DBCC CHECKDB ได้
• ทรัพยากรระบบเพียงพอ:
  • หน่วยความจำ: 25% ของขนาดฐานข้อมูล
  • พื้นที่ Tempdb: 10-15% ของขนาดฐานข้อมูล
  • CPU: พร้อมใช้งาน 50-70% ระหว่างการบำรุงรักษา
  • I/O: คาดหวังการดำเนินการอ่านหนัก
• การเข้าถึงฐานข้อมูล – ตรวจสอบว่าฐานข้อมูลของคุณสามารถเข้าถึงได้และไม่ได้อยู่ในสถานะจำกัด เนื่องจาก CHECKDB ต้องมีสิทธิ์อ่านหน้าฐานข้อมูลทั้งหมด

3.2 คำสั่งพื้นฐาน

ม.ost คำสั่ง DBCC CHECKDB ขั้นพื้นฐานมีรูปแบบทั่วไปสามแบบ:

(1) ตรวจสอบฐานข้อมูลปัจจุบัน (ไม่มีพารามิเตอร์):

DBCC CHECKDB

(2) ตรวจสอบฐานข้อมูลตามชื่อ:

DBCC CHECKDB ('YourDatabaseName')

(3) ตรวจสอบฐานข้อมูลด้วย ID:

DBCC CHECKDB(5)  -- Replace 5 with your database ID

คำสั่งพื้นฐานนี้จะทำการตรวจสอบความสมบูรณ์ของฐานข้อมูลที่ระบุทั้งหมด โดยจะตรวจสอบตาราง ดัชนี และโครงสร้างระบบทั้งหมด สำหรับฐานข้อมูลที่มีชื่อมาตรฐานซึ่งไม่มีช่องว่าง คุณสามารถละเว้นเครื่องหมายคำพูดได้ คำสั่งจะทำงานจนเสร็จสมบูรณ์ โดยจะแสดงข้อความความคืบหน้าและผลลัพธ์สุดท้าย ไวยากรณ์พื้นฐานนี้ใช้งานได้ดีกับฐานข้อมูลขนาดเล็กหรือเมื่อคุณมีเวลาบำรุงรักษาเพียงพอ

ด้านล่างนี้เป็นภาพหน้าจอของการรัน DBCC CHECKDB ใน SQL Server สตูดิโอการจัดการ (SSMS):

3.3 ตัวเลือกที่สมบูรณ์

ด้านล่างนี้เป็นตัวเลือกที่สมบูรณ์สำหรับ DBCC CHECKDB:

Category	ตัวเลือกเสริม (Option)	รายละเอียด	ตัวอย่าง DBCC CHECKDB
ตัวเลือกการซ่อม	REPAIR_REBUILD	การซ่อมแซมโดยไม่สูญเสียข้อมูล (เช่น การสร้างดัชนีใหม่)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	ไม่ต้องซ่อม รองรับรุ่นก่อนหน้าเท่านั้น	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	ซ่อมแซมทุกข้อผิดพลาด (อาจทำให้สูญเสียข้อมูล)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
การควบคุมขอบเขต	NOINDEX	ข้ามการตรวจสอบดัชนีที่ไม่เป็นคลัสเตอร์	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	ตรวจสอบเฉพาะความสมบูรณ์ของที่เก็บข้อมูลทางกายภาพ (หน้า/บันทึก)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	ตรวจสอบข้อผิดพลาดของค่าคอลัมน์เชิงตรรกะ (เช่น วันที่ไม่ถูกต้อง)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	การตรวจสอบลอจิกเชิงลึก (มุมมองที่สร้างดัชนี ดัชนี XML/เชิงพื้นที่)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
การควบคุมเอาต์พุต	ALL_ERRORMSGS	แสดงข้อผิดพลาดทั้งหมด (ค่าเริ่มต้น: 200 ต่ออ็อบเจ็กต์)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	ซ่อนข้อความข้อมูล	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
ประสิทธิภาพ	TABLOCK	ใช้การล็อกตาราง (ลดการใช้งาน TempDB แต่บล็อกการเขียน)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	การแทนที่การตั้งค่าความขนาน	DBCC CHECKDB ('MyDB', MAXDOP = 2)
ประโยชน์	ESTIMATEONLY	ประมาณการพื้นที่ TempDB ที่จำเป็น (ไม่มีการตรวจสอบจริง)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. การทำความเข้าใจผลลัพธ์ของคุณ

DBCC CHECKDB จะให้ผลลัพธ์ที่แตกต่างกันขึ้นอยู่กับว่าการดำเนินการนั้นเสร็จสมบูรณ์หรือไม่ มาอธิบายรายละเอียดกัน

4.1 การดำเนินการ CHECKDB เสร็จสมบูรณ์

หากการดำเนินการ DBCC CHECKDB เสร็จสมบูรณ์ ระบบจะรายงานผลลัพธ์ประเภทต่างๆ ขึ้นอยู่กับสถานะสุขภาพของฐานข้อมูลของคุณ

4.1.1 ไม่พบปัญหาใดๆ

หาก DBCC CHECKDB ไม่พบปัญหาใดๆ คุณจะเห็นผลลัพธ์ที่คล้ายกับ:

CHECKDB found 0 allocation errors and 0 consistency errors in database 'YourDatabase'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

ผลลัพธ์นี้บ่งชี้ว่าฐานข้อมูลของคุณรักษาความสมบูรณ์สมบูรณ์แบบในโครงสร้างที่ได้รับการตรวจสอบทั้งหมด

4.1.2 พบข้อผิดพลาดการทุจริต

เมื่อใดก็ตามที่ DBCC CHECKDB ตรวจพบข้อผิดพลาดการทุจริต ระบบจะรายงานข้อความแสดงข้อผิดพลาดโดยมีโครงสร้างต่อไปนี้:
คำแนะนำระดับความรุนแรง:

• ระดับ 16-19: ข้อผิดพลาดที่ผู้ใช้แก้ไขได้ มักเป็นความเสียหายเล็กน้อย
• ระดับ 20-24: ข้อผิดพลาดของระบบ การทุจริตร้ายแรงที่ต้องได้รับการแก้ไขทันที
• 25 ระดับ: เกิดข้อผิดพลาดร้ายแรง ฐานข้อมูลอาจไม่สามารถเข้าถึงได้

ข้อผิดพลาดทั่วไปได้แก่:

• ความล้มเหลวของการตรวจสอบความถูกต้องของหน้า (ข้อความ 824)
• ข้อผิดพลาดในการจัดสรร (ข้อความ 8928)
• ปัญหาความสอดคล้องของดัชนี (ข้อความ 8964)

การทำความเข้าใจโครงสร้างข้อความจะช่วยกำหนดลำดับความสำคัญของการดำเนินการตอบสนองและกำหนดกลยุทธ์การกู้คืนที่เหมาะสม

4.1.3 ข้อความแจ้งข้อมูลและคำเตือนทั่วไป

ผลลัพธ์ของ DBCC CHECKDB ไม่ได้บ่งชี้ถึงปัญหาที่ร้ายแรงทั้งหมด นอกจากนี้ ยังอาจแสดงข้อความแจ้งข้อมูลและคำเตือนบางรายการ เช่น:

• ใบแจ้งรายละเอียดการซ่อมแซม – ข้อความที่แนะนำคำสั่งซ่อมแซมเพื่อแก้ไขปัญหาเล็กน้อย
• คำเตือนการจัดสรร – คำเตือนเรื่องการจัดสรรพื้นที่ที่ไม่กระทบต่อการเข้าถึงข้อมูล
• คำแนะนำด้านประสิทธิภาพ – ข้อเสนอแนะสำหรับการดูแลรักษาและเพิ่มประสิทธิภาพดัชนี
• ประกาศแจ้งข้อมูล – ข้อความสถานะทั่วไปที่ไม่จำเป็นต้องดำเนินการทันที

ข้อความเหล่านี้ให้คำแนะนำการบำรุงรักษาที่มีคุณค่าในขณะที่แยกแยะระหว่างการทุจริตที่สำคัญที่ต้องดำเนินการทันทีและปัญหาเล็กน้อยที่สามารถแก้ไขได้ในช่วงเวลาการบำรุงรักษาปกติ

ตัวอย่างข้อความเตือน:

DBCC results for 'InventoryDatabase'.
Msg 2570, Level 16, State 3, Line 1
Page (2:8452), slot 17 in object ID 485577333, index ID 0, partition ID 72057594038845456, 
alloc unit ID 72057594042515968 (type "In-row data").
Column "ProductPrice" value is out of range for data type "decimal". Update column to a legal value.
There are 45892 rows in 1247 pages for object "Products".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'Products' (object ID 485577333).
CHECKDB found 0 allocation errors and 1 consistency errors in database 'InventoryDatabase'.

4.2 การดำเนินการ CHECKDB ล้มเหลว

หาก CHECKDB ยุติการทำงานระหว่างการดำเนินการเนื่องจากสาเหตุต่างๆ ระบบจะรายงานข้อความแสดงข้อผิดพลาดและเพิ่มบันทึกข้อผิดพลาดโดยมีโค้ดสถานะด้านล่างนี้:

สถานะ	รายละเอียด
0	เกิดข้อผิดพลาดหมายเลข 8930 ซึ่งบ่งชี้ถึงการทุจริตในข้อมูลเมตาที่ทำให้คำสั่ง DBCC ยุติลง
1	ข้อผิดพลาดหมายเลข 8967 ถูกยกขึ้น มีข้อผิดพลาด DBCC ภายใน
2	เกิดความล้มเหลวระหว่างการซ่อมแซมฐานข้อมูลโหมดฉุกเฉิน
3	สิ่งนี้บ่งชี้ถึงการทุจริตในข้อมูลเมตาที่ทำให้คำสั่ง DBCC ยุติลง
4	ตรวจพบการยืนยันหรือการละเมิดการเข้าถึง
5	เกิดข้อผิดพลาดที่ไม่ทราบสาเหตุซึ่งทำให้คำสั่ง DBCC สิ้นสุดลง

ตัวอย่างข้อความแสดงข้อผิดพลาด:

Failed:(-1073548784) Executing the query "DBCC CHECKDB('InventoryDB') WITH NO_INFOMSGS" failed with the following error: "There is insufficient system memory to run this query.Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

หรือ

2024-11-18 09:52:41.38 spid35 I/O error (bad page ID) detected during read at offset 0x00000024886000 in file 'C:\Data\MSSQL\DATA\SalesDatabase.mdf'.

ตัวอย่างบันทึกข้อผิดพลาด:

11/15/2024 09:23:17,spid52,Unknown,DBCC CHECKDB (SalesDatabase) WITH all_errormsgs no_infomsgs executed by CORP\dbadmin terminated abnormally due to error state 3. Elapsed time: 1 hours 32 minutes 18 seconds.

ในกรณีเช่นนี้ คุณสามารถลองใช้ตัวเลือกขั้นสูงอื่นๆ เช่น DataNumen SQL Recovery เพื่อแก้ไขความเสียหายในฐานข้อมูลของคุณ

5. การแก้ไขข้อผิดพลาดการทุจริต

5.1 การสำรองและกู้คืน: การแก้ไขที่ปลอดภัยที่สุด

เมื่อ DBCC CHECKDB ระบุข้อผิดพลาดการทุจริต การคืนค่าจากการสำรองข้อมูลที่สะอาดถือเป็นวิธีที่ปลอดภัยที่สุดและมost โซลูชันที่เชื่อถือได้ แนวทางนี้รับประกันความสมบูรณ์ของข้อมูลพร้อมทั้งขจัดสาเหตุการเสียหายที่อยู่เบื้องหลัง ก่อนที่จะกู้คืน ให้ตรวจสอบความสมบูรณ์ของการสำรองข้อมูลโดยใช้ คืนค่ายืนยันเท่านั้น คำสั่ง และพิจารณาตัวเลือกการกู้คืนในช่วงเวลาหนึ่งเพื่อลดการสูญเสียข้อมูล บันทึกรายละเอียดความเสียหายเพื่อวิเคราะห์สาเหตุหลัก เนื่องจากปัญหาฮาร์ดแวร์หรือข้อบกพร่องของซอฟต์แวร์อาจต้องได้รับการดูแลเพิ่มเติมเพื่อป้องกันไม่ให้เกิดขึ้นซ้ำ

5.2 การแก้ไขปัญหาการทุจริตในระดับหน้า

สำหรับความเสียหายของหน้าแยกที่ส่งผลต่อส่วนข้อมูลขนาดเล็ก SQL Server Enterprise Edition นำเสนอความสามารถในการกู้คืนเพจที่สามารถซ่อมแซมเพจที่เสียหายเฉพาะเจาะจงได้โดยไม่ต้องกู้คืนฐานข้อมูลทั้งหมด เทคนิคขั้นสูงนี้ต้องการแบบจำลองการกู้คืนทั้งหมดและการสำรองข้อมูลบันทึกปัจจุบัน

ขั้นตอนการกู้คืนหน้าทีละขั้นตอน:

1. ระบุหน้าที่เสียหาย จากข้อความแสดงข้อผิดพลาด CHECKDB (เช่น หน้า 1:256)
2. สำรองข้อมูลบันทึกปัจจุบัน เพื่อบันทึกธุรกรรมล่าสุด:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Log.trn'

3. กู้คืนหน้าที่เสียหาย จากม.ost การสำรองข้อมูลเต็มล่าสุด:

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Full.bak'

4. ใช้การสำรองข้อมูลแบบดิฟเฟอเรนเชียล (ถ้ามี):

RESTORE DATABASE YourDatabase PAGE = '1:256' 
FROM DISK = 'C:\Backups\YourDB_Diff.bak'

5. ใช้การสำรองข้อมูลบันทึกทั้งหมด ตามลำดับรวมทั้งที่เพิ่งสร้าง:

RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log1.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log2.trn'
-- Continue for all log backups in order
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Log.trn'

6. สำรองข้อมูลบันทึกสุดท้ายและเรียกคืน เพื่อให้หน้าเป็นปัจจุบัน:

BACKUP LOG YourDatabase TO DISK = 'C:\Backups\YourDB_Final.trn'
RESTORE LOG YourDatabase FROM DISK = 'C:\Backups\YourDB_Final.trn'

ทางเลือกสำหรับข้อมูลที่ไม่สำคัญ: หากความเสียหายส่งผลต่อข้อมูลที่ไม่สำคัญ คุณอาจส่งออกแถวที่ไม่ได้รับผลกระทบไปยังตารางใหม่ก่อนที่จะสร้างโครงสร้างที่เสียหายขึ้นมาใหม่:

-- Export good data to a new table
SELECT * INTO YourTable_Backup 
FROM YourTable 
WHERE NOT EXISTS (SELECT 1 FROM corrupt_page_list WHERE page_id = target_page)

-- Drop and recreate the corrupted table
DROP TABLE YourTable
-- Recreate table structure and reload clean data

5.3 การแก้ไขด่วนเกี่ยวกับการทุจริตดัชนี

การทุจริตดัชนีมักจะตอบสนองได้ดีต่อการสร้างใหม่ที่สร้างโครงสร้างดัชนีใหม่โดยไม่ส่งผลกระทบต่อข้อมูลตารางพื้นฐาน:

ALTER INDEX ALL ON YourTable REBUILD

แนวทางนี้ใช้ได้ผลดีโดยเฉพาะกับการเสียหายของดัชนีที่ไม่ได้อยู่ในคลัสเตอร์ เนื่องจากการสร้างใหม่จะสร้างหน้าดัชนีใหม่จากข้อมูลตารางต้นฉบับ ทำให้สามารถกำจัดการเสียหายได้อย่างมีประสิทธิภาพ ในขณะเดียวกันก็รักษาข้อมูลเดิมทั้งหมดไว้

6. ใช้ REPAIR_REBUILD และ REPAIR_ALLOW_DATA_LOSS

หากวิธีการก่อนหน้านี้ทั้งหมดล้มเหลวหรือไม่สามารถทำได้ คุณสามารถใช้ตัวเลือก REPAIR_REBUILD และ REPAIR_ALLOW_DATA_LOSS เพื่อซ่อมแซมฐานข้อมูล

6.1 REPAIR_REBUILD (ตัวเลือกที่ปลอดภัยกว่า):

• ใช้สำหรับ: การทุจริตดัชนีและข้อผิดพลาดในการจัดสรรเล็กน้อย
• ความปลอดภัยของข้อมูล: พยายามแก้ไขการทุจริตโดยไม่ต้องลบข้อมูล
• ระดับความเสี่ยง: ต่ำ – คาดว่าจะไม่มีการสูญเสียข้อมูล
• สถานการณ์ทั่วไป: การทุจริตดัชนีที่ไม่คลัสเตอร์ มีปัญหาเมตาข้อมูลเล็กน้อย
• ตัวอย่างคำสั่ง: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 การซ่อมแซม_ALLOW_DATA_LOSS (วิธีสุดท้าย):

• ใช้สำหรับ: ความเสียหายร้ายแรงเมื่อไม่สามารถสำรองข้อมูลได้
• ความปลอดภัยของข้อมูล: อาจลบข้อมูลที่เสียหายเพื่อคืนฟังก์ชันการทำงานของฐานข้อมูล
• ระดับความเสี่ยง: สูง – อาจสูญเสียข้อมูลถาวรได้
• สถานการณ์ทั่วไป: ความเสียหายของหน้า, ตารางระบบเสียหาย, ข้อผิดพลาดของห่วงโซ่การจัดสรร
• ตัวอย่างคำสั่ง: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 แนวทางปฏิบัติที่ดีที่สุดสำหรับตัวเลือกเหล่านี้:

• ทดสอบเสมอ การดำเนินการซ่อมแซมสำเนาฐานข้อมูลเมื่อเป็นไปได้
• สำรองข้อมูลไว้เสมอ ก่อนที่จะเรียกใช้ตัวเลือกเหล่านี้
• บันทึกการเปลี่ยนแปลงทั้งหมด เพื่อวัตถุประสงค์ด้านการปฏิบัติตามและการแก้ไขปัญหา
• ตั้งค่าฐานข้อมูลเป็นโหมดผู้ใช้รายเดียว ก่อนดำเนินการซ่อมแซม

โดยปกติเราควรลอง ซ่อมแซม_สร้างใหม่ ตัวเลือกแรก หากล้มเหลว ให้ลอง ซ่อมแซม_ALLOW_DATA_LOSS ตัวเลือก

6.4 ผลลัพธ์การซ่อมแซม_ALLOW_DATA_LOSS

6.4.1 การซ่อมแซมประสบความสำเร็จแม้จะมีการสูญเสียข้อมูล

บางครั้ง ซ่อมแซม_ALLOW_DATA_LOSS ตัวเลือกจะประสบความสำเร็จ แต่ข้อมูลบางอย่างก็ลost หลังจากการซ่อมแซม

ต่อไปนี้เป็นข้อความตัวอย่างบางส่วน:

CHECKDB found 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
CHECKDB fixed 0 allocation errors and 103 consistency errors in database ‘SalesDatabase’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8909, Level 16, State 1, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 45035996309880832 (type Unknown), page ID (1:553) contains an incorrect page ID in its page header. The PageId in the page header = (0:0).
The error has been repaired.
Msg 8939, Level 16, State 98, Line 8
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 111464090777419776 (type Unknown), page (0:0). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 2057 and -1.
Could not repair this error.

เนื่องจาก DBCC CHECKDB แก้ไขฐานข้อมูลโดยละทิ้งระเบียนที่เสียหายบางส่วน แต่ในความเป็นจริงแล้วost ของพวกเขายังสามารถกู้คืนได้ผ่าน DataNumen SQL Recovery.

ไฟล์ตัวอย่าง:

SQL Server รุ่น	ไฟล์ MDF เสียหาย	ไฟล์ MDF แก้ไขโดย DataNumen SQL Recovery
SQL Server 2014	ข้อผิดพลาด 10_1.mdf (ข้อความ 8909 ตามด้วยข้อความ 8939) (600 บันทึก lost พร้อม REPAIR_ALLOW_DATA_LOSS)	ข้อผิดพลาด10_1_fixed.mdf (ไม่มีบันทึกลost)
SQL Server 2014	ข้อผิดพลาด 10_2.mdf (ข้อความ 8909 ตามด้วยข้อความ 8939) (6000 บันทึก(50%) ลost พร้อม REPAIR_ALLOW_DATA_LOSS)	ข้อผิดพลาด10_2_fixed.mdf (มีเพียง 100 บันทึกเท่านั้นost)
SQL Server 2014	Error7.mdf (100 บันทึกลost พร้อม REPAIR_ALLOW_DATA_LOSS)	Error7_fixed.mdf (มีบันทึกเพียงหนึ่งรายการเท่านั้นost)

6.4.2 การซ่อมแซมล้มเหลว – พิจารณาวิธีแก้ปัญหาจากมืออาชีพ

If ซ่อมแซม_ALLOW_DATA_LOSS หากล้มเหลว ระบบจะส่งข้อความแสดงข้อผิดพลาดหนึ่งข้อความหรือหลายรายการ

ด้านล่างนี้เป็นตัวอย่างบางส่วน:

DBCC results for ‘MyDatabase’.
CHECKDB found 0 allocation errors and 0 consistency errors in database ‘MyDatabase’.
Msg 824, Level 24, State 2, Line 8
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xea8a9a2f; actual: 0x37adbff8). It occurred during a read of page (1:28) in database ID 39 at offset 0x00000000038000 in file ‘MyDatabase.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Msg 7909, Level 20, State 1, Line 8
The emergency-mode repair failed.You must restore from backup.

Msg 8992, Level 16, State 1, Line 8
Check Catalog Msg 3852, State 1: Row (object_id=69) in sys.objects (type=S ) does not have a matching row (object_id=69,column_id=1) in sys.columns.

Msg 8945, Level 16, State 1, Line 8
Table error: Object ID 41, index ID 1 will be rebuilt.
Could not repair this error.

Msg 2510, Level 16, State 17, Line 8
DBCC checkdb error: This system table index cannot be recreated.
Repair: The Nonclustered index successfully rebuilt for the object “sysidxstats” in database “MyDatabase”.

Msg 8921, Level 16, State 1, Line 8
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Msg 8998, Level 16, State 2, Line 8
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID 39 pages from (1:0) to (1:8087). See other errors for cause.
CHECKDB found 1 allocation errors and 0 consistency errors not associated with any single object.
Msg 2575, Level 16, State 1, Line 8
The Index Allocation Map (IAM) page (1:157) is pointed to by the next pointer of IAM page (0:0) in object ID 3, index ID 1, partition ID 196608, alloc unit ID 196608 (type In-row data), but it was not detected in the scan.
Could not repair this error.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘sys.sysrscols’ (object ID 3).

Msg 8948, Level 16, State 3, Line 8
Database error: Page (1:295) is marked with the wrong type in PFS page (1:1). PFS status 0x70 expected 0x60.
The error has been repaired.
Msg 8905, Level 16, State 1, Line 8
Extent (1:296) in database ID 39 is marked allocated in the GAM, but no SGAM or IAM has allocated it.
The error has been repaired.

Msg 5028, Level 16, State 4, Line 4
The system could not activate enough of the database to rebuild the log.

Msg 5125, Level 24, State 2, Line 2
File ‘C:Program FilesMicrosoft SQL ServerMSSQL12.SQL2014MSSQLDATASalesDatabase.mdf’ appears to have been truncated by the operating system. Expected size is 5120 KB but actual size is 5112 KB.
Msg 3414, Level 21, State 1, Line 2
An error occurred during recovery, preventing the database ‘SalesDatabase’ (39:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

Msg 3313, Level 21, State 1, Line 2
During redoing of a logged operation in database ‘SalesDatabase’, an error occurred at log record ID (135:752:2). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.

ในสถานการณ์เหล่านี้ คุณจำเป็นต้องใช้โซลูชันระดับมืออาชีพ เช่น DataNumen SQL Recovery เพื่อแก้ไขฐานข้อมูลของคุณ

ไฟล์ตัวอย่าง

SQL Server รุ่น	ไฟล์ MDF เสียหาย	ไฟล์ MDF แก้ไขโดย DataNumen SQL Recovery
SQL Server 2014	ข้อผิดพลาด 1_3.mdf (ข้อความเดี่ยว 824)	ข้อผิดพลาด1_3_fixed.mdf
SQL Server 2014	ข้อผิดพลาด 1_1.mdf (ข้อความต่อเนื่อง 824 ข้อผิดพลาด)	ข้อผิดพลาด 1_1_fixed.mdf
SQL Server 2014	ข้อผิดพลาด 1_2.mdf ((ข้อความ 824 ตามด้วยข้อความ 7909)	ข้อผิดพลาด1_2_fixed.mdf
SQL Server 2014	ข้อผิดพลาด 4_1.mdf (ข้อความ 8992 ตามด้วยข้อความ 3852)	ข้อผิดพลาด4_1_fixed.mdf
SQL Server 2014	ข้อผิดพลาด 4_2.mdf (ข้อความ 8992 ตามด้วยข้อความ 3852)	ข้อผิดพลาด4_2_fixed.mdf
SQL Server 2014	Error5.mdf (ข้อความ 8945)	Error5_fixed.mdf
SQL Server 2014	Error6.mdf (ข้อความ 2510)	Error6_fixed.mdf
SQL Server 2014	Error2.mdf (ข้อความ 2575)	Error2_fixed.mdf
SQL Server 2014	Error11.mdf (ข้อความ 8905)	Error11_fixed.mdf
SQL Server 2014	Error3.mdf (ข้อความ 5028)	Error3_fixed.mdf
SQL Server 2014	Error8.mdf (ข้อความ 5125)	Error8_fixed.mdf
SQL Server 2014	Error9.mdf (ข้อความ 3313)	Error9_fixed.mdf

7. แนวทางปฏิบัติที่ดีที่สุด

7.1 การกำหนดตารางการดำเนินการ CHECKDB เป็นประจำ

นำการดำเนินการ DBCC CHECKDB รายสัปดาห์ไปใช้กับฐานข้อมูลการผลิตที่สำคัญ โดยมีการตรวจสอบรายวันสำหรับระบบที่มีธุรกรรมสูง กำหนดเวลาการทำงานในช่วงที่มีการใช้งานน้อยเพื่อลดผลกระทบต่อประสิทธิภาพ และพิจารณาการหมุนเวียนระหว่างการตรวจสอบเต็มรูปแบบและตัวเลือก PHYSICAL_ONLY ตามขนาดฐานข้อมูลและช่วงเวลาการบำรุงรักษา กำหนดเวลาอัตโนมัติผ่าน SQL Server ตัวแทนช่วยให้มั่นใจว่าการดำเนินการมีความสอดคล้องกันในขณะที่ให้ความสามารถในการตรวจสอบและแจ้งเตือนแบบรวมศูนย์

7.2 การจัดการผลกระทบต่อประสิทธิภาพการทำงาน

การดำเนินการ DBCC CHECKDB ใช้ทรัพยากรระบบจำนวนมาก ซึ่งอาจส่งผลต่อกิจกรรมของผู้ใช้พร้อมกัน ตรวจสอบการใช้งาน CPU การใช้หน่วยความจำ และ I/O ของดิสก์ในระหว่างการตรวจสอบเพื่อทำความเข้าใจรูปแบบผลกระทบต่อประสิทธิภาพ พิจารณาใช้ตัวเลือก NOINDEX สำหรับการตรวจสอบตามปกติ โดยสงวนการตรวจสอบแบบเต็มรูปแบบไว้สำหรับช่วงเวลาการบำรุงรักษารายเดือน ใช้ส่วนขยายเวลาหมดเวลาของแบบสอบถามและกลยุทธ์การสื่อสารของผู้ใช้เพื่อจัดการความคาดหวังในช่วงเวลาการตรวจสอบความสมบูรณ์

7.3 การวางแผนหน้าต่างการบำรุงรักษา

ประสานงานกำหนดการ DBCC CHECKDB กับกิจกรรมการบำรุงรักษาอื่นๆ เช่น การดำเนินการสำรองข้อมูล การสร้างดัชนีใหม่ และการอัปเดตสถิติ หลีกเลี่ยงการดำเนินการซ้ำซ้อนที่ใช้ทรัพยากรมากซึ่งอาจทำให้ประสิทธิภาพลดลงหรือเกิดปัญหาการหมดเวลา วางแผนช่วงเวลาการบำรุงรักษาตามการคาดการณ์การเติบโตของขนาดฐานข้อมูล โดยให้แน่ใจว่ามีเวลาเพียงพอสำหรับการตรวจสอบความสมบูรณ์อย่างสมบูรณ์เมื่อปริมาณข้อมูลเพิ่มขึ้น

7.4 การตรวจสอบและแจ้งเตือนอัตโนมัติ

กำหนดค่า SQL Server ตัวแทนจะแจ้งเตือนผู้ดูแลระบบทันทีเมื่อ DBCC CHECKDB ตรวจพบการทุจริต ใช้โซลูชันการแยกวิเคราะห์บันทึกที่แยกและจัดหมวดหมู่ผลการตรวจสอบความสมบูรณ์ ช่วยให้วิเคราะห์แนวโน้มและระบุปัญหาเชิงรุกได้ สร้างขั้นตอนการขยายเวลาที่กำหนดกรอบเวลาตอบสนองและบุคลากรที่รับผิดชอบสำหรับระดับความรุนแรงของการทุจริตที่แตกต่างกัน

8. DBCC CHECKTABLE: ทางเลือกที่น้ำหนักเบา

8.1 เมื่อใดควรใช้ CHECKTABLE แทน CHECKDB

DBCC CHECKTABLE ให้การตรวจสอบความสมบูรณ์ที่เน้นเฉพาะตารางแต่ละตาราง ทำให้เหมาะอย่างยิ่งสำหรับ tarการแก้ไขปัญหาและการบำรุงรักษาอ็อบเจกต์ฐานข้อมูลเฉพาะ ใช้ CHECKTABLE เมื่อตรวจสอบปัญหาประสิทธิภาพกับตารางเฉพาะ ตรวจสอบตารางธุรกิจที่สำคัญระหว่างการตรวจสอบฐานข้อมูลแบบเต็ม หรือเมื่อข้อจำกัดด้านเวลาขัดขวางการตรวจสอบฐานข้อมูลอย่างสมบูรณ์ แนวทางนี้พิสูจน์แล้วว่ามีประโยชน์อย่างยิ่งในฐานข้อมูลขนาดใหญ่ที่การดำเนินการ CHECKDB แบบเต็มเกินช่วงเวลาการบำรุงรักษาที่มีอยู่

8.2 ไวยากรณ์และตัวอย่าง DBCC CHECKTABLE

คำสั่งพื้นฐาน CHECKTABLE tarได้รับตารางเฉพาะ:

DBCC CHECKTABLE('YourTable')

เช่นเดียวกับ CHECKDB, CHECKTABLE รองรับตัวเลือกต่างๆ รวมถึง NOINDEX สำหรับการเพิ่มประสิทธิภาพการทำงานและพารามิเตอร์การซ่อมแซมเพื่อแก้ไขการทุจริต คุณยังสามารถระบุชื่อสคีมาเพื่อระบุตารางได้อย่างแม่นยำ:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

แจกันดอกไม้โรแมนติกนี้ tarแนวทาง Geted ช่วยให้สามารถตรวจสอบความสมบูรณ์ได้ในระดับละเอียดในขณะที่ยังคงรักษาประสิทธิภาพของระบบในระหว่างเวลาทำการ

8.3 ประโยชน์ด้านประสิทธิภาพสำหรับฐานข้อมูลขนาดใหญ่

การดำเนินการของ CHECKTABLE เสร็จสิ้นเร็วกว่าการตรวจสอบฐานข้อมูลทั้งหมดอย่างเห็นได้ชัด ทำให้สามารถตรวจสอบความสมบูรณ์ของตารางที่สำคัญได้บ่อยขึ้น วิธีนี้ช่วยให้สามารถตรวจสอบตารางธุรกิจที่สำคัญได้ทุกวันในขณะที่สำรองการดำเนินการของ CHECKDB ที่ครอบคลุมไว้สำหรับกำหนดการรายสัปดาห์หรือรายเดือน การใช้ทรัพยากรที่ลดลงทำให้ CHECKTABLE เหมาะสำหรับการดำเนินการในสภาพแวดล้อมการผลิตโดยมีผลกระทบต่อผู้ใช้น้อยที่สุด

9. เมื่อ CHECKDB ล้มเหลว

DBCC CHECKDB จะล้มเหลวในสถานการณ์ต่างๆ รวมถึง:

• การดำเนินการ DBCC CHECKDB สิ้นสุดอย่างผิดปกติ
• การดำเนินการ DBCC CHECKDB เสร็จสมบูรณ์ แต่ ตัวเลือกการซ่อมแซม ไม่สามารถซ่อมแซมฐานข้อมูลได้

ในสถานการณ์เหล่านี้ เราต้องการเครื่องมือที่เป็นมืออาชีพมากขึ้นเพื่อช่วยเราแก้ไขความเสียหายในฐานข้อมูล

9.1 ความรู้เบื้องต้นเกี่ยวกับ DataNumen SQL Recovery

DataNumen SQL Recovery ให้ความสามารถขั้นสูงมากขึ้น:

• อัตราการฟื้นตัวที่ดีที่สุด ในอุตสาหกรรม
• กู้คืนไฟล์ฐานข้อมูลที่เสียหายร้ายแรง
• กู้คืนวัตถุฐานข้อมูลทั้งหมด รวมถึงตาราง ดัชนี มุมมอง ทริกเกอร์ กฎ และค่าเริ่มต้น
• กู้คืนกระบวนงานที่เก็บไว้ ฟังก์ชันสเกลาร์ ฟังก์ชันค่าตารางแบบอินไลน์ และฟังก์ชันค่าตารางหลายสถานะ
• กู้คืนข้อมูลที่ถูกลบทิ้งอย่างถาวร
• ถอดรหัสวัตถุที่เข้ารหัสใน SQL Server ฐานข้อมูล
• ซ่อมแซมไฟล์ MDF แบบเป็นชุด
• ตัวเลือกการซ่อมแซมที่ครอบคลุม
• การบันทึกและการรายงานขั้นสูง
• รองรับทุกคน SQL Server รุ่นที่
• ความพร้อมของการสนับสนุนด้านเทคนิค
• การอัปเดตและการปรับปรุงเป็นประจำ

9.2 การเปรียบเทียบอัตราความสำเร็จ

อัตราความสำเร็จในการฟื้นฟูแตกต่างกันอย่างมีนัยสำคัญ:

• DBCC CHECKDB และ CHECKTABLE: 1.27% อัตราการฟื้นตัวเฉลี่ย
• DataNumen: 92.6% อัตราการฟื้นตัว

ด้านล่างนี้เป็นการเปรียบเทียบการแข่งขันที่สมบูรณ์:

9.3 การฟื้นตัวจากการทุจริตที่ร้ายแรง

ความสามารถขั้นสูงสำหรับกรณีรุนแรง:

• การกู้คืนจากที่เก็บข้อมูลที่ได้รับความเสียหายทางกายภาพ
• การกู้คืนจากไดรฟ์ที่ฟอร์แมตหรือระบบที่ขัดข้อง
• กู้คืนจากดิสก์อิมเมจ ไฟล์สำรอง ไฟล์ดิสก์เครื่องเสมือน เทมโปrarไฟล์ y ฯลฯ

9.4 เมื่อใดจึงควรพิจารณาโซลูชันจากมืออาชีพ

• ไม่มีการสำรองข้อมูลล่าสุด
• DBCC CHECKDB ล้มเหลว
• สถานการณ์ทุจริตคอร์รัปชั่นร้ายแรง
• การจัดการกับข้อมูลทางธุรกิจที่สำคัญ
• เมื่อเวลาเป็นสิ่งสำคัญ
• เมื่อการฟื้นฟูสูงสุดเป็นสิ่งจำเป็น

10. คำถามที่พบบ่อย

11 ข้อสรุป

11.1 สรุปประเด็นสำคัญ

11.1.1 สรุปคำสั่ง DBCC CHECKDB ที่จำเป็น

เชี่ยวชาญไวยากรณ์ DBCC CHECKDB ขั้นพื้นฐานสำหรับการตรวจสอบฐานข้อมูลอย่างครอบคลุม ใช้ตัวเลือก NOINDEX และ PHYSICAL_ONLY สำหรับการเพิ่มประสิทธิภาพ และทำความเข้าใจ CHECKTABLE สำหรับ tarการตรวจสอบตาราง geted คำสั่งพื้นฐานเหล่านี้เป็นรากฐานของการบำรุงรักษาฐานข้อมูลเชิงรุก ช่วยให้สามารถตรวจจับการทุจริตได้ในระยะเริ่มต้นและตรวจสอบความสมบูรณ์ของระบบได้

11.1.2 คำเตือนเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดที่สำคัญ

ควรสำรองข้อมูลปัจจุบันไว้เสมอ ก่อนที่จะทำการตรวจสอบความสมบูรณ์ กำหนดเวลาการดำเนินการ CHECKDB เป็นประจำตามความสำคัญของฐานข้อมูล และใช้การตรวจสอบอัตโนมัติเพื่อแจ้งเตือนการเสียหายทันที โปรดจำไว้ว่าการป้องกันด้วยการตรวจสอบเป็นประจำดีกว่าวิธีการตอบสนอง และโซลูชันการกู้คืนข้อมูลโดยมืออาชีพจะมอบตัวเลือกการสำรองข้อมูลที่มีค่าเมื่อเครื่องมือมาตรฐานพิสูจน์แล้วว่าไม่เพียงพอ

11.2 เมื่อใดจึงควรใช้ DBCC CHECKDB เทียบกับโซลูชันขั้นสูง

ใช้ DBCC CHECKDB สำหรับการตรวจสอบความสมบูรณ์ตามปกติและการแก้ไขปัญหาการทุจริตเล็กน้อย ในขณะที่สงวนเครื่องมือการกู้คืนระดับมืออาชีพไว้สำหรับสถานการณ์การทุจริตร้ายแรงที่เกินกว่าความสามารถในการซ่อมแซมในตัว กรอบการตัดสินใจควรพิจารณาถึงความพร้อมใช้งานของการสำรองข้อมูล ความสำคัญของข้อมูล ข้อจำกัดด้านเวลา และความรุนแรงของการทุจริต ผู้ดูแลระบบฐานข้อมูลที่ประสบความสำเร็จจะรวมการตรวจสอบ CHECKDB เป็นประจำเข้ากับกลยุทธ์การสำรองข้อมูลที่ครอบคลุม และการรับรู้ถึงตัวเลือกการกู้คืนขั้นสูงเมื่อแนวทางมาตรฐานพิสูจน์แล้วว่าไม่เพียงพอ

11.3 รายการตรวจสอบสุขภาพประจำวันแบบรวดเร็วสำหรับ DBA

นอกเหนือจากการรัน DBCC CHECKDB แล้ว ควรรักษาสุขภาพฐานข้อมูลให้เหมาะสมด้วยแนวทางปฏิบัติประจำวันที่จำเป็นเหล่านี้:

1. ตรวจสอบความสมบูรณ์ของการสำรองข้อมูล

• ยืนยันการสำรองข้อมูลตามกำหนดเวลาสำเร็จแล้ว
• ใช้ RESTORE VERIFYONLY เพื่อตรวจสอบความสามารถในการอ่านข้อมูลสำรอง
• ให้แน่ใจว่าสำเนาจากนอกสถานที่ได้รับการซิงโครไนซ์และสามารถเข้าถึงได้

นอกจากนี้คุณยังสามารถรับข้อมูลเพิ่มเติมจาก คู่มือที่ครอบคลุมของเราเกี่ยวกับ SQL Server การสำรองข้อมูล.

2. ตรวจสอบสถานะความสอดคล้อง

• ตรวจสอบผลลัพธ์ DBCC CHECKDB อัตโนมัติจากการทำงานข้ามคืน
• การตรวจสอบ SQL Server บันทึกข้อผิดพลาดสำหรับคำเตือนการทุจริต
• ตรวจสอบข้อบกพร่องด้านความสมบูรณ์ทันที

3. ตรวจสอบสุขภาพเซิร์ฟเวอร์

• ตรวจสอบค่า CPU, หน่วยความจำ และ I/O ของดิสก์
• ตรวจสอบความพร้อมใช้งานของพื้นที่ tempdb
• ระบุกระบวนการที่ถูกบล็อกและแบบสอบถามที่รันยาวนาน

4. ติดตามกิจกรรมเดดล็อก

• ตรวจสอบกราฟเดดล็อกจากเหตุการณ์สุขภาพระบบ
• ระบุข้อสงสัยที่มีปัญหาและเพิ่มประสิทธิภาพร่วมกับทีมพัฒนา
• ติดตามจำนวนเหยื่อที่ได้รับผลกระทบและผลกระทบต่อธุรกิจ

การแจ้งเตือนที่สำคัญ

• หลีกเลี่ยงการย่อขนาดฐานข้อมูลบ่อยครั้ง – จะเพิ่มการกระจายตัวและลดประสิทธิภาพการทำงาน ควรลดขนาดหลังจากลบข้อมูลสำคัญเมื่อจำเป็นจริงๆ
• การตรวจสอบงานอัตโนมัติ ด้วย SQL Server งานตัวแทนหรือแผนการบำรุงรักษาพร้อมการแจ้งเตือนสำหรับปัญหาสำคัญ
• ทดสอบขั้นตอนการกู้คืนระบบหลังภัยพิบัติ รายสัปดาห์เพื่อให้แน่ใจว่าสามารถกู้คืนข้อมูลสำรองได้ และยังคงสามารถบรรลุเป้าหมายการกู้คืนได้

การรวมรายการตรวจสอบรายวันนี้เข้ากับการดำเนินการ DBCC CHECKDB ตามปกติ จะช่วยให้คุณสร้างการป้องกันที่ครอบคลุมสำหรับสภาพแวดล้อมฐานข้อมูลของคุณผ่านการตรวจสอบเชิงรุกและการตอบสนองต่อปัญหาอย่างทันท่วงที

12 อ้างอิง

1. Microsoft เรียนรู้ “DBCC CHECKDB (Transact-SQL)” SQL Server เอกสาร. บริษัท ไมโครซอฟท์ คอร์ปอเรชั่น
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn “แก้ไขข้อผิดพลาดความสอดคล้องของฐานข้อมูลที่รายงานโดย DBCC CHECKDB” SQL Server เอกสาร. บริษัท ไมโครซอฟท์ คอร์ปอเรชั่น
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors