INF: Disaster Recovery Planning for SQL Server

Traductions disponibles Traductions disponibles
Numéro d'article: 169039 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Résumé

Cet article fournit deux exemples de reprise après sinistre simple des plans de récupération d'un site peut prendre en compte lors de la planification proactive de la récupération des données à partir d'un sinistre catastrophique. Le premier exemple est ciblé pour les sites ayant des fenêtres de maintenance système disponibles ; le second exemple est conçu pour les sites fonctionnant sur une base de 24 heures.

L'objectif de cet article est de fournir un point de départ pour la reprise après sinistre efforts de planification. Cet article n'est pas votre plan de récupération après sinistre. C'est vous permettant de prendre en compte de votre propre environnement, modifiez en conséquence, de spécifier et de vérifier.

Plus d'informations

Supposons qu'un incendie se produit et efface à votre centre de données de 24 heures. Êtes-vous sûr de que pouvoir récupérer ? Combien de temps faudra-t-il vous permet de récupérer et que votre système disponible ? La quantité perte de données peuvent tolérer vos utilisateurs ? Il doivent être parmi les principales préoccupations de chaque administrateur système (SA) et administrateur de base de données (DBA) responsables des gestion des données système inestimable. Reprise après sinistre est le processus par lequel des informations systèmes sont restaurés en cas de catastrophe : une catastrophe naturelle ou manmade comme un incendie ou de sinistre technique comme une panne de deux disques dans une baie RAID-5. Planification de la récupération après sinistre est le travail consacré à la préparation de toutes les actions qui se produisent en réponse à un événement catastrophique. Évaluation de récupération après sinistre est la simulation d'un événement catastrophique et/ou l'évaluation des capacités du Disaster Recovery Plan remettre les besoins de récupération spécifié.

Dans l'idéal, le plan de récupération après sinistre doit indiquer combien de temps de récupération doivent prendre et la base de données finale état que les utilisateurs peuvent s'attendre. Par exemple, «après l'acquisition de matériel spécifié, récupération doit être effectuée dans les 48 heures et données va être garanties uniquement à la fin de la semaine précédente». Il est généralement important que gestion être tenus clairement informés de ces spécifications. Évaluation de récupération après sinistre doit pouvoir justifier la spécification.

