Here I go again, trying to finish up the translation. Thank you very much to local MVP Eric Moreau for his help fixing my mistakes so far :)

Configuration de l'instance SQL Serveur

Nos serveurs exploitent la version 64-bit de moteur de la base de données SQL Serveur 2005, avec la deuxième mise à jour applicative majeure appliquée (Service Pack 2) et la troisième mise à jour cumulatif aussi appliqué même si en ce moment SP3 et CU5 sont disponibles, nous avons réussi avec ses versions antérieures en production. Le type de collation est configuré à Latin1_General_CI_AS ou bien, SQL_Latin1_General_CP1_CI_AS – dans les deux cas, nous suggérons porter attention aux accents (AS=Accent Sensitive).  Bien sûr, si on refait cet environnement de relève maintenant, on profitera de Service Pack 3 avec la cinquième mise à jour accumulé installé sur nos instances en production – ce qui est fortement recommandé surement, est de mettre les derniers correctifs en production suite à son roulement avec succès en développement et test/pre-prod.

Les renseignements détaillés à propos de chacun des serveurs (SQL1 & SQL2) de la base de données inclus dans ce plan de relève est disponible dans un fichier aide compilé sur disque dur locale:  par exemple D:\DRP\NomduServeur.chm (i.e. soit très facile à trouver)

Détails critiques à propos des bases de données usagers

1. Liste des bases de données

BD1

BD2

…
À noter: nous allons pas toucher les bases de données systèmes (master, msdb, model, ou temp), qui sont sauvegardées sur une base régulière et seront copiés par Robocopy, mais pas restaurés sur le serveur de relève directement.

2. Plan de maintien de la base de données et restitution automatique
   En générale,
   our database restore plan will reflect exactly the backup schedule and wait for backups to finish by querying the metadata from the production server. The restore jobs will check to see if the days’ full backup has completed (or daily diff.) using the backupset.backup_finish_date  column.  Once we see that Full backup has been completed on the production server, we copy the backupfile over to the hot standby server. In the second step of the job, we continue to execute the code from the appropriate usp_DB_restore combined with the metadata extraction from the system tables
3. Plan de maintien de la base de données en production
   
   

   Nom du processus d’automatisés	Description de processus	fréq.	heure cédulé
   SauvgardeComplet_BD1	sauvegarde BD complet1	Hebdo	dimanche 6h
   SauvgardeComplet_BD2	sauvegarde BD complet2	Hebdo	dimanche 6h30
   …	…	…	…

   4.   Processus automatique sur le serveur de relève
   
   
   

   Nom du processus d’automatisés	Description de processus	fréq.	heure cédulé
   SauvgardeComplet_BD1	sauvegarde BD complet1	W	dimanche 6h
   SauvgardeComplet_BD1	sauvegarde BD complet2	W	dimanche 6h30
   …	…	…	…

    

   Procédures et code critiques pour le bon fonctionnement de ce plan de relève

   Le suivant est toute le code nécessaire pour vous puissiez profiter de ce plan de relève de SQL1 vers SQL2.

4. usp_DB_Restore_Master

5. Sauvegardes des bases de donnés systèmes

   Sur le serveur de relève lui-même les sauvegardes de MSDB, DBA_tools (ou se situe ce code de relève), qui sont critiques pour ce plan se retrouve ici : \\ServeurDeReleve:\DossierReleveSauvegardes\Complet

   Il devrait y avoir toujours un dossier de sauvegarde local facultatif pour les bases de données systèmes, tel que sur votre serveur de pré-production/rodage finale.  Ceci dit, il est fortement recommandé de placer sur votre serveur de rodage ces B.D. systèmes ici :

   \\ServeurDeRodage:\DossierReleveSauvegardes\Complet

   L’exemple suivant a été rodé sur un serveur de test, et est présente sur le serveur de restauration. La procédure stockée usp_DB_restoreX reçoit 6 paramètres.  Afin de s’aligner avec les métadonnées de journal de sauvegardes, nous allons s’accorder avec le nom de la base de données par date et les paramètres appropriés, ensuite nous poussons ces paramètres à la procédure stockée usp_DB_restoreX approprié.  Ces procédure centralisés sont divisés en deux types: ceux qui reçois le paramètres reliés aux métadonnées simple, et ceux prêt pour les BDs qui exploite multiples fichiers de données ou journaux de transactions. Employez toutes les procédures dépendantes pour faire la vraie restitution : il faut comprendre que usp_DB_RestoreX est dépendante sur usp_KillConnections qui aide le processus de restitution en fermant par force les connexions a la base de données (mais attention aux usagers systems SPID<50).

e.g.

Le procedure stockée en question, usp_DB_restore_norecovery, est le meme que usp_DB_restore, et il est destiné pour les bases de données qui vont rester en mode norecovery (éxpliqué ci-haut déjà).

Veuillez lire l'historique (Activity History) de Red Gate SQL Backup en ce qui concerne les rapports de sauvegardes, puisque le scope de ce document n'est seulement profonde qu'au niveau de la processus de restitution.  Malgré le fait que les renseignments reliés au sauvegardes sont retirés des métadonnées afin d'être mise dans les scripts automatisés à l'interieur des processus (SQL Agent Jobs), nous allons pas créer (à cette étape, au moins) des rapports customisés.

Résumée du plan de relève

Est-ce que ce plan en cas de désastre, cette méthodologie, vas vraiment réduire l'intervention manuelle lors d'une catastrophe ?  Est-ce qu'on peut l'améliorer ? Oui, sûrement, il y a toujours de quoi à réviser.  S'il vous plait, laissez vos commentaires ici-bas, et l'on fera ensemble. Ce qui est important, c'est comprendre que cette méthode n'est pas la solution pour tous vos environnements.  Avant que vous faites une copie/collé de ce code ci-haute rassemblé pour vos opérations, je vous recommande chaudement de lire la grille de Choix Haut Disponibilité ici-bas afin de éclairé votre voie en ce qui concerne vos besoins individuelles.  Naturellement, pour faire le choix de la voie approprié, il faut une profonde analyse d'attentes de vos clients.

Choix au niveau de la Haute Disponibilité

Personne veut être mis dans une situation de désastre sans la préparation nécessaire.

Quand on m'a demandé de préparer un plan de relève pour la plus grande gestionnaire de fonds institutionnels au Canada, qui gère des fonds provenant principalement de régimes de retraite et d'assurance publics et privés, je l'ai pris au sérieux – donc l'abondance des détails dans ce document.  Nous avons faits nos propres essaies, afin de simulé un désastre durant une fin de semaine, et cela sans problème (dieu merci).  Ici j'essaie de partager exactement comment faire un plan porque lors le désastre imprévu arrive dans votre environnement, il n'est pas un désastre en soi.