Préparer une base de données miroir pour la mise en miroir (SQL Server)

Article
06/25/2013

Avant qu'une session de mise en miroir de bases de données puisse commencer, le propriétaire de la base de données ou l'administrateur système doit s'assurer que la base de données miroir a été créée et qu'elle est prête pour la mise en miroir. La création d'une nouvelle base de données miroir requiert au minimum la réalisation d'une sauvegarde complète de la base de données principale puis d'une sauvegarde du journal, ainsi que la restauration de ces deux sauvegardes sur l'instance du serveur miroir, en utilisant WITH NORECOVERY.

Cette rubrique explique comment préparer une base de données miroir dans SQL Server 2012 à l'aide de SQL Server Management Studio ou de Transact-SQL.

Avant de commencer :

Spécifications

Limitations et restrictions

Recommandations

Sécurité
Pour préparer une base de données miroir existante pour redémarrer la mise en miroir
Pour préparer une nouvelle base de données miroir
Suivi : Après avoir préparé une base de données miroir
Tâches associées

Avant de commencer

Spécifications

Les instances du serveur miroir et du serveur principal doivent s'exécuter sur la même version de SQL Server. Il est possible que le serveur miroir dispose d'une version ultérieure de SQL Server, cependant, cette configuration n'est recommandée que lors d'un processus de mise à niveau planifié avec soin. Dans une telle configuration, vous courez le risque d'un basculement automatique, au cours duquel le déplacement des données est automatiquement suspendu, car les données ne peuvent pas être déplacées vers une version antérieure de SQL Server. Pour plus d'informations, consultez Réduire le temps d'indisponibilité des bases de données mises en miroir lors de la mise à niveau d'instances de serveur.
Les instances du serveur miroir et du serveur principal doivent s'exécuter sur la même édition de SQL Server. Pour plus d'informations sur la prise en charge de la mise en miroir de bases de données dans SQL Server 2012, consultez Fonctionnalités prises en charge par les éditions de SQL Server 2012.
La base de données doit utiliser le mode de récupération complète.

Pour plus d'informations, consultez Afficher ou modifier le mode de récupération d'une base de données (SQL Server) ou sys.databases (Transact-SQL) et ALTER DATABASE (Transact-SQL).
Le nom de la base de données miroir doit être le même que celui de la base de données principale.
La base de données miroir doit être dans l'état RESTORING pour que la mise en miroir fonctionne. Lors de la préparation d'une base de données miroir, vous devez utiliser RESTORE WITH NORECOVERY pour chaque opération de restauration. Au minimum, vous devrez restaurer avec RESTORE WITH NORECOVERY une sauvegarde complète de la base de données principale, suivie de toutes les sauvegardes de journaux suivantes.
Le système dans lequel vous envisagez de créer la base de données miroir doit posséder un lecteur de disque avec suffisamment d'espace pour contenir la base de données miroir.

Limitations et restrictions

Vous ne pouvez pas mettre en miroir les bases de données système master, msdb, temp ou model.
Vous ne pouvez pas mettre en miroir une base de données qui appartient à un groupe de disponibilité AlwaysOn.

Recommandations

Utilisez une sauvegarde complète très récente ou une sauvegarde différentielle récente de la base de données principale.
Si un travail de sauvegarde du journal est planifié pour s'exécuter très fréquemment sur la base de données principale, vous pouvez être amené à désactiver le travail de sauvegarde tant que la mise en miroir n'a pas commencé.
Si possible, le chemin d'accès (y compris la lettre de lecteur) de la base de données miroir doit être identique au chemin d'accès de la base de données principale.

Si les chemins d'accès des fichiers doivent différer, par exemple, si la base de données principale se trouve sur le lecteur « F: », mais que le système miroir n'a pas de lecteur F:, vous devez inclure l'option MOVE dans l'instruction RESTORE STATEMENT.

Important

Pour pouvoir ajouter un fichier pendant une session de mise en miroir sans compromettre la session, il faut que le chemin d'accès au fichier existe sur les deux serveurs. Par conséquent, si vous déplacez des fichiers de base de données lors de la création de la base de données miroir, une opération d'ajout de fichier ultérieure peut échouer sur la base de données miroir et entraîner la suspension de la mise en miroir. Pour plus d'informations sur le traitement d'une opération de création de fichier qui a échoué, consultez Résolution des problèmes de configuration de mise en miroir de bases de données (SQL Server).
Si la base de données principale comporte des catalogues de texte intégral, nous recommandons de consulter Mise en miroir de bases de données et catalogues de texte intégral (SQL Server).
Dans le cas d'une base de données de production, effectuez toujours les sauvegardes sur une unité distincte.

Sécurité

