Backup erkennt Beschädigungen, CHECKDB jedoch nicht

Ich habe eine Datenbank, in der ich den Sicherungsbefehl ausführe

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

Ich erhalte die Fehlermeldung

Meldung 3043, Ebene 16,
Status 1, Zeile 8 BACKUP 'MyDatabase' hat auf Seite (1: 745345) einen Fehler in der Datei 'F: \ Data \ MyDatabase_1.ndf' festgestellt.
Meldung 3013, Ebene 16,
Status 1, Zeile 8 BACKUP DATABASE wird abnormal beendet.

Ich habe eine vollständige CHECKDB ausgeführt, aber sie kommt sauber zurück. Ich habe festgestellt, dass die Option "Seitenüberprüfung" auf "NONE" gesetzt wurde (nicht meine Aufgabe), daher habe ich sie in "CHECKSUM" geändert und alle Indizes in der Datenbank neu erstellt, damit sie auf alle Seiten geschrieben und Prüfsummen generiert werden. Danach schlägt die Sicherung immer noch fehl und die checkdb zeigt immer noch sauber an (also keine Änderung).

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

aus dem SQL-Protokoll:

DBCC CHECKDB (MyDatabase) WITH all_errormsgs, no_infomsgs, data_purity, ausgeführt von xxx, hat 0 Fehler gefunden und 0 Fehler behoben. Verstrichene Zeit: 0 Stunden 21 Minuten 46 Sekunden. Der interne Datenbank-Snapshot hat den Split-Punkt LSN = 000ab776: 0000112f: 0001 und den ersten LSN = 000ab776: 0000112d: 0001.

Ich habe DBCC PAGE ausgeführt, aber es ist ein Fehler (scheint nicht einmal die richtige Seite zurückzugeben). Ich kann es mit Druckoption 2 ausführen und es kehrt zurück, aber ehrlich gesagt weiß ich nicht, wonach ich dort suche.

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

SEITE: (3: 513793)

PUFFER:


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          

KOPFZEILE:


Seite @ 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
Metadaten: AllocUnitId = 633462595911680 Metadaten: PartitionId = 0
Metadaten: IndexId = -1 Metadaten: 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

Zuordnungsstatus

GAM (1: 511232) = ALLOCATED SGAM (1: 511233) = NOT ALLOCATED     
PFS (1: 744096) = 0x40 ALLOCATED 0_PCT_FULL DIFF (1: 511238) = NICHT GEÄNDERT
ML (1: 511239) = NICHT MIN_LOGGED      

Meldung 2514, Ebene 16,
Status 8, Zeile 20 Ein DBCC-PAGE-Fehler ist aufgetreten: Ungültige Seitenmetadaten - Speicherauszugsstil 3 nicht möglich.

Irgendwelche Ideen, was ich als nächstes versuchen könnte? Serverversion ist

select @@version

Microsoft SQL Server 2014 (SP2-CU11) (KB4077063) - 12.0.5579.0 (X64) 
    21. Februar 2018 12:19:47 
    Copyright (c) Microsoft Corporation
    Developer Edition (64-Bit) unter Windows NT 6.3 (Build 9600 :) (Hypervisor)

Die Kompatibilitätsstufe der Datenbank beträgt 100 (SQL 2008).

Diese Antwort stammt aus einer Ausgabe des SQLskills.com-Newsletters von Paul Randal über "eine Datenbank, bei der eine Sicherung mit Seitenprüfsummenfehlern fehlschlagen würde, die jedoch bestanden wurde DBCC CHECKDB".

Dies kann nur passieren, wenn ein Bereich ein gemischter Bereich ist (wobei die 8 Seiten des Bereichs potenziell 8 verschiedenen Zuordnungseinheiten zugeordnet werden können - siehe hier ) und einige Seiten fälschlicherweise als von der entsprechenden PFS-Seite zugewiesen markiert sind.

In diesem Fall DBCC CHECKDBwird nicht versucht, diese Seiten zu lesen, da abgeleitet wird, welche Seiten von den IAM-Seiten einer Zuordnungseinheit gelesen werden sollen (von denen die erste die Seiten in gemischtem Umfang auflistet). Dieser Fall ist eine Lücke in DBCC CHECKDBder Korruptionserkennungslogik.

[Weil] DBCC CHECKDBdie Beschädigung nicht erkennen konnte, war es nicht möglich, die Reparaturen durchzuführen, die zur Behebung erforderlich waren. Mit habe DBCC WRITEPAGEich die Änderungen im Zuordnungsstatus für die falsch zugewiesenen Seiten direkt auf der PFS-Seite herausgearbeitet und es hat funktioniert!

Dies war ein äußerst seltener Fall - es kommt viel häufiger vor, dass ein DBCC CHECKDB Fehler fehlschlägt, ein Backup jedoch erfolgreich ist.

Meiner Meinung nach geht Pauls Vorsatz weit über das Exportieren und Importieren der Daten hinaus, so wie Sie es getan haben. Ich denke, Sie haben das Richtige getan.