DBCC CHECKDB: Hướng dẫn đầy đủ về MS SQL Server Sức khỏe cơ sở dữ liệu (2026)

DBCC CHECKDB là SQL ServerCông cụ toàn vẹn cơ sở dữ liệu chính. Tìm hiểu cách sử dụng công cụ này với các ví dụ, khắc phục lỗi và tối ưu hóa hiệu suất.

3. Chạy DBCC CHECKDB: từng bước

3.1 điều kiện tiên quyết

Dưới đây là danh sách kiểm tra trước khi thực hiện bất kỳ hoạt động DBCC CHECKDB nào:

• Sao lưu cơ sở dữ liệu hoàn chỉnh – Tạo bản sao lưu đầy đủ trước khi chạy kiểm tra tính toàn vẹn như một mạng lưới an toàn của bạn nếu phát hiện lỗi hoặc cần phải thực hiện các hoạt động sửa chữa.
• Quyền hợp lệ – Bạn cần có quyền sysadmin hoặc db_owner để thực thi lệnh DBCC CHECKDB
• Tài nguyên hệ thống đủ:
  • Bộ nhớ: 25% kích thước cơ sở dữ liệu
  • Không gian Tempdb: 10-15% kích thước cơ sở dữ liệu
  • CPU: Khả dụng 50-70% trong quá trình bảo trì
  • I/O: Dự kiến ​​các hoạt động đọc nặng
• Khả năng truy cập cơ sở dữ liệu – Xác minh rằng cơ sở dữ liệu của bạn có thể truy cập được và không ở trạng thái bị hạn chế, vì CHECKDB yêu cầu quyền truy cập đọc vào tất cả các trang cơ sở dữ liệu

3.2 Lệnh cơ bản

Các most Lệnh DBCC CHECKDB cơ bản bao gồm ba biến thể phổ biến:

(1) Kiểm tra cơ sở dữ liệu hiện tại (không có tham số):

DBCC CHECKDB

(2) Kiểm tra cơ sở dữ liệu theo tên:

DBCC CHECKDB ('YourDatabaseName')

(3) Kiểm tra cơ sở dữ liệu theo ID:

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

Lệnh cơ bản này thực hiện kiểm tra toàn bộ tính toàn vẹn của cơ sở dữ liệu được chỉ định, kiểm tra tất cả các bảng, chỉ mục và cấu trúc hệ thống. Đối với các cơ sở dữ liệu có tên chuẩn không chứa khoảng trắng, bạn có thể bỏ dấu ngoặc kép. Lệnh sẽ chạy cho đến khi hoàn tất, hiển thị thông báo tiến trình và kết quả cuối cùng. Cú pháp cơ bản này hoạt động hoàn hảo cho các cơ sở dữ liệu nhỏ hơn hoặc khi bạn có nhiều thời gian bảo trì.

Dưới đây là ảnh chụp màn hình chạy DBCC CHECKDB trong SQL Server Xưởng quản lý (SSMS):

3.3 Tùy chọn hoàn chỉnh

Dưới đây là các tùy chọn đầy đủ cho DBCC CHECKDB:

Phân loại	Tùy chọn	Mô tả Chi tiết	Ví dụ về DBCC CHECKDB
Tùy chọn sửa chữa	REPAIR_REBUILD	Sửa chữa mà không mất dữ liệu (ví dụ, xây dựng lại chỉ mục)	DBCC CHECKDB ('MyDB', REPAIR_REBUILD)
	REPAIR_FAST	Không sửa chữa. Chỉ tương thích ngược	DBCC CHECKDB ('MyDB', REPAIR_FAST)
	REPAIR_ALLOW_DATA_LOSS	Sửa chữa tất cả các lỗi (có thể gây mất dữ liệu)	DBCC CHECKDB ('CorruptDB', REPAIR_ALLOW_DATA_LOSS)