TRUSTWORTHY a la valeur OFF lorsqu'une base de données est sauvegardée. Par conséquent, la propriété TRUSTWORTHY d'une nouvelle base de données miroir a toujours la valeur OFF. Si la base de données doit être fiable après un basculement, des opérations de configuration supplémentaires sont requises. Pour plus d'informations, consultez Configurer une base de données miroir pour utiliser la propriété Trustworthy (Transact-SQL).

Pour plus d'informations sur l'activation du déchiffrement automatique de la clé principale d'une base de données miroir, consultez Configurer une base de données miroir chiffrée.

Autorisations

Propriétaire de base de données ou administrateur système.

[Haut de la page]

Pour préparer une base de données miroir existante pour redémarrer la mise en miroir

Si la mise en miroir a été supprimée et que la base de données miroir est toujours à l'état RECOVERING, vous pouvez redémarrer la mise en miroir.

Prenez au moins une sauvegarde du journal sur la base de données principale. Pour plus d'informations, consultez Sauvegarder un journal des transactions (SQL Server).
Sur la base de données miroir, restaurez à l'aide de RESTORE WITH NORECOVERY toutes les sauvegardes des journaux effectuées sur la base de données principale depuis la suppression de la mise en miroir. Pour plus d'informations, consultez Restaurer une sauvegarde de journal des transactions (SQL Server).

Pour préparer une nouvelle base de données miroir

Pour préparer une base de données miroir

[!REMARQUE]

Pour obtenir un exemple Transact-SQL de cette procédure, consultez Exemple (Transact-SQL), plus loin dans cette section.

Connectez-vous à l'instance de serveur principal.
Créez une sauvegarde complète ou une sauvegarde différentielle de la base de données principale.
- Créer une sauvegarde complète de base de données (SQL Server)
- Créer une sauvegarde différentielle de base de données (SQL Server).
En général, vous devez prendre au moins une sauvegarde du journal sur la base de données principale. Toutefois, une sauvegarde du journal peut s'avérer superflue, si la base de données vient d'être créée et qu'aucune sauvegarde du journal n'a été encore réalisée ou si le mode de récupération vient d'être modifié de SIMPLE à FULL.
- Sauvegarder un journal des transactions (SQL Server)
À moins que les sauvegardes se trouvent sur un lecteur réseau accessible à partir des deux systèmes, copiez les sauvegardes de la base de données et des journaux sur le système qui hébergera l'instance de serveur miroir.
Connectez-vous à l'instance de serveur miroir.
À l'aide de RESTORE WITH NORECOVERY, créez la base de données miroir en restaurant la sauvegarde complète de la base de données et, éventuellement, la sauvegarde différentielle de base de données la plus récente, sur l'instance de serveur miroir.

[!REMARQUE]

Si vous restaurez le groupe de fichiers de base de données par groupe de fichiers, veillez à restaurer l'intégralité de la base de données.
- Restaurer une sauvegarde de base de données (SQL Server Management Studio)
- RESTORE (Transact-SQL) et Arguments RESTORE (Transact-SQL).
À l'aide de RESTORE WITH NORECOVERY, appliquez les autres sauvegardes de fichiers journaux ou sauvegardes en attente à la base de données miroir.
- Restaurer une sauvegarde de journal des transactions (SQL Server)

Exemple (Transact-SQL)

Avant de démarrer une session de mise en miroir de bases de données, vous devez créer la base de données miroir. Vous devez procéder à cette opération avant de démarrer la session de mise en miroir.

L'exemple suivant utilise la base de données d'exemple AdventureWorks2012 qui emploie par défaut le mode de récupération simple.

Pour utiliser la mise en miroir de base de données sur la base de données AdventureWorks2012 , modifiez-la afin qu'elle utilise le mode de restauration complète :
```
USE master;
GO
ALTER DATABASE AdventureWorks 
SET RECOVERY FULL;
GO
```
Après avoir changé le mode de récupération de SIMPLE à FULL, créez une sauvegarde complète qui pourra être utilisée pour créer la base de données miroir. Dans la mesure où le mode de récupération vient d'être modifié, l'option WITH FORMAT est spécifiée pour créer un nouveau support de sauvegarde. Il peut se révéler utile de séparer les sauvegardes effectuées en mode de restauration complète des sauvegardes préalablement effectuées sous le mode de récupération simple. Pour les besoins de cet exemple, le fichier de sauvegarde (C:\AdventureWorks.bak) est créé sur le même lecteur que la base de données.

[!REMARQUE]

Dans le cas d'une base de données de production, il est conseillé de toujours effectuer les sauvegardes sur une unité distincte.

