Impossible de restaurer (erreur 3456)

J'ai une situation qui n'est pas facile à comprendre, et j'ai pensé demander à ce forum si d'autres pouvaient avoir des suggestions.

J'exécute SQL Server 2008 R2 Standard SP3 sur Windows Server 2008R2 Enterprise.

Une base de données avait besoin d'un peu de maintenance et, après coup, j'avais besoin de restaurer sur un autre serveur. J'ai une sauvegarde complète de la base de données effectuée avec COPY_ONLY plus un ensemble de 4 sauvegardes tlog.

avant de commencer, créez tlogbackup1
passer du FULLau BULK_LOGGEDmodèle de récupération
ajouter un nouveau groupe de fichiers
ajouter un fichier à newfilegroup
définir newfilegroup comme valeur par défaut
sélectionner dans la table (sur newfilegroup)
déposer la table d'origine
supprimer le fichier d'origine
supprimer le groupe de fichiers d'origine
changer le nom de la nouvelle table pour qu'elle corresponde à la table d'origine
changer le nom de fichier de newfilegroup pour correspondre au groupe de fichiers d'origine
changer le nom de fichier dans le catalogue pour correspondre au nom de fichier d'origine
changer le nom du fichier au niveau du système d'exploitation pour correspondre au nom du fichier d'origine
définir le groupe de fichiers par défaut comme l'original
mettre db en ligne
passer du BULK_LOGGEDau FULLmodèle de récupération
Une fois toutes les étapes terminées, créez tlogbackup2

La restauration de toutes les sauvegardes doit utiliser WITH MOVE, en raison des modifications de la lettre de lecteur sur le serveur de restauration.

Étapes de récupération:

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

La restauration finale du tlog atteint 100%, puis échoue avec l'erreur 3456:

368 pages traitées pour la base de données 'SomeDB', fichier 'SystemData' sur le fichier 1.

7656520 pages traitées pour la base de données 'SomeDB', fichier 'SystemDataPDS' sur le fichier 1.

172430 pages traitées pour la base de données 'SomeDB', fichier 'SystemData_log' sur le fichier 1.

Msg 3456, niveau 16, état 1, ligne 1
Impossible de refaire l'enregistrement du journal (210388: 123648: 232), pour l'ID de transaction (0: 1016710921), à la page (4: 8088), base de données 'SomeDB' (ID de base de données 6) . Page: LSN = (0: 0: 1), tapez = 11. Journal: OpCode = 4, contexte 11, PrevPageLSN: (210388: 122007: 1). Restaurez à partir d'une sauvegarde de la base de données ou réparez la base de données. Msg 3013, niveau 16, état 1, ligne 1 RESTORE LOG se termine anormalement.

Juste pour vérifier que la sauvegarde complète de la base de données était correcte, je l'ai restaurée CHECKDBet il n'y a eu aucune erreur.

Tous les commentaires sont les bienvenus.

Merci d'avance,

Ned Otter

— NedOtter
source

Pourriez-vous expliquer pourquoi vous pensez avoir une chaîne de journal ininterrompue? Au moment où vous avez basculé la base de données en mode BULK_LOGGED et commencé à jouer avec le schéma, tous les paris sur la non interruption de la chaîne de journaux sont désactivés.

— Thomas Kejser

Merci pour votre réponse, Thomas. Je vois maintenant que le titre de mon message était incorrect. Je n'ai pas besoin d'une récupération ponctuelle, mais d'une restauration complète à la fin de la 4e sauvegarde de tlog. La définition de BULK_LOGGED ne devrait donc pas avoir posé de problème avec cela. Je ne vois pas comment ce que j'ai fait aurait provoqué l'échec de la 2e sauvegarde du journal - toutes les commandes ont été prises en charge par SQL Server, et j'ai exécuté exactement les mêmes étapes (mais pas sur les mêmes données) sur une base de données plus petite, et j'ai pu pour restaurer la 2ème sauvegarde tlog sans problème.

— NedOtter

L'erreur ressemble à de la corruption. Il s'agit d'une erreur interne. Pouvez-vous vérifier l'intégrité de tous les fichiers de sauvegarde? Sont-ils avec des sommes de contrôle?

— usr

J'ai vérifié que la sauvegarde complète de la base de données ne comportait aucune erreur en exécutant CHECKDB. Je vais devoir vérifier si CHECKSUM a été utilisé.