Kiểm soát phạm vi	NOINDEX	Bỏ qua các kiểm tra chỉ mục không được nhóm	DBCC CHECKDB ('LargeDB', NOINDEX)
	PHYSICAL_ONLY	Chỉ kiểm tra tính toàn vẹn của bộ lưu trữ vật lý (trang/bản ghi)	DBCC CHECKDB ('ProdDB', PHYSICAL_ONLY)
	DATA_PURITY	Kiểm tra lỗi giá trị cột logic (ví dụ: ngày không hợp lệ)	DBCC CHECKDB ('OldDB', DATA_PURITY)
	EXTENDED_LOGICAL_CHECKS	Kiểm tra logic sâu (lượt xem được lập chỉ mục, chỉ mục XML/không gian)	DBCC CHECKDB ('ComplexDB', EXTENDED_LOGICAL_CHECKS)
Kiểm soát đầu ra	ALL_ERRORMSGS	Hiển thị tất cả lỗi (mặc định: 200 cho mỗi đối tượng)	DBCC CHECKDB ('MyDB', ALL_ERRORMSGS)
	NO_INFOMSGS	Ẩn tin nhắn thông tin	DBCC CHECKDB ('MyDB', NO_INFOMSGS)
HIỆU QUẢ	TABLOCK	Sử dụng khóa bảng (giảm mức sử dụng TempDB nhưng chặn ghi)	DBCC CHECKDB ('BigDB', TABLOCK)
	MAXDOP = number	Ghi đè cài đặt song song	DBCC CHECKDB ('MyDB', MAXDOP = 2)
Tiện ích	ESTIMATEONLY	Ước tính dung lượng TempDB cần thiết. (không kiểm tra thực tế)	DBCC CHECKDB ('MyDB', ESTIMATEONLY)

4. Hiểu kết quả của bạn

DBCC CHECKDB sẽ tạo ra các kết quả khác nhau tùy thuộc vào việc thực thi thành công hay không. Chúng ta hãy cùng giải thích chi tiết.

4.1 Thực hiện CHECKDB hoàn tất thành công

Nếu quá trình thực thi DBCC CHECKDB hoàn tất thành công, nó sẽ báo cáo các loại kết quả khác nhau tùy thuộc vào trạng thái hoạt động của cơ sở dữ liệu.

4.1.1 Không tìm thấy vấn đề nào

Nếu DBCC CHECKDB không tìm thấy bất kỳ vấn đề nào, bạn sẽ thấy kết quả tương tự như sau:

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

Kết quả này cho thấy cơ sở dữ liệu của bạn duy trì tính toàn vẹn hoàn hảo trên tất cả các cấu trúc được kiểm tra.

4.1.2 Lỗi hỏng được tìm thấy

Bất cứ khi nào DBCC CHECKDB phát hiện lỗi hỏng, nó sẽ báo cáo thông báo lỗi có cấu trúc sau:
Hướng dẫn mức độ nghiêm trọng:

• Mức 16-19: Lỗi có thể sửa được bởi người dùng, thường là lỗi nhỏ
• Mức 20-24: Lỗi hệ thống, hỏng hóc nghiêm trọng cần xử lý ngay
• Cấp độ 25: Lỗi nghiêm trọng, cơ sở dữ liệu có thể không truy cập được

Các lỗi phổ biến bao gồm:

• Lỗi kiểm tra tổng trang (tin nhắn 824)
• Lỗi phân bổ (tin nhắn 8928)
• Các vấn đề về tính nhất quán của chỉ mục (tin nhắn 8964)

Hiểu được cấu trúc tin nhắn giúp ưu tiên các hành động phản hồi và xác định các chiến lược phục hồi phù hợp.

4.1.3 Thông báo thông tin và cảnh báo chung

Không phải tất cả đầu ra DBCC CHECKDB đều chỉ ra các vấn đề nghiêm trọng. Nó cũng có thể đưa ra một số thông báo thông tin và cảnh báo, bao gồm:

• Sửa chữa các câu lệnh – Tin nhắn gợi ý lệnh sửa chữa để khắc phục các sự cố nhỏ
• Cảnh báo phân bổ – Cảnh báo về việc phân bổ không gian không ảnh hưởng đến việc truy cập dữ liệu
• Khuyến nghị về hiệu suất – Đề xuất duy trì và tối ưu hóa chỉ mục
• Thông báo thông tin – Tin nhắn trạng thái chung không yêu cầu hành động ngay lập tức

