Partager via

Récupération d'urgence de SQL Server

  • Article

SQL Server : Récupération suite à des sinistres à l'aide de sauvegardes

Paul s. Randal

T ici n'est pas grand intérêt prise de sauvegardes SQL Server, sauf si vous savez comment les restaurer. Si vous avez quelque chose plus compliqué que juste une sauvegarde complète de la base de données, vous allez ont besoin de connaître certaines options de restauration pour pouvoir restaurer correctement votre base de données à l'endroit souhaité dans le temps.

C'est encore plus le cas si vous disposez d'une mise en page de base de données complexe ou d'une stratégie de sauvegarde complexe et que vous voulez être en mesure de restaurer, par exemple, un seul fichier ou un groupe de fichiers, ou de tirer parti de disponibilité partielle de la base de données.
Tant que vous disposez d'une stratégie de sauvegarde efficace et vos sauvegardes sont valides, vous devez être en mesure de récupérer à partir d'un incident au sein de votre objectif de temps de récupération (RTO) et à votre objectif de point de récupération (RPO). Dans le premier article de cette série de trois parties, j'ai abordé les différents types de sauvegardes et comment élaborer une stratégie de sauvegarde (voir «Comprendre les sauvegardes SQL Server» dans le numéro de juillet 2009).

Dans cet article, je Vais vous expliquer comment fonctionne la restauration et comment exécuter certaines des opérations de restauration plus courantes. Il peut être utile si vous avez lu l'article de sauvegarde et le matériel d'arrière-plan que je l'ai mentionné dans l'introduction de cet article. Je vais également expliquer quelques opérations difficiles plus, telles qu'effectuant une restauration point-à-temps et une restauration en ligne petit à petit avec disponibilité partielle de la base de données.

Tout comme dans l'article précédent sur BACKUP, je vais vous expliquer le fonctionne de la syntaxe de RESTORE ou parcourez les étapes spécifiques de toutes les opérations de restauration. Documentation en ligne effectue un travail de cette excellente. Voir"RESTORE (Transact-SQL)"pour plus d'informations, notamment les exemples répartis dans la rubrique. Il existe en fait autant d'options pour RESTORE qu'il s'agit d'une rubrique pour expliquer les entiers autre ! " Sauvegarde et restauration de rubriques Comment relatives aux (SQL Server Management Studio)«Explique comment utiliser les outils pour effectuer des restaurations.

Les quatre phases de restauration

Commençons par le fonctionne restauration. Une opération de restauration a jusqu'à quatre phases :

  1. Création de fichier et d'initialisation
  2. Copie de journal de données et/ou de transaction
  3. Rétablir la phase de récupération
  4. Annuler la phase de récupération

Un des principaux objectifs de récupération d'urgence est de réactiver la base de données aussi rapidement que possible. Si votre plan de récupération d'urgence implique la restauration de sauvegardes (au lieu de, disons, basculement vers un miroir de base de données), vous allez le processus de restauration doit être aussi rapidement que possible. Avec chacun des quatre étapes de restauration esprit, y a-t-il quelque chose que vous pouvez faire pour accélérer les ?

La première étape peut être ignoré essentiellement si les fichiers de données et journaux existent déjà. Cela signifie que si vous avez l'intention d'écraser une base de données existante, ne pas supprimer la base de données avant d'effectuer la restauration. Au lieu de cela, utilisez l'option WITH REPLACE à la première opération de restauration pour indiquer à SQL Server d'utiliser les fichiers existants. Si les fichiers n'existent pas, ils créés et initialisés puis. La création des fichiers est très rapide, mais le processus de zéro-initialisation les peut être très lent.

Pour des raisons de sécurité et par défaut, tous les fichiers de base de données sont initialisées à zéro. Vous pouvez activer l'initialisation instantanée des fichiers pour l'instance de SQL Server, qui ignore le processus de réinitialisation de fichier de données de créer et de croissance des opérations, y compris celles requises lors d'une restauration--éventuellement l'enregistrement des heures de temps d'arrêt, même si les fichiers de données sont uniquement gigaoctets de taille. Fichiers journaux des transactions sont toujours initialisées à zéro en raison de la nature circulaire du journal des transactions lui-même.