— NedOtter

Si les sauvegardes ont activé la somme de contrôle, vous devez également utiliser la somme de contrôle pour la restauration. Le type de page 11 est une page PFS, ce qui signifie que vous ne pouvez pas y remédier, vous pouvez uniquement effectuer une restauration complète. En outre, vous ne dites pas quand la sauvegarde de copie uniquement a été effectuée. Où était cette sauvegarde dans la chronologie?

— Robert L Davis

Afin de comprendre pourquoi l'erreur 3456 serait levée, nous devons prendre un peu de recul et comprendre comment SQL Server gère ce coin de récupération.

Lorsque SQL Server refait une opération et que cette restauration est une modification de page, il effectue une vérification rapide. Dans l'en-tête de page, il y aura finalement un PageLSN, qui est une indication du dernier LSN qui a modifié cette page, enregistré par la page. Pensez-y comme ceci, la page garde une trace du dernier LSN qui y a apporté des modifications. C'est le PageLSN.

Chaque fois qu'il y a une opération de modification de page enregistrée, cet enregistrement de journal comprend quelques LSN. À savoir, le LSN de l'enregistrement de journal (pensez ... LSN actuel ), puis il a ce qu'on appelle le LSN de la page précédente ( PrevPageLSNaller de l'avant). Ainsi, lorsque nous modifions une page, l'une des données qui est placée dans l'enregistrement de journal est ce que la page indique comme étant le dernier LSN avant que vous ayez modifié la page .

Pensez-y comme ceci ... Votre voiture doit faire l'objet de travaux. Le mécanicien John travaille sur votre voiture, et dans le compartiment moteur, il a une petite étiquette et le mécanicien John écrit "John a travaillé sur cette voiture en dernier". Ensuite, la prochaine fois que vous emmenez votre voiture dans un autre magasin, le mécanicien Mark regarde dans le compartiment moteur et voit que le mécanicien John a travaillé sur cette voiture en dernier. Sur sa fiche technique, il écrit ces informations. Même idée avec SQL Server.

Cela peut être quelque peu déroutant, alors jetez un œil à cette image ci-dessous sur les modifications de page séquentielles, et comment les PageLSNet se PrevPageLSNrapportent:

entrez la description de l'image ici

Revenons en arrière, car tout cela entre en jeu lorsque vous devez refaire une opération sur une page (restaurations, récupération, HA, etc.). Lorsque SQL Server doit refaire une opération de page, il effectue un contrôle de cohérence pour voir si le PageLSNsur la page correspond à ce PrevPageLSNque l'enregistrement de journal inclut. Si ce n'est pas égal, vous verrez l'erreur 3456 s'afficher.

PageLSN est - il égal à PrevPageLSN ? Non??? Arrêt et augmentation de l'erreur 3456 ...

Analysons votre message d'erreur, qui comprend comment:

Impossible de refaire l'enregistrement du journal (210388: 123648: 232), pour l'ID de transaction (0: 1016710921), à la page (4: 8088), base de données 'SomeDB' (ID de base de données 6). Page: LSN = (0: 0: 1) , tapez = 11. Journal: OpCode = 4, contexte 11, PrevPageLSN: (210388: 122007: 1) . Restaurez à partir d'une sauvegarde de la base de données ou réparez la base de données. Msg 3013, niveau 16, état 1, ligne 1 RESTORE LOG se termine anormalement.

J'ai mis en gras les deux données qui présentent une inégalité à l'origine de l'erreur. Vous pouvez voir que notre PageLSNest 0: 0: 1 (cela a été trouvé dans l'en-tête de la page), et notre PrevPageLSNest 210388: 122007: 1 (cela a été trouvé dans les données de l'enregistrement de journal qui tentait d'être refait). Ce ne sont évidemment pas égaux, d'où err3456.

Donc, pour découvrir le pourquoi de cet événement, ce serait de savoir pourquoi il y a une disparité ici. Nous devons vraiment retracer le cycle de vie de la page 4: 8088 et voir où se trouve la déconnexion. Malheureusement, sans informations supplémentaires ni dépannage pratique, je ne peux pas faire grand-chose d'autre que vous donner le contexte de cette opération de récupération et les causes de l'erreur.

— Thomas Stringer
source

Je sais que ça fait un moment mais quand même ... de bonnes choses, merci pour l'explication approfondie!

— RThomas