Những thông báo này cung cấp hướng dẫn bảo trì có giá trị trong khi phân biệt giữa lỗi nghiêm trọng cần hành động ngay lập tức và các vấn đề nhỏ có thể được giải quyết trong thời gian bảo trì thường xuyên.

Ví dụ về thông báo cảnh báo:

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 Hủy bỏ thực hiện CHECKDB

Nếu CHECKDB bị dừng trong quá trình thực thi vì nhiều lý do, nó sẽ báo cáo thông báo lỗi và thêm nhật ký lỗi với mã trạng thái bên dưới:

Tiểu bang	Mô tả Chi tiết
0	Đã phát sinh lỗi số 8930. Lỗi này cho biết có sự cố hỏng hóc trong siêu dữ liệu đã chấm dứt lệnh DBCC.
1	Đã phát sinh lỗi số 8967. Có lỗi DBCC nội bộ.
2	Đã xảy ra lỗi trong quá trình sửa chữa cơ sở dữ liệu ở chế độ khẩn cấp.
3	Điều này cho thấy có sự hỏng hóc trong siêu dữ liệu dẫn đến kết thúc lệnh DBCC.
4	Đã phát hiện vi phạm xác nhận hoặc truy cập.
5	Đã xảy ra lỗi không xác định khiến lệnh DBCC bị chấm dứt.

Ví dụ về thông báo lỗi:

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.

or

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'.

Ví dụ về nhật ký lỗi:

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.

Trong trường hợp như vậy, bạn có thể thử các tùy chọn nâng cao thay thế như DataNumen SQL Recovery để khắc phục lỗi trong cơ sở dữ liệu của bạn.

5. Sửa lỗi tham nhũng

5.1 Sao lưu và khôi phục: Cách khắc phục an toàn nhất

Khi DBCC CHECKDB xác định lỗi hỏng, khôi phục từ bản sao lưu sạch sẽ là giải pháp an toàn nhất vàost giải pháp đáng tin cậy. Cách tiếp cận này đảm bảo tính toàn vẹn của dữ liệu trong khi loại bỏ các nguyên nhân gây hỏng hóc tiềm ẩn. Trước khi khôi phục, hãy xác minh tính toàn vẹn của bản sao lưu bằng KHÔI PHỤC CHỈ XÁC MINH lệnh và xem xét các tùy chọn khôi phục tại thời điểm để giảm thiểu mất dữ liệu. Ghi lại chi tiết về lỗi để phân tích nguyên nhân gốc rễ, vì các sự cố phần cứng hoặc lỗi phần mềm có thể cần được chú ý thêm để ngăn ngừa tái diễn.

5.2 Giải pháp chống tham nhũng cấp trang

Đối với lỗi trang bị cô lập ảnh hưởng đến các phần dữ liệu nhỏ, SQL Server Phiên bản Enterprise cung cấp khả năng khôi phục trang để sửa chữa các trang bị hỏng cụ thể mà không cần khôi phục toàn bộ cơ sở dữ liệu. Kỹ thuật tiên tiến này yêu cầu mô hình khôi phục đầy đủ và bản sao lưu nhật ký hiện tại.

Quy trình khôi phục trang từng bước:

1. Xác định trang bị hỏng từ thông báo lỗi CHECKDB (ví dụ, trang 1:256)
2. Sao lưu nhật ký hiện tại để nắm bắt các giao dịch gần đây:

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

3. Khôi phục trang bị hỏng từ most sao lưu đầy đủ gần đây:

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

4. Áp dụng sao lưu khác biệt (nếu có sẵn):

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

5. Áp dụng tất cả các bản sao lưu nhật ký theo trình tự, bao gồm cả trình tự vừa tạo:

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. Sao lưu nhật ký cuối cùng và khôi phục để đưa trang hiện tại:

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

Giải pháp thay thế cho dữ liệu không quan trọng: Nếu lỗi hỏng ảnh hưởng đến dữ liệu không quan trọng, bạn có thể xuất các hàng không bị ảnh hưởng sang các bảng mới trước khi xây dựng lại các cấu trúc bị hỏng:

-- 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 Sửa lỗi nhanh hỏng chỉ mục

Hỏng chỉ mục thường phản hồi tốt với các hoạt động xây dựng lại cấu trúc chỉ mục mà không ảnh hưởng đến dữ liệu bảng cơ bản:

ALTER INDEX ALL ON YourTable REBUILD

Cách tiếp cận này đặc biệt hiệu quả đối với tình trạng hỏng chỉ mục không theo cụm, vì việc xây dựng lại sẽ tạo lại các trang chỉ mục từ dữ liệu bảng nguồn, do đó loại bỏ hiệu quả tình trạng hỏng trong khi vẫn bảo toàn mọi thông tin gốc.

6. Sử dụng REPAIR_REBUILD và REPAIR_ALLOW_DATA_LOSS

Nếu tất cả các phương pháp trước đó đều không thành công hoặc không khả thi, bạn có thể sử dụng tùy chọn REPAIR_REBUILD và REPAIR_ALLOW_DATA_LOSS để sửa chữa cơ sở dữ liệu.

6.1 REPAIR_REBUILD (Tùy chọn an toàn hơn):

• Dùng cho: Chỉ mục bị hỏng và lỗi phân bổ nhỏ
• An toàn dữ liệu: Cố gắng sửa lỗi hỏng mà không xóa dữ liệu
• Mức độ rủi ro: Thấp – không dự kiến ​​mất dữ liệu
• Các tình huống điển hình: Hỏng chỉ mục không nhóm, các vấn đề siêu dữ liệu nhỏ
• Ví dụ lệnh: DBCC CHECKDB('YourDB', REPAIR_REBUILD)

6.2 REPAIR_ALLOW_DATA_LOS (Giải pháp cuối cùng):

• Dùng cho: Hỏng hóc nghiêm trọng khi không có bản sao lưu
• An toàn dữ liệu: Có thể xóa dữ liệu bị hỏng để khôi phục chức năng cơ sở dữ liệu
• Mức độ rủi ro: Cao – có thể mất dữ liệu vĩnh viễn
• Các tình huống điển hình: Lỗi trang, hỏng bảng hệ thống, lỗi chuỗi phân bổ
• Ví dụ lệnh: DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS)

6.3 Các biện pháp thực hành tốt nhất cho các tùy chọn này:

• Luôn luôn kiểm tra sửa chữa các hoạt động trên bản sao cơ sở dữ liệu khi có thể
• Luôn luôn sao lưu trước khi chạy các tùy chọn này
• Ghi lại tất cả các thay đổi cho mục đích tuân thủ và khắc phục sự cố
• Đặt cơ sở dữ liệu ở chế độ người dùng đơn trước khi chạy các hoạt động sửa chữa

Thông thường, chúng ta nên thử SỬA_LẠI_XÂY_DỰNG tùy chọn đầu tiên. Nếu nó không thành công, hãy thử REPAIR_ALLOW_DATA_LOSS tùy chọn.

6.4 Kết quả REPAIR_ALLOW_DATA_LOS

6.4.1 Sửa chữa thành công khi mất dữ liệu

Đôi khi REPAIR_ALLOW_DATA_LOSS tùy chọn sẽ thành công, nhưng một số dữ liệu là lost sau khi sửa chữa.

Dưới đây là một số tin nhắn mẫu:

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.

Điều này là do DBCC CHECKDB sửa cơ sở dữ liệu bằng cách loại bỏ một số bản ghi bị hỏng, nhưng thực tế, most trong số chúng vẫn có thể được phục hồi thông qua DataNumen SQL Recovery.

Các tập tin mẫu:

