Wiederherstellung nicht möglich (Fehler 3456)

Ich habe eine Situation, die nicht leicht herauszufinden ist, und dachte, ich würde in diesem Forum fragen, ob andere Vorschläge haben könnten.

Ich verwende SQL Server 2008 R2 Standard SP3 unter Windows Server 2008R2 Enterprise.

Eine Datenbank musste gewartet werden, und danach musste ich sie auf einem anderen Server wiederherstellen. Ich habe eine vollständige Datenbank-Sicherung mit COPY_ONLY sowie einen Satz von 4 tlog-Sicherungen.

1. Erstellen Sie vor dem Start tlogbackup1
2. Wechsel von FULLzu BULK_LOGGEDWiederherstellungsmodell
3. Neue Dateigruppe hinzufügen
4. Datei zur neuen Dateigruppe hinzufügen
5. Setzen Sie newfilegroup auf default
6. in Tabelle auswählen (auf neue Dateigruppe)
7. Original-Tabelle fallen lassen
8. Originaldatei löschen
9. ursprüngliche Dateigruppe löschen
10. Ändern Sie den Namen der neuen Tabelle entsprechend der ursprünglichen Tabelle
11. Ändern Sie den Dateinamen der neuen Dateigruppe entsprechend der ursprünglichen Dateigruppe
12. Ändern Sie den Dateinamen im Katalog so, dass er mit dem ursprünglichen Dateinamen übereinstimmt
13. Ändern Sie den Dateinamen auf Betriebssystemebene so, dass er mit dem ursprünglichen Dateinamen übereinstimmt
14. Setzen Sie die Standard-Dateigruppe auf das Original
15. db online bringen
16. Wechsel von BULK_LOGGEDzu FULLWiederherstellungsmodell
17. Nachdem alle Schritte abgeschlossen sind, erstellen Sie tlogbackup2

Für die Wiederherstellung aller Sicherungen muss WITH MOVE verwendet werden, da sich die Laufwerksbuchstaben auf dem Wiederherstellungsserver geändert haben.

Wiederherstellungsschritte:

RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

Die endgültige tlog-Wiederherstellung erreicht 100% und schlägt dann mit Fehler 3456 fehl:

368 Seiten für die Datenbank 'SomeDB', Datei 'SystemData' in Datei 1 verarbeitet.

Verarbeitete 7656520 Seiten für die Datenbank 'SomeDB', Datei 'SystemDataPDS' in Datei 1.

Verarbeitete 172430 Seiten für die Datenbank 'SomeDB', Datei 'SystemData_log' in Datei 1.

Meldung 3456, Ebene 16,
Status 1, Zeile 1 Protokolldatensatz (210388: 123648: 232) für Transaktions-ID (0: 1016710921) auf Seite (4: 8088), Datenbank 'SomeDB' (Datenbank-ID 6) konnte nicht wiederholt werden. . Seite: LSN = (0: 0: 1), Typ = 11. Protokoll: OpCode = 4, Kontext 11, PrevPageLSN: (210388: 122007: 1). Stellen Sie eine Sicherung der Datenbank wieder her oder reparieren Sie die Datenbank. Meldung 3013, Ebene 16, Status 1, Zeile 1 RESTORE LOG wird abnormal beendet.

Nur um zu überprüfen, ob das vollständige DB-Backup in Ordnung war, habe ich es wiederhergestellt CHECKDBund es gab keine Fehler.

Alle Rückmeldungen sind willkommen.

Danke im Voraus,

Ned Otter

Um zu verstehen, warum der Fehler 3456 ausgelöst wird, müssen wir einen kleinen Schritt zurücktreten und verstehen, wie SQL Server mit dieser Ecke der Wiederherstellung umgeht.