Vous pouvez lire plus d'informations sur tout ceci, avec des références à la documentation en ligne, dans mon «Initialisation instantanée» catégorie du billet de blog.

Vous vous demandez peut-être à propos de la deuxième phase--pourquoi l'élément stipule «et/ou un journal des transactions» ? Si vous lisez l'article précédent, vous allez n'oubliez pas que toutes les sauvegardes complètes et différentielles également incluent certains enregistrements du journal des transactions, pour activer la base de données restaurée à partir d'un point cohérent dans le temps. Phase 2 est une opération de copie pure--aucun traitement des données n'est effectuée--; la principale pour accélérer ce consiste à avoir un sous-système d'e/S better-performing. Il s'agit d'une le plusieurs fois lorsqu'il est acceptable pour «lever matériel au problème.»

L'autre pour accélérer la phase de copie consiste à utiliser un type de technologie de compression de sauvegarde, soit natif pour SQL Server 2008 ou via un des différentes solutions de tiers. Les deux parties de la phase de copie sont lecture à partir du support de sauvegarde et écriture vers les fichiers de données ou journal. Si vous pouvez faire moins de lectures (à l'aide de supports de sauvegarde compressés), vous pouvez accélérer le processus global, aux dépens d'une petite quantité de ressources processeur.

Phases trois et quatre sont sur l'exécution de récupération sur le journal des transactions pour ramener la base de données à un point cohérent dans le temps. J'ai expliqué les détails de récupération dans l'article de février 2009»Enregistrement de compréhension et de récupération dans SQL Server". Notez que les quatre phases est facultatif, comme je l'expliquerai plus tard.

Suffisant de dire que le journal des transactions plus qui doivent être récupérées lors d'une restauration, plue la restauration prendra. Cela signifie que si, par exemple, vous disposez d'une sauvegarde complète de la base de données à partir d'une semaine et toutes les heures sont essentiellement des sauvegardes du journal des transactions depuis puis, le processus de restauration relire toutes les transactions à partir de la semaine dernière avant de terminer. J'ai abordé une solution pour cela dans l'article précédent--l'ajout de sauvegardes différentielles dans une stratégie de sauvegarde de journal full plus.

Une sauvegarde différentielle de base de données contient toutes les pages du fichier de données qui ont été modifiés depuis la dernière sauvegarde complète de la base de données et peuvent être utilisés dans une opération de restauration pour éviter d'avoir à relire toutes les transactions effectuées durant la période entre la sauvegarde complète de la base de données et la sauvegarde différentielle de base de données. Ceci peut réduire considérablement le temps nécessaire pour restaurer la base de données, mais au détriment d'une stratégie de sauvegarde légèrement plus compliquée.

Pour trouver plus d'informations, consultez la rubrique documentation en ligne"Optimisation des performances de sauvegarde et de restauration dans SQL Server".

Configuration requise pour la restauration ?

Lorsque sinistre, la première chose que vous avez besoin de faire est de travailler en ce qui a été endommagé, comme cela se passe pour dicter les actions à suivre pour effectuer la récupération d'urgence. Pour la défaillance du support de stockage, les possibilités sont les suivantes :

  • Dommages pour l'ensemble de la base de données (par exemple, tout ce qui a été stockant la base de données a été détruit, ou la base de données était un seul fichier de données et il a été endommagé).
  • Endommager pour un seul groupe de fichiers d'une base de données multi-groupe de fichiers.
  • Endommager vers un fichier unique d'un groupe de fichiers multifichier.
  • Endommager à une seule page dans la base de données.
  • Dommages se propagent par le biais de la base de données.

Vous pouvez vérifier les dommages en parcourant le journal des erreurs de SQL Server pour les notifications de fichier (s) sont inaccessibles, page en lecture des erreurs se sont produites (par instance, échecs de somme de contrôle de page ou une erreur de détection de pages endommagées), ou que la corruption générale a été rencontrée. Si ont été touchées, il est habituel pour exécuter l'opération de vérification de cohérence DBCC CHECKDB pour vous faire une idée de comment répandue le dommage concerne.