SQL Server phiên bản	Tập tin MDF bị hỏng	Tệp MDF được cố định bởi DataNumen SQL Recovery
SQL Server 2014	Lỗi10_1.mdf (Tin nhắn 8909 theo sau là Tin nhắn 8939) (600 bản ghi lost với SỬA_PHÒNG_CHO_MẤT_DỮ_LÝ)	Error10_1_fixed.mdf (Không có hồ sơ lost)
SQL Server 2014	Lỗi10_2.mdf (Tin nhắn 8909 theo sau là Tin nhắn 8939) (6000 bản ghi (50%) lost với SỬA_PHÒNG_CHO_MẤT_DỮ_LÝ)	Error10_2_fixed.mdf (Chỉ có 100 bản ghi lost)
SQL Server 2014	Error7.mdf (100 bản ghi lost với SỬA_PHÒNG_CHO_MẤT_DỮ_LÝ)	Error7_fixed.mdf (Chỉ có một bản ghi lost)

6.4.2 Sửa chữa lỗi – Cân nhắc giải pháp chuyên nghiệp

If REPAIR_ALLOW_DATA_LOSS nếu không thành công, nó sẽ đưa ra một hoặc nhiều thông báo lỗi.

Dưới đây là một số ví dụ:

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.

Trong những trường hợp này, bạn cần sử dụng giải pháp chuyên nghiệp như DataNumen SQL Recovery để sửa cơ sở dữ liệu của bạn.

Các tập tin mẫu