Un plan de récupération d'urgence peut être structuré différentes façons, et il peut contenir de nombreux types d'informations (comment obtenir le matériel, qui est de communiquer ce que, qui sont les personnes à contacter en cas de sinistre, comment sont-ils à contacter, qui est propriétaire de l'administration de la plan et ainsi de suite). Cet article est consacré uniquement aux propose certaines voies initiales pour la récupération de technique de SQL Server.

Voici un exemple pour les sites qui ne fonctionnent pas sur une base de 24 heures sur 24 (c'est-à-dire, des sites ayant des fenêtres de maintenance disponibles) :

Pour préparer la reprise après sinistre, procédez comme tous les jours (ou chaque fois que la fenêtre de maintenance est) :
  1. Arrêter SQL Server.
  2. Copier tous les fichiers de périphérique de base de données, préférence à un autre ordinateur dans un autre bâtiment (mais n'oubliez pas de charge réseau) et également pour un périphérique à bande (avec le serveur, le périphérique hors fichiers puissent être copiés comme n'importe quel autre fichier).
  3. Conservez les journaux système de manière sécurisée. Enregistrer le répertoire où se trouvent tous les fichiers de SQL Server, en particulier le fichier master.DAT. Prenez note de tous les service packs installés pour Windows NT Server et SQL Server. Conserver les enregistrements des Net-libraries utilisés, le mode de sécurité et le mot de passe SA.
  4. Conservez un script des fonctionnalités de base pour évaluer rapidement les capacités minimales (voir la Remarque à la fin de cet article).
  5. Pour réduire la quantité de données perdues pendant la journée, effectuez dumps de journal de transactions pendant que le système est direct. Consultez la documentation en ligne de SQL Server pour plus d'informations sur les procédures de vidage, de charge et de récupération.
  6. Évaluer après sinistre récupération suit avance sur un autre serveur et modifier les étapes autant de fois que nécessaire.
Pour récupérer après qu'un incident s'est produite, procédez comme suit après l'acquisition de matériel de remplacement adéquat :
  1. Installez Windows NT Server et chargez le service pack approprié. Vérifier l'existence de la fonctionnalité de domaine approprié. Par exemple, vérifiez ce fichier partage fonctionne correctement.
  2. Installez SQL Server et chargez le service pack approprié. Placez le périphérique de base de données master dans même répertoire qu'il a été installé initialement. Sélectionnez également le même NET-bibliothèque, le mode de sécurité et le mot de passe SA comme avant.
  3. Confirmez que SQL Server fonctionne correctement. Si le serveur Windows NT a changé de nom, utilisez sp_dropserver et sp_addserver pour correspondre au nom de Windows NT Server.
  4. Arrêtez SQL Server.
  5. Déplacez tous les fichiers de périphérique de base de données vers leur emplacement d'origine, y compris le fichier master.DAT.
  6. Redémarrez SQL Server.
  7. Si des journaux de transactions ou de la base de données sont disponibles après cette heure, les charger.
  8. Vérifiez la disponibilité du système. Exécutez un script des fonctionnalités pour garantir le fonctionnement adéquat. Idéalement, avant les utilisateurs sont sur le système, heure convient pour DBCC CHECKDB et NEWALLOC chaque base de données et DBCC TEXTALL et TEXTALLOC sur ces bases de données et les tables contenant des champs de texte. Cela est de s'assurer que le processus de migration n'a pas modifier les fichiers de manière indésirable.
  9. Une fois que les instructions DBCC en cours d'exécution affiche la base de données dans un souci de cohérence et le script de test de fonctionnalité réussit, permettent aux utilisateurs de reprendre.
Voici un exemple pour les sites qui n'ont aucune fenêtre de maintenance en ligne et qui s'exécutent 7 jours sur 7, 24 heures sur 24 :

Pour préparer un sinistre, procédez comme suit :
  1. Périodiquement vider toutes les bases de données, préférence sur un disque sur un autre ordinateur dans un autre bâtiment (mais n'oubliez pas de charge réseau) et également pour un périphérique à bande. Journaux de transactions peuvent être traitées de la même façon.
  2. Conservez les journaux système de manière sécurisée. Enregistrer le répertoire où se trouvent tous les fichiers de SQL Server, en particulier le fichier master.DAT. Prenez note de tous les service packs installés pour Windows NT Server et SQL Server. Conserver les enregistrements des Net-libraries utilisés, le mode de sécurité et le mot de passe SA. Gardez une trace des options de base de données spécifié.
  3. Enregistrer dans les scripts le tous les changements de taille pour tous les périphériques et les bases de données. Ceci est crucial pour simplifier la récupération dans cette situation !
  4. Conservez un script des fonctionnalités de base pour évaluer rapidement les capacités minimales (voir la remarque au bas de cet article).
  5. Évaluer après sinistre récupération suit avance sur un autre serveur et modifier les étapes autant de fois que nécessaire.
Pour récupérer après un incident a eu lieu après l'acquisition de matériel approprié :
  1. Installez Windows NT Server et chargez le service pack approprié. Vérifier l'existence de la fonctionnalité de domaine approprié. Par exemple, vérifiez ce fichier partage fonctionne correctement.
  2. Installez SQL Server et chargez le service pack approprié. Veillez à placer l'unité de base de données master dans même répertoire qu'avant. Sélectionnez également le même NET-bibliothèque, le mode de sécurité et le mot de passe SA comme avant.
  3. Confirmez que SQL Server fonctionne correctement. Si le serveur Windows NT a changé de nom, s'exécuter sp_dropserver et sp_addserver pour correspondre au nom de Windows NT Server.
  4. Créer ou modifier tous les périphériques et les bases de données à partir de scripts dans étape 3 de la section précédente ci-dessus. Il est possible de créer des bases de données pour LOAD.
  5. Une fois toutes les bases de données et les fichiers de périphérique sont dimensionnés telles qu'elles étaient au moment de la dernière dump, si les informations d'ouverture de session utilisateur ou les informations d'ouverture de session de serveur distant sont significatives de la base de données master faisant l'objet d'un dumping, poursuivre l'étape 5 a. Dans le cas contraire, s'ils ne sont pas essentielles, passez à étape 6.

    1. Arrêtez SQL Server.
    2. Démarrage de SQL Server en mode utilisateur unique à partir de la ligne de commande "SQLSERVR - c -m".
    3. S'est produite lors de la charge de la base de données master depuis le dernier vidage de celui-ci avant la catastrophe.
    4. Après réussite, arrêtez et redémarrez SQL Server normalement. Passez à l'étape 6.
  6. Chacune des bases de données utilisateur charger à partir des fichiers faisant l'objet d'un dumping (et le journal des transactions exporte trop, le cas échéant).
  7. Arrêtez et redémarrez le serveur SQL Server.
  8. Vérifiez la disponibilité du système. Si la base de données master a été pas rechargé dans l'étape 5c, définissez les options de base de données pour chaque base de données. Exécutez un script des fonctionnalités afin de garantir le fonctionnement adéquat de SQL Server. Dans l'idéal, avant les utilisateurs sont publiés sur le système, de temps doivent être fournis à exécuter DBCC CHECKDB et NEWALLOC sur chaque base de données et DBCC TEXTALL et TEXTALLOC sur celles des bases de données et tables TEXT contenant champs. Cela est de s'assurer que le processus de migration n'a pas modifier les fichiers de manière indésirable.
  9. Une fois que les instructions DBCC en cours d'exécution affiche la base de données dans un souci de cohérence et le script de test de fonctionnalité réussit, permettent aux utilisateurs de reprendre.
Évaluation de récupération après sinistre assure la vérification du plan et est obtenue en obtenant matériel suffisant, fournissant la reprise après sinistre documenté les instructions de récupération et ayant une sauvegarde de SA ou DBA (quelqu'un qui n'est pas impliqué dans le plan de développement) récupérer le système sur cet ordinateur. Effectuer des évaluations de récupération après sinistre périodiques pour vérifier la vitalité du plan de récupération après sinistre en cours.

Si vos données sont précieuses, l'importance de Disaster Recovery Assessment ne peut pas surévalué. Quel est le risque d'entreprise si vous ne pouvez pas accéder à vos données retour ? Quel est le coût de retard chaque heure de dans l'obtention de votre système vers le haut et en cours d'exécution ? Cela n'est pas une situation de supposer que vos données sont récupérables rapidement, vérifiez qu'il ! Comprendre les étapes très soigneusement avant de temps et permet de minimiser le stress et l'incertitude imposées par les circonstances de certains catastrophe future.

Cet article a été écrite sous la forme d'une extension à la section Restauration de bases de données sur la page 48 du Guide de déploiement de Microsoft SQL Server 6.5 (trouvé sur le World Wide Web à l'adresse http://www.microsoft.com/sql/deploy.htm). Vous trouverez plus d'informations sur la base de données master DUMP LOAD SQLSERVR dans la documentation en ligne et dans la base de connaissances Microsoft.

Remarque: A «script des fonctionnalités de base"est un lot de code qui peut être utilisé pour illustrer rapidement le bon fonctionnement de la base de données à partir du point de vue d'une application spécifique. La plupart du temps il s'agit d'un fichier .sql avec des commandes SQL par lots exécuter le serveur à partir de ISQL. Pour d'autres applications, un fichier .bat est plus approprié car il peut contenir des commandes BCP et ISQL. Un script des fonctionnalités de base est très spécifique à l'application et peut se présenter sous différentes formes. Par exemple, sur un système de support de décision/Reporting, le script peut être simplement une copie d'un couple de votre clé de requêtes de rapport ; pour une transaction en ligne (OLTP) application de traitement qu'il peut s'agir de l'exécution d'un lot de procédures stockées pour exécuter des instructions INSERT, UPDATE et DELETE. L'objectif consiste à vérifier, d'un point de vue brute, que tout fonctionne comme prévu. Le script des fonctionnalités de base fournit un outil utile pour les SA ou le DBA doit être en mesure de voir que la base de données est revenue à un état acceptable, sans en fonction de l'utilisateur final pour la vérification.

Propriétés

Numéro d'article: 169039 - Dernière mise à jour: vendredi 14 novembre 2003 - Version: 3.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 4.21a Standard
  • Microsoft SQL Server 6.0 Standard
  • Microsoft SQL Server 6.5 Édition Standard
Mots-clés : 
kbmt kbenv kbhowto kbusage KB169039 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 169039
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Exclusion de responsabilité concernant les contenus obsolètes dans la Base de connaissances
Cet article concerne des produits pour lesquels Microsoft n'offre plus de support. Il est par conséquent fourni « en l'état » et ne sera plus mis à jour.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com