Explication de la vérification de cohérence n'est pas abordée dans cet article, mais vous pouvez regarder une vidéo d'une présentation que j'ai effectuée sur le forum informatique Tech-Ed en novembre 2008 intitulée"Techniques de survie altération"et écouter un entretien TechNet Radio à partir de cette année aborder une corruption de la base de données (téléchargement direct sont des liens here).

Les incidents ne sont pas limitées aux défaillances de serveur ou de sous-système d'e/S--erreur humaine à prendre en compte est également. Tables de base de données (ou les données à partir de ceux-ci) sont souvent accidentellement supprimées par les applications mal programmées ou des instructions Transact-SQL un (le scénario «Je n'a pas réaliser que j'étais sur le serveur de production»). Dans ce cas, il peut être très difficile à figure en ce qui doit être restaurée et à partir de quel point dans le temps, surtout si la personne est propriétaire à ce que l'erreur. Vous obtiendrez peut-être chance à l'aide d'états standard à partir de la trace par défaut où l'opération DDL est toujours disponible ou l'instruction DELETE a été interceptée par votre propre enregistrement--mais souvent, il n'existe aucun enregistrement de qui a fait quoi à la base de données. J'aborderai la récupération à partir de cette situation plus en détail ultérieurement. Indépendamment de qui a effectué la suppression accidentelle de données ou lorsqu'il est devenu, plus vous attendez à récupérer--ou plus de temps qui s'écoule avant vous sont informés du problème--le plus complexe, il peut être à récupérer.

Par conséquent, une première étape que si la base de données est en cours d'exécution dans le modèle de récupération FULL et le journal des transactions est intacte, effectuez une sauvegarde de fin du journal pour vous assurer que toutes les transactions jusqu'au moment de l'incident sont sauvegardées. Cette sauvegarde du journal des transactions «final» aura tout jusqu'à l'heure de l'incident et peut être utilisée pour mettre la base de données restaurée aussi loin que possible, éventuellement temps réel.

En bref, vous devez déterminer ce que vous devez restaurer. Il devient alors une question de ce que vous êtes en mesure de restaurer.

Ce qu'est-ce que vous en mesure de restaurer ?

L'objectif de toute opération de restauration est de restaurer les sauvegardes moins possibles, afin que l'opération de restauration est aussi rapide que possible et se termine dans votre RTO, tout en permettant la répondent à votre ordre de fabrication LANCÉ.

La principale question à poser ici est «What sauvegardes ai-je en ma possession?» Si la sauvegarde seulement vous disposez est une sauvegarde complète de la base de données à partir d'une semaine et l'intégralité de la base de données a été perdue, il est option de seule restauration--à un moment une semaine, perdre tout travail depuis puis. Pour résumer, votre stratégie de sauvegarde doit toujours vérifier que vous êtes en mesure de restaurer ce que vous devez en cas d'incident, comme je l'ai expliqué dans l'article précédent.

Vous avez par conséquent, comment pouvez-vous déterminer les sauvegardes disponibles ? Tout d'abord, vous pouvez interroger diverses tables d'historique dans la base de données msdb de sauvegarde. Ces tables contiennent un enregistrement de toutes les sauvegardes qui ont été prises dans l'instance de SQL Server depuis la dernière fois que les tables d'historique de sauvegarde ont été effacées.

Concerne les sauvegardes elles-mêmes, il est recommandé de nommer les fichiers de sauvegarde à inclure la base de données, le type de sauvegarde, date et l'heure afin que la sauvegarde peut être identifiée en un clin de œil. Si vous n'avez pas effectué cette opération, vous pouvez savoir ce qu'un fichier de sauvegarde contient à l'aide de la commande RESTORE HEADERONLY. Ceci affichera le contenu d'en-tête du fichier de sauvegarde, essentiellement les métadonnées qui décrivent la sauvegarde elle-même. Vous trouverez plus dans la rubrique documentation en ligne»Affichage des informations sur les sauvegardes".