SQL Server phiên bản	Tập tin MDF bị hỏng	Tệp MDF được cố định bởi DataNumen SQL Recovery
SQL Server 2014	Lỗi1_3.mdf (Tin nhắn đơn 824)	Error1_3_fixed.mdf
SQL Server 2014	Lỗi1_1.mdf (Lỗi tin nhắn liên tục 824)	Lỗi1_1_fixed.mdf
SQL Server 2014	Lỗi1_2.mdf ((Tin nhắn 824 tiếp theo là Tin nhắn 7909)	Error1_2_fixed.mdf
SQL Server 2014	Lỗi4_1.mdf (Tin nhắn 8992 tiếp theo là Tin nhắn 3852)	Error4_1_fixed.mdf
SQL Server 2014	Lỗi4_2.mdf (Tin nhắn 8992 tiếp theo là Tin nhắn 3852)	Error4_2_fixed.mdf
SQL Server 2014	Lỗi5.mdf (Tin nhắn 8945)	Error5_fixed.mdf
SQL Server 2014	Lỗi6.mdf (Tin nhắn 2510)	Error6_fixed.mdf
SQL Server 2014	Lỗi2.mdf (Tin nhắn 2575)	Error2_fixed.mdf
SQL Server 2014	Lỗi11.mdf (Tin nhắn 8905)	Error11_fixed.mdf
SQL Server 2014	Lỗi3.mdf (Tin nhắn 5028)	Error3_fixed.mdf
SQL Server 2014	Error8.mdf (Tin nhắn 5125)	Error8_fixed.mdf
SQL Server 2014	Lỗi9.mdf (Tin nhắn 3313)	Error9_fixed.mdf

7. Thực tiễn tốt nhất

7.1 Lên lịch các hoạt động CHECKDB thường xuyên

Triển khai thực thi DBCC CHECKDB hàng tuần cho các cơ sở dữ liệu sản xuất quan trọng, với các lần kiểm tra hàng ngày cho các hệ thống giao dịch cao. Lên lịch hoạt động trong thời gian sử dụng thấp để giảm thiểu tác động đến hiệu suất và cân nhắc luân phiên giữa các lần kiểm tra đầy đủ và các tùy chọn PHYSICAL_ONLY dựa trên kích thước cơ sở dữ liệu và cửa sổ bảo trì. Lên lịch tự động thông qua SQL Server Agent đảm bảo thực hiện nhất quán trong khi cung cấp khả năng giám sát và cảnh báo tập trung.

7.2 Quản lý tác động hiệu suất

Các hoạt động DBCC CHECKDB tiêu tốn nhiều tài nguyên hệ thống, có khả năng ảnh hưởng đến hoạt động đồng thời của người dùng. Theo dõi việc sử dụng CPU, mức tiêu thụ bộ nhớ và I/O đĩa trong quá trình kiểm tra để hiểu các mẫu tác động đến hiệu suất. Cân nhắc sử dụng tùy chọn NOINDEX cho các lần kiểm tra thường xuyên, dành quyền xác thực đầy đủ cho các cửa sổ bảo trì hàng tháng. Triển khai các phần mở rộng thời gian chờ truy vấn và các chiến lược giao tiếp với người dùng để quản lý kỳ vọng trong các giai đoạn kiểm tra tính toàn vẹn.

7.3 Lập kế hoạch cửa sổ bảo trì

Phối hợp lịch trình DBCC CHECKDB với các hoạt động bảo trì khác như hoạt động sao lưu, xây dựng lại chỉ mục và cập nhật số liệu thống kê. Tránh chồng chéo các hoạt động tốn nhiều tài nguyên có thể gây ra sự suy giảm hiệu suất hoặc sự cố hết thời gian. Lên kế hoạch cho các cửa sổ bảo trì dựa trên dự báo tăng trưởng kích thước cơ sở dữ liệu, đảm bảo đủ thời gian để xác minh tính toàn vẹn hoàn toàn khi khối lượng dữ liệu tăng lên.

7.4 Giám sát và cảnh báo tự động

Thiết lập SQL Server Agent cảnh báo để thông báo ngay cho quản trị viên khi DBCC CHECKDB xác định được lỗi. Triển khai các giải pháp phân tích nhật ký trích xuất và phân loại kết quả kiểm tra tính toàn vẹn, cho phép phân tích xu hướng và xác định vấn đề chủ động. Tạo các quy trình leo thang xác định khung thời gian phản hồi và nhân sự chịu trách nhiệm cho các mức độ lỗi khác nhau.

8. DBCC CHECKTABLE: Giải pháp thay thế nhẹ

8.1 Khi nào sử dụng CHECKTABLE thay vì CHECKDB

DBCC CHECKTABLE cung cấp kiểm tra tính toàn vẹn tập trung cho các bảng riêng lẻ, làm cho nó trở nên lý tưởng cho targeted khắc phục sự cố và bảo trì các đối tượng cơ sở dữ liệu cụ thể. Sử dụng CHECKTABLE khi điều tra các vấn đề về hiệu suất với các bảng cụ thể, xác thực các bảng kinh doanh quan trọng giữa các lần kiểm tra cơ sở dữ liệu đầy đủ hoặc khi hạn chế về thời gian ngăn cản việc xác thực cơ sở dữ liệu hoàn chỉnh. Cách tiếp cận này chứng tỏ đặc biệt có giá trị trong các cơ sở dữ liệu lớn, nơi các hoạt động CHECKDB đầy đủ vượt quá các cửa sổ bảo trì khả dụng.

8.2 Cú pháp và ví dụ của DBCC CHECKTABLE

Lệnh CHECKTABLE cơ bản tarlấy các bảng cụ thể:

DBCC CHECKTABLE('YourTable')

Giống như CHECKDB, CHECKTABLE hỗ trợ nhiều tùy chọn khác nhau bao gồm NOINDEX để tối ưu hóa hiệu suất và các tham số sửa chữa để giải quyết lỗi. Bạn cũng có thể chỉ định tên lược đồ để xác định bảng chính xác:

DBCC CHECKTABLE('SchemaName.TableName', NOINDEX)

T tarPhương pháp tiếp cận geted cho phép xác minh tính toàn vẹn chi tiết trong khi vẫn duy trì hiệu suất hệ thống trong giờ làm việc.

8.3 Lợi ích về hiệu suất cho cơ sở dữ liệu lớn

Các hoạt động CHECKTABLE hoàn thành nhanh hơn đáng kể so với các kiểm tra cơ sở dữ liệu đầy đủ, cho phép xác minh tính toàn vẹn thường xuyên hơn của các bảng quan trọng. Phương pháp này cho phép xác thực hàng ngày các bảng kinh doanh thiết yếu trong khi dành riêng các hoạt động CHECKDB toàn diện cho các lịch trình hàng tuần hoặc hàng tháng. Việc giảm mức tiêu thụ tài nguyên khiến CHECKTABLE phù hợp để thực hiện môi trường sản xuất với tác động tối thiểu đến người dùng.

9. Khi CHECKDB Thất bại

DBCC CHECKDB sẽ không thành công trong nhiều trường hợp, bao gồm:

• Thực hiện DBCC CHECKDB chấm dứt bất thường
• Việc thực hiện DBCC CHECKDB hoàn tất thành công, nhưng các phương án sửa chữa không thể sửa chữa cơ sở dữ liệu.

Trong những trường hợp này, chúng ta cần một công cụ chuyên nghiệp hơn để giúp khắc phục lỗi trong cơ sở dữ liệu.

9.1 Giới thiệu về DataNumen SQL Recovery

DataNumen SQL Recovery cung cấp các khả năng tiên tiến hơn:

• Tỷ lệ phục hồi tốt nhất trong ngành công nghiệp.
• Khôi phục các tập tin cơ sở dữ liệu bị hỏng nghiêm trọng.
• Khôi phục tất cả các đối tượng cơ sở dữ liệu, bao gồm bảng, chỉ mục, chế độ xem, kích hoạt, quy tắc và mặc định.
• Khôi phục các thủ tục được lưu trữ, hàm vô hướng, hàm có giá trị bảng nội tuyến và hàm có giá trị bảng đa câu lệnh.
• Khôi phục các bản ghi đã xóa vĩnh viễn.
• Giải mã các đối tượng được mã hóa trong SQL Server cơ sở dữ liệu.
• Sửa chữa hàng loạt các tập tin MDF.
• Tùy chọn sửa chữa toàn diện.
• Ghi nhật ký và báo cáo nâng cao.
• Hỗ trợ cho tất cả SQL Server phiên bản.
• Sẵn có hỗ trợ kỹ thuật
• Cập nhật và cải tiến thường xuyên

9.2 So sánh tỷ lệ thành công

Tỷ lệ phục hồi thành công khác nhau đáng kể:

• DBCC CHECKDB & CHECKTABLE: 1.27% tỷ lệ thu hồi trung bình
• DataNumen: 92.6% Tỷ lệ thu hồi

Dưới đây là bảng so sánh cạnh tranh đầy đủ:

9.3 Phục hồi sau tham nhũng nghiêm trọng

Khả năng nâng cao cho các trường hợp nghiêm trọng:

• Phục hồi từ bộ lưu trữ bị hư hỏng vật lý
• Phục hồi từ ổ đĩa đã định dạng hoặc hệ thống bị hỏng
• Phục hồi từ ảnh đĩa, tệp sao lưu, tệp đĩa máy ảo, temporarcác tập tin y, v.v.

9.4 Khi nào nên cân nhắc các giải pháp chuyên nghiệp

• Không có bản sao lưu gần đây
• DBCC CHECKDB không thành công
• Kịch bản tham nhũng nghiêm trọng
• Xử lý dữ liệu kinh doanh quan trọng
• Khi thời gian là quan trọng
• Khi sự phục hồi tối đa là cần thiết

10. Câu hỏi thường gặp

11. Phần kết luận

11.1 Tóm tắt các điểm chính

11.1.1 Tóm tắt các lệnh DBCC CHECKDB cần thiết

Nắm vững cú pháp DBCC CHECKDB cơ bản để kiểm tra cơ sở dữ liệu toàn diện, sử dụng các tùy chọn NOINDEX và PHYSICAL_ONLY để tối ưu hóa hiệu suất và hiểu CHECKTABLE để tarXác minh bảng đã nhận. Các lệnh cơ bản này tạo thành nền tảng cho việc bảo trì cơ sở dữ liệu chủ động, cho phép phát hiện sớm tình trạng hỏng hóc và giám sát tính toàn vẹn có hệ thống.

11.1.2 Nhắc nhở về các biện pháp thực hành tốt nhất quan trọng

Luôn duy trì các bản sao lưu hiện tại trước khi chạy kiểm tra tính toàn vẹn, lên lịch các hoạt động CHECKDB thường xuyên dựa trên mức độ quan trọng của cơ sở dữ liệu và triển khai giám sát tự động để cảnh báo lỗi ngay lập tức. Hãy nhớ rằng phòng ngừa thông qua giám sát thường xuyên vượt trội hơn các phương pháp phản ứng và các giải pháp phục hồi chuyên nghiệp cung cấp các tùy chọn sao lưu có giá trị khi các công cụ tiêu chuẩn tỏ ra không đủ.

11.2 Khi nào sử dụng DBCC CHECKDB so với các giải pháp nâng cao

Sử dụng DBCC CHECKDB để giám sát tính toàn vẹn thường xuyên và giải quyết lỗi nhỏ, đồng thời dành riêng các công cụ phục hồi chuyên nghiệp cho các tình huống lỗi nghiêm trọng vượt quá khả năng sửa chữa tích hợp. Khung quyết định nên xem xét tính khả dụng của bản sao lưu, tính quan trọng của dữ liệu, hạn chế về thời gian và mức độ lỗi. Các quản trị viên cơ sở dữ liệu thành công kết hợp giám sát CHECKDB thường xuyên với các chiến lược sao lưu toàn diện và nhận thức về các tùy chọn phục hồi nâng cao khi các phương pháp tiếp cận tiêu chuẩn tỏ ra không đủ.

11.3 Danh sách kiểm tra sức khỏe hàng ngày nhanh chóng cho DBA

Ngoài việc chạy DBCC CHECKDB, hãy duy trì tình trạng cơ sở dữ liệu tối ưu bằng các biện pháp thiết yếu hàng ngày sau:

1. Xác minh tính toàn vẹn của bản sao lưu

• Xác nhận sao lưu theo lịch trình đã hoàn tất thành công
• Sử dụng RESTORE VERIFYONLY để xác minh khả năng đọc bản sao lưu
• Đảm bảo các bản sao bên ngoài được đồng bộ hóa và có thể truy cập được

Bạn cũng có thể lấy thêm thông tin từ hướng dẫn toàn diện của chúng tôi về SQL Server sao lưu.

2. Xem lại trạng thái nhất quán

• Kiểm tra kết quả DBCC CHECKDB tự động từ các lần chạy qua đêm
• Màn Hình SQL Server nhật ký lỗi cảnh báo hỏng hóc
• Điều tra ngay lập tức bất kỳ lỗi toàn vẹn nào

3. Theo dõi tình trạng máy chủ

• Kiểm tra số liệu I/O của CPU, bộ nhớ và đĩa
• Xác minh tính khả dụng của không gian tempdb
• Xác định các tiến trình bị chặn và các truy vấn chạy lâu

4. Theo dõi hoạt động bế tắc

• Xem lại biểu đồ bế tắc từ các sự kiện sức khỏe hệ thống
• Xác định các truy vấn có vấn đề và tối ưu hóa với các nhóm phát triển
• Theo dõi số lượng nạn nhân của tình trạng bế tắc và tác động đến doanh nghiệp

Nhắc nhở quan trọng

• Tránh việc thu hẹp cơ sở dữ liệu thường xuyên – nó làm tăng phân mảnh và làm giảm hiệu suất. Chỉ thu nhỏ sau khi xóa dữ liệu lớn khi thực sự cần thiết.
• Tự động hóa các tác vụ giám sát sử dụng SQL Server Công việc của đại lý hoặc kế hoạch bảo trì có cảnh báo về các vấn đề quan trọng.
• Kiểm tra các thủ tục phục hồi thảm họa hàng tuần để đảm bảo các bản sao lưu có thể khôi phục được và các mục tiêu phục hồi vẫn có thể đạt được.

Bằng cách kết hợp danh sách kiểm tra hàng ngày này với các hoạt động DBCC CHECKDB thường xuyên, bạn sẽ tạo ra khả năng bảo vệ toàn diện cho môi trường cơ sở dữ liệu của mình thông qua giám sát chủ động và phản hồi sự cố nhanh chóng.

12. Tài liệu tham khảo

1. Microsoft Learn. “DBCC CHECKDB (Transact-SQL).” SQL Server Tài liệu. Tập đoàn Microsoft.
   https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver17
2. Microsoft Learn. “Khắc phục lỗi thống nhất cơ sở dữ liệu được DBCC CHECKDB báo cáo.” SQL Server Tài liệu. Tập đoàn Microsoft.
   https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/database-file-operations/troubleshoot-dbcc-checkdb-errors