Kopia zapasowa wykrywa uszkodzenie, ale CHECKDB nie

Mam bazę danych, w której po uruchomieniu polecenia tworzenia kopii zapasowej

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

Pojawia się komunikat o błędzie

Msg 3043, poziom 16, stan 1, wiersz 8
BACKUP „MyDatabase” wykrył błąd na stronie (1: 745345) w pliku „F: \ Data \ MyDatabase_1.ndf”.
Msg 3013, poziom 16, stan 1, wiersz 8
KOPIA ZAPASOWA kończy się nieprawidłowo.

Uruchomiłem pełny plik CHECKDB, ale wrócił czysty. Zauważyłem, że opcja Weryfikacja strony została ustawiona na BRAK (nie moja), więc zmieniłem ją na CHECKSUM i przebudowałem wszystkie indeksy w DB, aby umożliwić zapisywanie na wszystkich stronach i generowanie sum kontrolnych. Po tym tworzenie kopii zapasowej nadal nie powiedzie się, a checkdb nadal pokazuje czyste (więc bez zmian).

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

z dziennika SQL:

DBCC CHECKDB (MyDatabase) Z all_errormsgs, no_infomsgs, data_purity wykonane przez xxx znaleziono 0 błędów i naprawiono 0 błędów. Upływający czas: 0 godzin 21 minut 46 sekund. Migawka wewnętrznej bazy danych ma punkt podziału LSN = 000ab776: 0000112f: 0001 i pierwszy LSN = 000ab776: 0000112d: 0001.

Uruchomiłem DBCC PAGE, ale to błędy (nawet nie wydaje się, że zwraca właściwą stronę). Mogę uruchomić go z opcją drukowania 2 i zwraca, ale szczerze mówiąc, nie wiem, czego tam szukam.

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

STRONA: (3: 513793)

BUFOR:


BUF @ 0x00000003811F8280

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

NAGŁÓWEK:


Strona @ 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
Metadane: AllocUnitId = 633462595911680 Metadane: PartitionId = 0
Metadane: IndexId = -1 Metadane: 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 Frag ID = 1

Status przydziału

GAM (1: 511232) = PRZYDZIELONY SGAM (1: 511233) = NIE PRZYZNANY     
PFS (1: 744096) = 0x40 PRZYDZIELONY 0_PCT_FULL DIFF (1: 511238) = NIEZMIENIONY
ML (1: 511239) = NOT MIN_LOGGED      

Msg 2514, poziom 16, stan 8, wiersz 20
Wystąpił błąd STRONY DBCC: Nieprawidłowe metadane strony - styl zrzutu 3 niemożliwy.

Jakieś pomysły, co mógłbym wypróbować dalej? Wersja serwera to

select @@version

Microsoft SQL Server 2014 (SP2-CU11) (KB4077063) - 12.0.5579.0 (X64) 
    21 lutego 2018 12:19:47 
    Prawa autorskie (c) Microsoft Corporation
    Wersja dla programistów (64-bitowa) w systemie Windows NT 6.3 (kompilacja 9600:) (Hypervisor)

Poziom zgodności DB wynosi 100 (SQL 2008).

Ta odpowiedź pochodzi z wydania biuletynu SQLskills.com napisanego przez Paula Randala na temat „bazy danych, która nie powiodła się kopia zapasowa z błędami sumy kontrolnej strony, ale przeszła DBCC CHECKDB”.

Może się to zdarzyć tylko wtedy, gdy zakres jest zakresem mieszanym (gdzie 8 stron w zakresie można przypisać potencjalnie 8 różnym jednostkom alokacji - patrz tutaj ), a niektóre strony są błędnie oznaczone jako przydzielone przez odpowiednią stronę PFS.

Gdy tak się stanie, DBCC CHECKDBnie będzie próbował odczytać tych stron, ponieważ wyprowadza strony do odczytania ze stron IAM jednostki alokacji (pierwsza z nich zawiera listę stron przydzielonych z mieszanego zakresu). Ten przypadek stanowi lukę w DBCC CHECKDBlogice wykrywania uszkodzeń.

[Ponieważ] DBCC CHECKDBnie mógł wykryć uszkodzenia, nie było możliwe wykonanie napraw niezbędnych do ich naprawy. Korzystając z tego DBCC WRITEPAGE, opracowałem niezbędne zmiany w statusie alokacji dla błędnie przydzielonych stron, bezpośrednio na stronie PFS, i zadziałało!

To był niezwykle rzadki przypadek - o wiele częściej zdarza się, że DBCC CHECKDB awaria, ale tworzenie kopii zapasowej się powiedzie.

Moim zdaniem rozdzielczość Paula wykracza daleko poza eksport i import danych, tak jak Ty, więc myślę, że postąpiłeś właściwie.