À l'aide d'une de ces méthodes, vous essayez de déterminer la séquence de restauration à utiliser pour restaurer les données endommagées ou supprimées. Une séquence de restauration est un jeu de sauvegardes doit être restaurée et l'ordre approprié dans lequel les restaurer. La séquence de restauration peut être simple, telle qu'une sauvegarde complète (d'une base de données, groupe de fichiers ou un fichier), ou un ensemble complexe de complète, différentielle et sauvegardes du journal des transactions.

Par exemple, imaginez un scénario où la stratégie de sauvegarde comprend la base de données complète, différentielle de base de données et sauvegardes du journal des transactions. Si une panne du système se produit et les fichiers de données sont endommagés, quelle est la séquence de restauration ? La figure 1 illustre cet exemple.

Dans ce cas, la séquence de restauration le plus court et plus rapide est la dernière sauvegarde complète de la base de données (F), la dernière sauvegarde différentielle de la base de données (D2) et puis tous les autres sauvegardes du journal des transactions, jusqu'à et y compris la sauvegarde de la fin du journal (N7 et N8).

Un des problèmes difficiles lors de la planification d'une séquence de restauration consiste à trouver la sauvegarde du journal des transactions requis plus proche pour restaurer (parfois appelé recherche le «minimum LSN» ou «numéro de séquence minimum log»). Dans l'exemple de de la figure 1, uniquement sauvegardes du journal des transactions L7 et N8 sont nécessaires, car la sauvegarde différentielle de base de données D2 apporte la base de données à un point plus récent dans le temps que la transaction précédente sauvegardes du journal.

Figure 1 : Séquence de restauration exemple

SQL Server permettra précédent, les sauvegardes à restaurer, du journal des transactions mais ils ne seront pas utilisées et récupération d'urgence essentiellement simplement déchets time.Continuing mon exemple, que se passerait-il si la base de données différentielle sauvegarde D2 a été endommagé ou manquant ? La figure 2 illustre ce cas.

Figure 2 : Restaurer la séquence avec une sauvegarde de base de données différentielle dommages

Dans ce scénario, la séquence de restauration le plus court et plus rapide est la dernière sauvegarde complète de la base de données (F), la prochaine sauvegarde différentielle de base de données plus récente (D1) et ensuite tous les autres sauvegardes du journal des transactions (L4, L5, L6, L7 et N8). Cela est possible tant que sauvegardes D1, L4, L5 et L6 sont toujours disponibles. Il est important que vous ne supprimez pas de sauvegardes trop tôt ; sinon vous pourriez exécuter dans des problèmes durant un incident.

Par exemple, si la sauvegarde complète de la base de données F est endommagée, à moins que la sauvegarde complète de la base de données précédente est toujours disponible, la base de données ne sera pas récupérable. Si la sauvegarde différentielle de base de données D1 est supprimée dès que D2 s'achève, puis le scénario dans de la figure 2 ne sera pas possible, et la séquence de restauration impliquera toutes les sauvegardes du journal des transactions depuis la sauvegarde complète de la base de données--une séquence de restauration potentiellement très long.

Cela déclenche la question de "Lorsque doit supprimer vos précédentes sauvegardes?" La réponse est définitivement «IT dépend!» Si vous n'avez pas une obligation légale de conserver vos sauvegardes autour d'une certaine période de temps, puis il est à vous et dépend de la stratégie de sauvegarde que vous avez et la quantité d'espace disque est nécessaire. Quoi qu'il en soit, ne pas supprimer immédiatement les sauvegardes précédentes dès qu'une nouvelle provient ; il est conseillé de conserver au moins un ou deux complètes cycles de sauvegardes avant débarrasser des anciennes sauvegardes. Idéalement, vous devez tester vos sauvegardes avant de supprimer les plus anciens.

Sauvegardes des journaux des transactions, en général avoir chacun d'entre eux depuis la dernière sauvegarde complète de la base de données a été prise, comme c'est la séquence de restauration d'automne différée finale. Si la sauvegarde du journal une transaction unique à partir du journal des transactions sauvegarde «chaîne» est manquant ou endommagé, l'opération de restauration ne peut pas se poursuivre au-delà de l'écart. Comme je l'ai mentionné dans l'article précédent, la vérification de l'intégrité de vos sauvegardes est un élément essentiel de pouvoir restaurer correctement.

Vous pouvez en savoir plus sur découvrir ce que vous êtes en mesure de restaurer dans la rubrique documentation en ligne complète»Utilisation de séquences de restauration pour les bases de données SQL Server".

Scénarios de restauration exemple

Le scénario de restauration le plus courant implique une sauvegarde complète de la base de données et puis une ou plusieurs sauvegardes du journal des transactions pour ramener la base de données dans le temps. Cela est possible par l'intermédiaire de SQL Server Management Studio (SSMS) ou à l'aide de Transact-SQL, bien qu'il y a quelque chose que vous devez être conscient si vous avez l'intention d'utiliser directement les commandes RESTORE.

Lorsqu'une sauvegarde est restaurée, il existe trois options pour la fin de l'opération de restauration et ils tous sont liés à la phase UNDO de la récupération. Comme chaque sauvegarde successif dans la séquence de restauration est restaurée, la phase REDO de la récupération est toujours effectuée, mais la phase UNDO ne peut pas être effectuée tant que la dernière sauvegarde dans la chaîne de sauvegarde du journal des transactions a été restaurée. Cela est dû au fait que, dès la récupération est terminée, aucune autre sauvegarde de journal de transaction ne peut être appliqué, donc tous les restaure dans la séquence de restauration doit spécifier de ne pas exécuter la phase UNDO de la récupération.

La valeur par défaut, est malheureusement, pour exécuter la phase UNDO de la récupération--l'équivalent de l'aide de l'option WITH RECOVERY sur l'instruction RESTORE. Lorsque vous restaurez plusieurs sauvegardes, vous devez être prudent que chacun d'eux spécifie WITH NORECOVERY. En fait, la plus sûre consiste à utiliser l'option WITH NORECOVERY sur toutes les restaurations dans la séquence de restauration, puis manuellement terminer la récupération par la suite. Voici un exemple de code Transact-SQL pour restaurer une sauvegarde complète de la base de données et deux sauvegardes du journal des transactions, puis terminer manuellement la récupération afin de rendre la base de données :

RESTORE DATABASE DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Full_051709_0000.bak'
AVEC REMPLACEMENT TOTAL DE CONTRÔLE, NORECOVERY ;
GO

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0100.bak'
AVEC NORECOVERY ;
GO

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
AVEC NORECOVERY ;
GO

RESTORE DATABASE DBMaint2008 WITH RECOVERY ;
GO

Notez que j'ai également utilisé l'option total de contrôle sur la restauration de la sauvegarde complète de la base de données pour vous assurer que les sommes de contrôle de page présentes dans la base de données restaurée sont vérifiés comme ils sont restaurés.

Si WITH NORECOVERY n'a pas été spécifié sur la première instruction RESTORE, l'erreur suivante est renvoyée :

Msg 3117, niveau 16, état 1, ligne 1
La sauvegarde différentielle ou de journal ne peut pas être restauré car aucun fichier n'est prêt à rollforward.
Msg 3013, niveau 16, état 1, ligne 1
RESTORE LOG s'arrête anormalement.

Vous devez être très prudent utiliser l'option de droite, sinon vous risquez de devoir redémarrer une séquence de restauration long : il n'existe aucun moyen pour annuler la récupération lorsqu'elle est terminée.

Toutefois, il existe une option intéressante ce type de fait qui--l'option WITH STANDBY. Il s'agit de la dernière des trois options que je l'ai mentionné précédemment. Il fonctionne en exécutant la phase UNDO de la récupération, mais il conserve une note de ce qu'il n'a (dans un fichier de «Annuler» dont vous spécifiez le nom et le chemin d'accès) et puis permet un accès en lecture seule à la base de données. La base de données est cohérente, mais vous avez la possibilité de poursuivre la séquence de restauration. Si vous décidez de continuer, l'annuler est inversé (en utilisant le contenu du fichier d'annulation) et ensuite le fichier journal des transactions suivant est restauré. Ceci est utile dans deux scénarios : Pour autoriser l'accès en lecture seule à une base de données secondaire envoi de journaux et permettant d'examiner le contenu de la base de données pendant la séquence de restauration.