Sur l'instance de serveur principal (sur PARTNERHOST1), créez une sauvegarde complète de la base de données principale comme suit :
```
BACKUP DATABASE AdventureWorks 
    TO DISK = 'C:\AdventureWorks.bak' 
    WITH FORMAT
GO
```
Copiez cette sauvegarde complète sur le serveur miroir.
À l'aide de RESTORE WITH NORECOVERY, restaurez la sauvegarde complète sur l'instance de serveur miroir. La commande de restauration dépend si les chemins d'accès aux bases de données principale et miroir sont identiques ou non.
- Si les chemins d'accès sont identiques :
  
  Sur l'instance de serveur miroir (sur PARTNERHOST5), restaurez la sauvegarde complète comme suit :
```
RESTORE DATABASE AdventureWorks 
    FROM DISK = 'C:\AdventureWorks.bak' 
    WITH NORECOVERY
GO
```
- Si les chemins d'accès sont différents :
  
  Si le chemin d'accès de la base de données miroir n'est pas le même que celui de la base de données principale (lettres de lecteurs distinctes, par exemple), la création de la base de données miroir requiert l'intégration d'une clause MOVE dans l'opération de restauration.
  
  Important
  
  Si les chemins d'accès des bases de données principale et miroir diffèrent, vous ne pouvez pas ajouter de fichier. La raison tient à la réception du journal pour l'opération d'ajout de fichier puisque l'instance de serveur miroir tente de placer le nouveau fichier dans l'emplacement utilisé par la base de données principale.
  
  Par exemple, la commande ci-dessous restaure une sauvegarde d'une base de données principale résidant dans C:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Data\ dans un emplacement différent, D:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Data\, où la base de données miroir doit résider.
```
RESTORE DATABASE AdventureWorks
   FROM DISK='C:\AdventureWorks.bak'
   WITH NORECOVERY, 
      MOVE 'AdventureWorks_Data' TO 
         'D:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Data\AdventureWorks_Data.mdf', 
      MOVE 'AdventureWorks_Log' TO
         'D:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\Data\AdventureWorks_Log.ldf';
GO
```
Après avoir créé la sauvegarde complète, vous devez créer une sauvegarde du journal sur la base de données principale. Par exemple, l'instruction Transact-SQL suivante sauvegarde le journal dans le même fichier utilisé par la sauvegarde complète antérieure :
```
BACKUP LOG AdventureWorks 
    TO DISK = 'C:\AdventureWorks.bak' 
GO
```
Avant de démarrer la mise en miroir, vous devez appliquer la sauvegarde du journal requise (et toutes les sauvegardes de journal ultérieures).

Par exemple, l'instruction Transact-SQL ci-dessous restaure le premier journal provenant de C:\AdventureWorks.bak :
```
RESTORE LOG AdventureWorks 
    FROM DISK = 'C:\AdventureWorks.bak' 
    WITH FILE=1, NORECOVERY
GO
```
Si des sauvegardes de journal supplémentaires se produisent avant le démarrage de la mise en miroir, vous devez également restaurer toutes ces sauvegardes de journal, dans l'ordre, sur le serveur miroir, en utilisant WITH NORECOVERY.

Par exemple, l'instruction Transact-SQL ci-dessous restaure les deux journaux supplémentaires provenant de C:\AdventureWorks.bak :
```
RESTORE LOG AdventureWorks 
    FROM DISK = 'C:\AdventureWorks.bak' 
    WITH FILE=2, NORECOVERY
GO
RESTORE LOG AdventureWorks 
    FROM DISK = 'C:\AdventureWorks.bak' 
    WITH FILE=3, NORECOVERY
GO
```

Pour voir un exemple complet illustrant la configuration de la mise en miroir de bases de données, la configuration de la sécurité, la préparation de la base de données miroir, la définition des serveurs partenaires et l'ajout d'un témoin, consultez Configuration de la de mise en miroir de bases de données (SQL Server).

[Haut de la page]

Suivi : Après avoir préparé une base de données miroir

Si des sauvegardes de fichier journal supplémentaires ont été effectuées depuis votre opération RESTORE LOG la plus récente, vous devez appliquer manuellement chaque sauvegarde de journal supplémentaire, à l'aide de RESTORE WITH NORECOVERY.
Démarrez la session de mise en miroir. Pour plus d'informations, consultez Établir une session de mise en miroir de bases de données au moyen de l'authentification Windows (SQL Server Management Studio) ou Établir une session de mise en miroir de bases de données au moyen de l'authentification Windows (Transact-SQL).
Si vous avez désactivé le travail de sauvegarde sur la base de données principale, réactivez le travail.
Si la base de données doit être fiable après un basculement, des opérations de configuration supplémentaires sont requises après le début de la mise en miroir. Pour plus d'informations, consultez Configurer une base de données miroir pour utiliser la propriété Trustworthy (Transact-SQL).

[Haut de la page]