LOG SHIPPING MANUEL

Bonjour à tous,

Je viens de mettre en place un système de backup pour plusieurs serveurs.
Ce système fait un backup FULL le Lundi et différentiel les autres jours de la semaine.
Les Logs sont sauvegardés toutes les 15 minutes sur disque.

Ils sont enregistrés sur le même device.
Je n'ai pas spécifié INIT afin que les sauvegardes se rajoutent à la fin de mon backupset.

Tout se passe bien Je peux réutiliser les backup sans soucis.

Mon problème est que je passe de SQL Server 2005 à SQL Server 2000 STD et que je ne dispose pas de gestion du log shipping.

J'ai donc voulu utiliser mes backup de log afin de les restaurer sur une autre base.


Pour le premier restore pas de problème ma base est toujours en NORECOVERY nickel.

Mon problème (Nous y voila) est qu'a la prochaine éxécution de mon job qui restaure les log il reprends toujours au premier fichier de mon backupset.

Je n'ai pas de solution pour qu'automatiquement il fasse ce que je ferait manuellement.
C'est a dire

RESTORE LOG MABASE FROM DISK='xxxxx' WITH NORECOVERY,FILE=2

RESTORE LOG MABASE FROM DISK='xxxxx' WITH NORECOVERY,FILE=3

RESTORE LOG MABASE FROM DISK='xxxxx' WITH NORECOVERY,FILE=4


Y a t'il un moyen de connaitre le LSN d'une base qui est en NORECOVERY?
De cette manière je pourrai récupérer les informations du HEADER de mon device de backup et faire une recherche pour savoir quel sauvegarde utiliser.

Peut être y aurait t'il une autre manière tout simplement d'appréhender la chose?


Merci d'avance pour votre aide.

bonjour,

pour répondre à la question :

Citation:

---

Y a t'il un moyen de connaitre le LSN d'une base qui est en NORECOVERY?

---

Code:

---

1 2	DBCC LOGINFO('MABASE') go

---

et prendre le VLF qui a le statut à 2 (la portion du journal active)

Cool je te remercie.
Dommage pour moi le Create LSN est toujours à 0 dans ce cas précis ce qui ne m'aide pas tellement pour le coup.

Peut on utiliser le startoffset?

J'ai trouvé quelques articles sur cette commande DBCC mais ils ne sont pas associés à mon type de problématique et ne traitent que de la taille des log virtuels.

(((



2 6488064 8192 0 0 64 0
2 6488064 6496256 0 0 0 0
2 6488064 12984320 7 2 64 0
2 6742016 19472384 0 0 64 0

Bonjour,

Pourquoi ne pas maintenir une table qui conserve l'info du dernier fichier restauré dans le jeu de sauvegarde, et ensuite construire le RESTORE en SQL dynamique avec les numéros de fichier suivants ?

C'est une option, j'aurai préféré faire sans, si cela avait été possible.

Et ca m'interessait de savoir si on pouvait récupérer l'info du point de recouvrement (LSN) d'une base.

Le format du journal, et les commandes DBCC qui le lisent, sont non documentées. Cela veut dire que tu n'as pas de garantie de pérennité des solutions basées sur ces infos.

Arf...
Bon il semblerait que je doive me résigner. Dommage (

En tout cas merci pour ta réponse ;)