Wenn SQL Server einen Vorgang wiederholt und es sich bei dieser Wiederholung um eine Seitenänderung handelt, wird eine schnelle Überprüfung durchgeführt. Im Seitenkopf befindet sich letztendlich ein PageLSN, was ein Hinweis auf die letzte LSN ist, die diese Seite geändert hat und von der Seite aufgezeichnet wurde. Stellen Sie sich das so vor: Die Seite verfolgt den letzten LSN, der Änderungen daran vorgenommen hat. Das ist der PageLSN.

Jedes Mal, wenn eine Änderungsoperation für protokollierte Seiten ausgeführt wird, enthält dieser Protokolldatensatz einige LSNs. Das heißt, die LSN des Protokolldatensatzes (denken Sie an ... die aktuelle LSN ), und dann hat sie die sogenannte LSN für die vorherige Seite ( PrevPageLSNin Zukunft). Wenn wir also eine Seite ändern, ist eines der Daten, die in den Protokolldatensatz eingefügt werden, das, was auf der Seite als letzte LSN angegeben wird, bevor Sie die Seite geändert haben .

Denken Sie so darüber nach ... Ihr Auto muss bearbeitet werden. Mechaniker John arbeitet an Ihrem Auto, und im Motorraum befindet sich ein kleines Etikett, und Mechaniker John schreibt "John hat zuletzt an diesem Auto gearbeitet". Wenn Sie Ihr Auto das nächste Mal in ein anderes Geschäft bringen, schaut Mechanic Mark in den Motorraum und stellt fest, dass Mechanic John zuletzt an diesem Auto gearbeitet hat. Auf sein Datenblatt schreibt er diese Informationen. Gleiche Idee mit SQL Server.

Dies kann etwas verwirrend, so werfen Sie einen Blick auf dieses Bild unten auf sequenzielle Seite Änderungen und wie die PageLSNund PrevPageLSNbeziehen:

Kehren wir zurück, da dies alles ins Spiel kommt, wenn Sie einen Vorgang auf einer Seite wiederholen müssen (Wiederherstellen, Wiederherstellen, HA usw.). Wenn SQL Server eine Seitenoperation wiederholen muss, wird eine Überprüfung der Integrität durchgeführt, um festzustellen, ob die PageLSNauf der Seite angegebene Datei mit der PrevPageLSNim Protokolldatensatz enthaltenen übereinstimmt . Wenn dies nicht gleich ist, wird der Fehler 3456 ausgelöst.

Does PageLSN gleich PrevPageLSN ? Nein??? Stopp und Fehler auslösen 3456 ...

Lassen Sie uns Ihre Fehlermeldung analysieren, die Folgendes beinhaltet:

Protokolldatensatz (210388: 123648: 232) für Transaktions-ID (0: 1016710921) auf Seite (4: 8088), Datenbank 'SomeDB' (Datenbank-ID 6) konnte nicht wiederholt werden. Seite: LSN = (0: 0: 1) , Typ = 11. Protokoll: OpCode = 4, Kontext 11, PrevPageLSN: (210388: 122007: 1) . Stellen Sie eine Sicherung der Datenbank wieder her oder reparieren Sie die Datenbank. Meldung 3013, Ebene 16, Status 1, Zeile 1 RESTORE LOG wird abnormal beendet.

Ich habe die beiden Daten fett gedruckt, die eine Ungleichung aufweisen, die den Fehler verursacht. Sie können sehen , dass unser PageLSNsind 0: 0: 1 (dies wurde in der Seite - Header), und unser PrevPageLSNsind 210.388: 122.007: 1 (dies wurde in den Daten auf dem Protokolldatensatz gefunden , die erneuert zu werden versuchen). Diese sind offensichtlich nicht gleich, daher err3456.

Um das Warum dieses Ereignisses herauszufinden, müsste man herausfinden, warum es hier Unterschiede gibt. Wir müssen wirklich den Lebenszyklus von Seite 4: 8088 verfolgen und sehen, wo sich die Trennung befindet. Leider kann ich ohne weitere Informationen oder praktische Fehlerbehebung nicht viel anderes tun, als Ihnen den Hintergrund dieses Wiederherstellungsvorgangs und die Ursachen des Fehlers zu erläutern.