Si l'incident que vous êtes à la récupération implique une suppression accidentelle d'une table, par exemple, vous souhaiterez effectuer une restauration point-à-temps. Il existe plusieurs façons pour ce faire, mais est le plus courant où vous souhaitez restaurer la base de données mais de vous assurer que la récupération ne passez pas après un certain temps. Dans ce cas, vous pouvez utiliser l'option WITH STOPAT pour empêcher la restauration du journal des transactions d'aller passé l'heure que vous connaissez la table a été supprimé. Par exemple, à l'aide de l'exemple Transact-SQL ci-dessus, si je souhaite empêcher que la base de données restaurée au-delà de 1 h 45, je pourrait utiliser la syntaxe suivante sur la deuxième instruction RESTORE LOG :

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
AVEC NORECOVERY, STOPAT = ' 2009 - 05 - 17 01:45:00.000 ' ;
GO

Vous pouvez combiner même STOPAT et STANDBY pour voir si c'était le point approprié dans le temps et ensuite, si ce n'est pas le cas, restaurez la sauvegarde du journal des transactions même avec un délai de quelques secondes plus tard et ainsi de suite. Ce type d'opération devient très fastidieux, mais il peut être la seule solution si vous ne savez pas quelle heure une opération a eu lieu.

Vous trouverez une discussion complète de ces options ainsi que d'autres pour l'instruction RESTORE dans la rubrique documentation en ligne»RESTORE arguments (Transact-SQL)".

