Discussion :

[slimsamfr]

Bonjour,

je souhaite mettre une BDD en mode NO RECOVERY comment faire.

Merci

[mikedavem]

En restaurant un ou plusieurs backups en mode NORECOVERY

++

[slimsamfr]

En faite je m'expliquer le but de cette manipulation est de mettre en mode No RECOVERY une BDD afin de pouvoir l'utiliser lors d'une implementation d'un Log Shipping.

Donc en faite je n'ai pas de restaure à faire.

+++

[mikedavem]

Donc il faut récupérer les dernières sauvegardes de votre base de données en production (FULL et LOG) et les restaurer en mode NORECOVERY sur votre secondaire. Vous pourrez alors initier votre session LOGSHIPPING

++

[slimsamfr]

Merci Mike,

Je crois que je n'ais pas etais clair sur ma demande.

En faite je me trouve dans le scenario ou j'ai basculé sur mon serve secondaire car il y a eu un souci sur le primaire.

Le server primaire est retabli et je dois remonter mon log shipping sachant qu'il y a eu de l'activité sur le server secondaire.

Donc je fais un backup du server secondaire, je restaure sur le primaire, jusqu'a la tous va bien.
Ensuite il faut que je remonte le log shipping par contre il faut que la BDD du server secondaire soit en NoRecovery.

Il y a une solution qui serait de faire un restore du backup précédant (généré sur le server secondaire) en mode NoRecovery mais ceci et une etape un peu stupide sachant que je fais un backup d'une même BDD.

Merci

[agdid04]

Bonjour,

Il faut resynchroniser la standby avec ta primaire déjà ...
A ta palce je ré-initialise le log shipping qui se chargera de la restauration de la base jusqu'à la dernière sequence ....

A+

[Ptit_Dje]

Bonjour,

Votre situation est la suivante si je comprend bien:
Votre base de données tourne sur le server secondaire (appelons le B)
Vous souhaitez retourner vers le server primaire (appelons le A)
Vous souhaitez que la base sur le serveur B soit en mode NORECOVERY, c'est à dire dans un état restoring afin de réappliquer vos logs du server A sur votre base de données.

Je proposerais la solution suivante:
- Restore de la base du serveur B vers le serveur A (en mode no recovery)
- Restore d'au moins un log du serveur B vers le serveur A (pre-requis mirroring)
- Mise en place du mirroring depuis B vers A (en asynchrone pour commencer si il y a beaucoup de log a rejouer)
- Update de la session de mirroring en mode synchrone lorsque les DBs sont quasi synchrones (garantir 0 data loss)
- Failover de la session de mirroring (A redevient la DB principale, B devient la secondaire)
(- Activités ad-hoc pour pointer sur le bon serveur au niveau des applications)
- Coupure de la session de mirroring (A est le primaire, B est dans un état restoring)
- remise en place du log shipping de A vers B

Principaux avantages:
- Downtime de la base de données réduit
- Serveur secondaire (B) directement pret pour reprendre la session de log shipping sans restore de base de données superflu.

[mikedavem]

De manière générale il faudra restaurer la session log shipping de l'ancien secondaire vers l'ancien primaire dans une première phase pour resynchroniser vos 2 serveurs (pendant que vos applications attaquent l'ancien secondaire) et rejouer un failover durant lequel il faudra couper votre production, restaurer tous les backups restants sur le secondaire (+ tail log backup) avec RECOVERY à la fin et ensuite repasser votre secondaire en serveur primaire.

Ptit_Dje vous propose également d'implémenter temporairement du mirroring qui pourra accéler votre failover. Bien entendu il faut au moins être en version 2005 (vous n'avez pas précisé votre version) et pour le mode asynchrone il faudra posséder une édition entreprise. Les éditions standard ne supportent que le mode synchrone.

++