Sao lưu phát hiện tham nhũng, nhưng CHECKDB không

Tôi có một cơ sở dữ liệu khi tôi chạy lệnh sao lưu

BACKUP DATABASE [MyDatabase] TO     
DISK =  'G:\Backup\MyDatabase_01_01_2018.bak'   
WITH    NOFORMAT, NOSKIP, COMPRESSION, INIT, BUFFERCOUNT = 100

Tôi nhận được thông báo lỗi

Msg 3043, Cấp 16, Trạng thái 1, Dòng 8
BACKUP 'MyDatabase' đã phát hiện lỗi trên trang (1: 745345) trong tệp 'F: \ Data \ MyDatabase_1.ndf'.
Msg 3013, Cấp 16, Tiểu bang 1, Dòng 8
BACKUP DATABASE đang chấm dứt bất thường.

Tôi đã chạy một CHECKDB đầy đủ nhưng nó đã hoạt động trở lại. Tôi đã nhận thấy rằng tùy chọn Xác minh trang đã được đặt thành KHÔNG (không phải do tôi thực hiện) vì vậy tôi đã thay đổi nó thành CHECKSUM và xây dựng lại tất cả các chỉ mục trong DB để ghi vào tất cả các trang và tạo tổng kiểm tra. Sau đó, bản sao lưu vẫn thất bại và checkdb vẫn hiển thị sạch (vì vậy không có thay đổi).

DBCC CHECKDB('MyDatabase') WITH NO_INFOMSGS, ALL_ERRORMSGS,
DATA_PURITY, EXTENDED_LOGICAL_CHECKS;

từ nhật ký SQL:

DBCC CHECKDB (MyDatabase) VỚI all_errormsgs, no_infomsgie, data_purity được thực hiện bởi xxx đã tìm thấy 0 lỗi và sửa 0 lỗi. Thời gian đã trôi qua: 0 giờ 21 phút 46 giây. Ảnh chụp nhanh cơ sở dữ liệu nội bộ có điểm phân chia LSN = 000ab776: 0000112f: 0001 và LSN đầu tiên = 000ab776: 0000112d: 0001.

Tôi đã chạy TRANG DBCC nhưng nó bị lỗi (thậm chí dường như không trả lại đúng trang ở vị trí đầu tiên). Tôi CÓ THỂ chạy nó với tùy chọn in 2 và nó trả về nhưng thật lòng tôi không biết tôi đang tìm gì ở đó.

DBCC PAGE ('MyDatabase',1,745345,3)

TRANG: (3: 513793)

ĐỆM:


BUF @ 0x00000003811F8280

bpage = 0x00000000F2D70000 bhash = 0x0000000000000000 bpageno = (1: 745345)
bdbid = 5 breferences = 0 bcputicks = 0
bsampleCount = 0 bUse1 = 44283 bstat = 0x809
blog = 0x5adb215a bnext = 0x0000000000000000          

TRANG CHỦ ĐẦU TƯ:


Trang @ 0x00000000F2D70000

m_pageId = (3: 513793) m_headerVersion = 1 m_type = 2
m_typeFlagBits = 0x4 m_level = 0 m_flagBits = 0x0
m_objId (AllocUnitId.idObj) = 1075937538 m_indexId (AllocUnitId.idInd) = 2
Siêu dữ liệu: AllocUnitId = 633462595911680 Siêu dữ liệu: PartitionId = 0
Siêu dữ liệu: IndexId = -1 Siêu dữ liệu: ObjectId = 0 m_prevPage = (3: 513795)
m_nextPage = (3: 513820) pminlen = 17 m_slotCnt = 426
m_freeCnt = 2 m_freeData = 7338 m_reservedCnt = 0
m_lsn = (608841: 643611: 411) m_xactReserved = 0 m_xdesId = (0: 0)
m_ghostRecCnt = 0 m_tornBits = 0 DB ID ID = 1

Tình trạng phân bổ

GAM (1: 511232) = SGAM ALLOCATED (1: 511233) = KHÔNG ĐƯỢC PHÉP     
PFS (1: 744096) = 0x40 ĐƯỢC PHÉP 0_PCT_FULL DIFF (1: 511238) = KHÔNG THAY ĐỔI
ML (1: 511239) = KHÔNG MIN_LOGGED      

Msg 2514, Cấp 16, Trạng thái 8, Dòng 20
Đã xảy ra lỗi TRANG DBCC: Siêu dữ liệu trang không hợp lệ - kết xuất kiểu 3 không thể.

Bất kỳ ý tưởng những gì tôi có thể thử tiếp theo? Phiên bản máy chủ là

select @@version

Máy chủ Microsoft SQL 2014 (SP2-CU11) (KB4077063) - 12.0.5579.0 (X64) 
    Ngày 21 tháng 2 năm 2018 12:19:47 
    Bản quyền (c) Tập đoàn Microsoft
    Phiên bản dành cho nhà phát triển (64-bit) trên Windows NT 6.3 (Bản dựng 9600 :) (Hypervisor)

Mức độ tương thích của DB là 100 (SQL 2008).

Câu trả lời này được lấy từ một vấn đề của bản tin SQLskills.com được viết bởi Paul Randal, về "một cơ sở dữ liệu sẽ không sao lưu với lỗi kiểm tra trang, nhưng đã thông qua DBCC CHECKDB".

Lần duy nhất điều này có thể xảy ra là khi một phạm vi là một phạm vi hỗn hợp (trong đó 8 trang trong phạm vi có thể được phân bổ cho 8 đơn vị phân bổ khác nhau - xem tại đây ) và một số trang được đánh dấu nhầm là được phân bổ bởi trang PFS có liên quan.

Khi điều đó xảy ra, DBCC CHECKDBsẽ không cố đọc các trang đó, vì nó xuất phát những trang cần đọc từ các trang IAM của đơn vị phân bổ (trang đầu tiên liệt kê các trang được phân bổ ở phạm vi hỗn hợp). Trường hợp này là một lỗ hổng trong DBCC CHECKDBlogic phát hiện tham nhũng.

[Bởi vì] DBCC CHECKDBkhông thể phát hiện ra tham nhũng, nó không thể thực hiện việc sửa chữa cần thiết để khắc phục chúng. Vì vậy, bằng cách sử dụng DBCC WRITEPAGE, tôi đã tìm ra các thay đổi cần thiết trong trạng thái phân bổ cho các trang được phân bổ sai, trực tiếp trong trang PFS và nó đã hoạt động!

Đây là một trường hợp cực kỳ hiếm gặp - phổ biến hơn nhiều là DBCC CHECKDB thất bại nhưng sao lưu sẽ thành công.

Theo tôi, độ phân giải của Paul vượt trội hơn cả việc xuất và nhập dữ liệu như bạn đã làm, vì vậy tôi nghĩ bạn đã làm đúng.