Une des plus utiles nouvelles fonctionnalités introduites dans SQL Server 2005 Enterprise Edition a été disponibilité partielle de la base de données. Cette fonctionnalité permet une base de données multi-groupe de fichiers être en ligne et disponibles en tant que long comme au moins le groupe de fichiers primaire est en ligne. Évidemment, vous ne pouvez pas accéder aux données dans des groupes de fichiers hors connexion, mais cette fonctionnalité permet une très grande base de données à diviser en groupes de fichiers distinct pour récupération plus facile et plus rapide. Une autre fonctionnalité d'entreprise uniquement qui a été ajoutée est la possibilité d'effectuer des restaurations étape par étape (par exemple, un seul groupe de fichiers à partir d'une base de données multi-groupe de fichiers) en ligne, tandis que le reste de la base de données est utilisé pour le traitement.

Ces deux fonctionnalités combinées activer certains scénarios de restauration relativement sophistiqué et efficace, aussi longtemps que la base de données a été établie de cette façon et les sauvegardes corrects existent.

Vous trouverez une excellente, approfondie article technique SQL Server intitulé «Microsoft SQL Server 2005 partiel de la base de données disponibilité» avec certains exemples complètes disponibles à tinyurl.com/mbpa65. Il existe également un enregistrement de 75 minutes de Kimberly l. Tripp fournissant une session Tech-Ed EMEA intitulée"Disponibilité SQL Server 2005 VLDB et les stratégies de récupération«qui vaut bien la surveillance.

Considérations lors de la restauration vers un emplacement différent

Le scénario de restauration la plus simple se produit lorsque la base de données est restaurée sur la même instance de SQL Server à laquelle il est généralement associée et portant le même nom. Lorsque vous déplacez plus absent (e) à partir de ce scénario, la suite de l'opération de restauration devient plus complexe.

Si la base de données est restaurée sur la même instance mais avec un nom différent, il se peut que vous deviez apporter des modifications aux éléments tels que DTS/SSIS packages, les plans de maintenance de base de données, chaînes de l'application et tout ce qui s'appuie sur un nom de base de données.

Si la base de données est restaurée sur une instance différente sur le même serveur, les choses deviennent beaucoup plus compliqués :

  • Les connexions SQL Server seront différentes ou n'existent pas.
  • Travaux de l'Agent SQL et des packages DTS/SSIS seront différents ou n'existent pas.
  • La base de données master est différent, par conséquent, les procédures stockées définies par l'utilisateur est peut-être manquants.
  • Le nom de l'instance SQL Server seront différent, donc il peut y avoir des problèmes de connectivité client.
  • Si la base de données est restaurée sur une instance sur un autre serveur, tout ce qui est répertorié s'applique, mais il peut être ajoutée problèmes de sécurité comme comptes Windows peuvent être différents, et ils peuvent être dans un autre domaine de Windows.
  • Une autre considération est l'édition de SQL Server la base de données est restaurée sur. Il existe certaines fonctionnalités, si elle est utilisée dans la base de données, la base de données «Enterprise-only»--il ne peut pas être restaurée sur une édition standard (ou inférieur) instance SQL Server.
  • Dans SQL Server 2000 et versions antérieures, ce n'est pas un problème. Dans SQL Server 2005, si la table ou le partitionnement de l'index est utilisé, la base de données est «Enterprise-only.» Dans SQL Server 2008, la liste de fonctionnalités est :
  • Capture de données modifiées
  • Chiffrement de données transparent
  • Compression des données
  • Partitionnement

Tous ces nécessitent des privilèges sysadmin pour permettre à l'exception de compression des données, qui peut être activée par un propriétaire de la table ainsi potentiellement interrompre un plan de récupération d'urgence impliquant la restauration vers une instance de Standard Edition. Vous pouvez indiquer si une de ces fonctionnalités sont utilisée dans la base de données à l'aide de la DMV sys.dm_db_persisted_sku_features et ajuster votre plan de récupération d'urgence en conséquence.

Retrouvez vos connaissances

Tout comme avec le premier article de la série de sauvegardes, il y a beaucoup de facettes des opérations de restauration que je n'ai pas d'espace pour couvrir. Maintenant que vous connaissez les notions de base, toutefois, vous pouvez plonger dans certains des liens de la documentation en ligne et de blog pour plus d'informations. Le meilleur endroit pour démarrer dans la documentation en ligne est la rubrique"Vue d'ensemble de récupération (SQL Server) et de restauration". Vous trouverez également un grand nombre d'informations sur mon blog, commençant par la catégorie de sauvegarde/restauration.

Le principal takeaway que j'aimerais vous pour accéder à partir de cet article est que pour récupérer avec succès une base de données à l'aide de sauvegardes, vous devez pratique pour vous assurer que vous savez comment procéder. Vous ne souhaitez pas être apprendre la syntaxe de la commande RESTORE pendant une situation de récupération d'urgence high-pressure. Vous observerez peut-être que votre stratégie de sauvegarde ne vous permet pas à récupérer dans les besoins de votre entreprise. Peut-être sont trop longues pour pouvoir restaurer les sauvegardes, peut-être que vos sauvegardes de journal sont accidentellement écraser mutuellement ou peut-être que vous avez oublié de sauvegarder le certificat de serveur utilisé pour activer le cryptage de base de données transparent dans SQL Server 2008.

De loin la meilleure façon de préparer en cas d'urgence consiste à disposer d'un plan de restauration qui répertorie les étapes à franchir et avoir un ensemble de scripts qui vous aide à identifier les sauvegardes existent et de l'ordre dans lequel les restaurer. J'apprécie toujours de dire qu'il doit être écrit par l'administrateur de base de données plus senior de l'équipe et testé par la base de données plus junior--pour vous assurer que tout le monde peut suivre les étapes en toute sécurité. Toutefois, si vous êtes un administrateur de base de données involontaire, vous vous aurez besoin de rassembler un plan vous-même et vous assurer que vous pouvez le suivre.

Dans le prochain article, j'expliquerai comment faire pour récupérer à partir d'une corruption de la base de données si vous ne disposez pas des sauvegardes et pourquoi vous pouvez choisir d'exécuter une opération de réparation même si vous disposez des sauvegardes.
Dans la moyenne des temps de bon fonctionnement et comme toujours, si vous avez des commentaires ou questions, supprimer m'une ligne-- Paul@SQLskills.com.

Grâce à Kimberly l. Tripp pour fournir une étude technique de cet article.

Randal à Paul s. est le directeur de gestion de directeur régional général SQLskills.com, MVP SQL Server et Microsoft. Il a travaillé sur l'équipe SQL Server Storage Engine chez Microsoft de 1999 à 2007. Randal a écrit DBCC CHECKDB/repair pour SQL Server 2005 et était responsable de Core Storage Engine pendant le développement de SQL Server 2008. Randal est un expert de récupération d'urgence, haute disponibilité et de la maintenance de base de données et un présentateur régulière à des conférences à travers le monde. Blogs he à SQLskills.com/blogs/paul et se trouve sur Twitter comme @ PaulRandal.