Restore LOG : is too early to apply

Bonjour,

Je voulais restaurer ma base dans le temps:

Code:

---

1 2 3 4 5 6

RESTORE DATABASE MABASE from DISK='R:\Backup_MABASE_1310162230.BAK' WITH norecovery   Processed 14776 pages for database 'MABASE', file 'MABASE' on file 1. Processed 3 pages for database 'MABASE', file 'MABASE_log' on file 1. RESTORE DATABASE successfully processed 14779 pages in 2.232 seconds (51.728 MB/sec).

---

Qd j'essaie de restaurer la première sauvegarde de journal qui a suivi la sauvegarde complète de la base:

Code:

---

1 2 3

Restore LOG MABASE from DISK='R:\Backup_Journal_1310162250.trn' WITH NORECOVERY

---

Citation:

---

Msg 4326, Level 16, State 1, Line 1
The log in this backup set terminates at LSN 2299000000018100001, which is too early to apply to the database. A more recent log backup that includes LSN 2472000000005800001 can be restored.
Msg 3013, Level 16, State 1, Line 1
RESTORE LOG is terminating abnormally.

---

J'ai ce type de message normalement quand il y a une sauvegarde sauvage intercalée ds la chaine !
Merci.

Citation:

---

Envoyé par agdid04

Bonjour,

Je voulais restaurer mabase ds le temps:

Code:

---

1 2 3 4 5 6

RESTORE DATABASE MABASE from DISK='R:\Backup_MABASE_1310162230.BAK' WITH norecovery   Processed 14776 pages for database 'MABASE', file 'MABASE' on file 1. Processed 3 pages for database 'MABASE', file 'MABASE_log' on file 1. RESTORE DATABASE successfully processed 14779 pages in 2.232 seconds (51.728 MB/sec).

---

Qd j'essaie de restaurer la première sauvegarde de journal qui a suivi la svg full de la base:

Code:

---

1 2 3 4 5 6 7 8 9

Restore LOG MABASE from DISK='R:\Backup_Journal_1310162250.trn' WITH NORECOVERY     Msg 4326, Level 16, State 1, Line 1 The log in this backup set terminates at LSN 2299000000018100001, which is too early to apply to the database. A more recent log backup that includes LSN 2472000000005800001 can be restored. Msg 3013, Level 16, State 1, Line 1 RESTORE LOG is terminating abnormally.

---

J'ai ce type de message normalement qd il y a une sauvegarde sauvage intercallée ds la chaine !
Merci.

---

Une parenthèse: Est ce qu'on peut avoir un fichier backup (base ou journal) corrompu ? (ce n'est pas le cas mais je me pose la question).

Merci.

@+

Est-tu sûr qu'il ne te manque pas une sauvegarde de journal ?

Tu peux vérifier l'entête de tes sauvegardes et les numéros de LSN correspondants pour voir si tu n'as pas un gap

Que te donne les commandes :

Code:

---

RESTORE headeronly FROM DISK='R:\Backup_MABASE_1310162230.BAK'

---

et

Code:

---

RESTORE headeronly FROM DISK='R:\Backup_Journal_1310162250.trn'

---

++

Bonjour David,

Merci, effectivement une sauvegarde d'un journal a été lancé en // le blème c'est que le dernier backup a ecrasé le 1er !!! d'ou le trou de séquence LSN.

Je reviens à l'autre question: Est ce qu'on peut avoir un fichier backup (base ou journal) corrompu ?

Merci et Bonne journée.

@+

Citation:

---

Je reviens à l'autre question: Est ce qu'on peut avoir un fichier backup (base ou journal) corrompu ?

---

Oui c'est tout à fait possible.

++

Re,

Avant de clorer ce dossier:

Est ce qu'il y a des outils SQLServer anti blocs de données corrompus ?
Il y a first et Last LSN mais je ne connaissais pas CHECKPOINT LSN ?

Merci.

@+

Citation:

---

Envoyé par agdid04

Avant de clorer ce dossier:

---

chlorer ou clore ?

Citation:

---

Est ce qu'il y a des outils SQLServer anti blocs de données corrompus ?

---

SQL Server a ce qu'il faut en natif pour détecter les corruptions de pages pour être plus précis avec l'option de bases de données de vérification de pages, la commande DBCC CHECKDB, la table msdb.dbo.suspect_pages ...

En ce qui concerne les backups depuis 2008 il y a la possibilité d'utiliser l'option CHECKSUM au niveau des sauvegardes pour la détection des erreurs pendant la sauvegarde.

Citation:

---

Il y a first et Last LSN mais je ne connaissais pas CHECKPOINT LSN ?

---

Lorsqu'une sauvegarde est initiée SQL Server effectue un checkpoint pour avoir un "point de départ" pour simplifier les choses. C'est ce qui correspondant au checkpoint LSN. Cependant il se peut qu'une ou plusieurs transactions soient ouvertes à ce moment là et SQL Server doit pouvoir revenir à un état intègre pendant une éventuelle restauration. Le firt LSN correspond au LSN de la transaction ouverte la plus ancienne ou celle qui n'a pas été encore répliquée dans les architectures de type miroir ou de réplication. Dans certains cas, il se peut que le first LSN soit égale au checkpoint LSN et d'en d'autres cas le first LSN sera inférieure au checkpoint LSN

++

Merci David && Bon Weekend.

:ccool: