Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

DRP for SQL Server in French - traduction en français du plan de relève – part 5

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 :)Here's a complete final draught en français.

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.

  1. 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
  2. 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.

  3. usp_DB_Restore_Master

  4. 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.

EXEC DBA_Tools.dbo.usp_DB_restore '\\ServeurDeRodage\Disque$\DossierSauvegardeProduction\

Full\Complet_NomDuServeur_BD1_20080217_030000.sqb', 'DBlogicalName' 'DB_DataFile_Logicalname', 'DB_LogFileLogical_name',
'DriveName:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\
DBphysicalDataFileName.mdf'
,
'DriveName:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\
DBphysicalLogFileName_log.ldf'

    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é

      Solution

      Coût

      Complexité

      Mise en Relève

      Retour  

      Hardware Clustering

      Elevé

      Elevé

      Rapide

      Rapide

      Software Clustering

      Elevé

      Elevé

      Rapide

      Rapide

      Replication

      Moyen

      Moyen

      Moyen-avec procedure manuelle

      Lent -avec procedure manuelle

      Continuous Data
      Protection

      Moyen

      Moyen

      Moyen

      Lent

      Log Shipping

      Faible

      Faible

      Moyen

      Lent

      Backup and
      Restore

      Faible

      Faible

      Lent

      Lent

      Database Mirroring

      Faible

      Faible

      Rapide, restriction par BD individuelle

      Rapide, restriction par BD individuelle

       

       

      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.

       

        Comments

        No comments.

        Leave a Comment

        Please register or log in to leave a comment.