Article
09/27/2010

Résolution des problèmes de déploiement de la mise en miroir de bases de données

Cette rubrique fournit des informations destinées à résoudre les problèmes de configuration d'une session de mise en miroir de base de données.

[!REMARQUE]

Assurez-vous que vous prenez en charge tous les éléments requis pour la mise en miroir de bases de données.

Question	Résumé
Comptes	Traite des conditions nécessaires à la configuration correcte des comptes sous lesquels SQL Server s'exécute.
Points de terminaison	Traite des conditions nécessaires à la configuration correcte du point de terminaison de mise en miroir de bases de données de chaque instance de serveur.
Adresse système	Résume les alternatives pour la spécification du nom système d'une instance de serveur dans une configuration de mise en miroir de bases de données.
Accès réseau	Traite de l'exigence selon laquelle chaque instance de serveur doit être autorisée à accéder aux ports de l'autre instance ou des autres instances de serveur par le biais du protocole TCP.
Préparation de la base de données miroir	Résume les conditions requises pour la préparation de la base de données miroir afin de permettre le démarrage de la mise en miroir.
Échec d'opération de création de fichier	Décrit comment réagir à un échec d'opération de création de fichier.
Démarrage de la mise en miroir (Transact-SQL)	Décrit l'ordre requis pour les instructions ALTER DATABASE nom_base_de_données SET PARTNER ='serveur_partenaire'.

Comptes

Les comptes sous lesquels SQL Server est en cours d'exécution doivent être configurés correctement.

Les comptes possèdent-ils les autorisations appropriées ?
1. Si les comptes fonctionnent dans les mêmes comptes de domaine, les risques de problèmes de configuration sont réduits.
2. Si les comptes s'exécutent dans des domaines différents ou ne sont pas des comptes de domaine, la connexion d'un compte doit être créée dans la base de données master sur l'autre ordinateur et des autorisations CONNECT doivent être octroyées à cette connexion sur le point de terminaison. Pour plus d'informations, consultez Gestion des métadonnées lors de la mise à disposition d'une base de données sur une autre instance de serveur. Ceci inclut le compte intégré Service réseau.
Si SQL Server est en cours d'exécution en tant que service utilisant le compte système local, vous devez utiliser des certificats pour l'authentification. Pour plus d'informations, consultez Utilisation de certificats pour la mise en miroir de bases de données.

Points de terminaison

Les points de terminaison doivent être correctement configurés.

Vérifiez que chaque instance de serveur (serveur principal, serveurs miroir et témoin, le cas échéant) a un point de terminaison de mise en miroir de bases de données. Pour plus d'informations, consultez sys.database_mirroring_endpoints (Transact-SQL) et, selon le mode d'authentification, Procédure : créer un point de terminaison de mise en miroir pour l'authentification Windows (Transact-SQL) ou Procédure : autoriser la mise en miroir de bases de données à utiliser des certificats pour les connexions sortantes (Transact-SQL).
Vérifiez les numéros de ports.

Pour identifier le port actuellement associé au point de terminaison de mise en miroir de bases de données d'une instance de serveur, utilisez l'instruction Transact-SQL ci-dessous.
```
SELECT type_desc, port FROM sys.tcp_endpoints;
GO
```
Pour les problèmes de configuration de la mise en miroir de bases de données qu'il est difficile d'expliquer, nous vous conseillons d'examiner chaque instance de serveur pour déterminer si elle est à l'écoute sur les ports appropriés. Pour plus d'informations sur la vérification de la disponibilité des ports, consultez MSSQLSERVER_1418.
Vérifiez que les points de terminaison sont démarrés (STATE=STARTED). Sur chaque instance de serveur, utilisez l'instruction Transact-SQL ci-dessous.
```
SELECT state_desc FROM sys.database_mirroring_endpoints
```
Pour plus d'informations sur la colonne state_desc, consultez sys.database_mirroring_endpoints (Transact-SQL).

Pour démarrer un point de terminaison, utilisez l'instruction Transact-SQL ci-dessous.
```
ALTER ENDPOINT Endpoint_Mirroring 
STATE = STARTED 
AS TCP (LISTENER_PORT = <port_number>)
FOR database_mirroring (ROLE = ALL);
GO
```
Pour plus d'informations, consultez ALTER ENDPOINT (Transact-SQL).
Vérifiez que le ROLE est correct. Sur chaque instance de serveur, utilisez l'instruction Transact-SQL ci-dessous.
```
SELECT role FROM sys.database_mirroring_endpoints;
GO
```
Pour plus d'informations, consultez sys.database_mirroring_endpoints (Transact-SQL).

Assurez-vous que la connexion de l'autre serveur possède l'autorisation CONNECT. Pour déterminer qui possède une autorisation CONNECT pour un point de terminaison, sur chaque instance de serveur, utilisez l'instruction Transact-SQL ci-dessous.

SELECT 'Metadata Check';
SELECT EP.name, SP.STATE, 
   CONVERT(nvarchar(38), suser_name(SP.grantor_principal_id)) 
      AS GRANTOR, 
   SP.TYPE AS PERMISSION,
   CONVERT(nvarchar(46),suser_name(SP.grantee_principal_id)) 
      AS GRANTEE 
   FROM sys.server_permissions SP , sys.endpoints EP
   WHERE SP.major_id = EP.endpoint_id
   ORDER BY Permission,grantor, grantee; 
GO

Adresse système

Comme nom système d'une instance de serveur dans une configuration de mise en miroir de bases de données, vous pouvez utiliser tout nom qui identifie sans ambiguïté le système. L'adresse de serveur peut être un nom système (si les systèmes sont dans le même domaine), un nom de domaine complet ou une adresse IP (de préférence statique). L'utilisation du nom de domaine complet garantit un fonctionnement correct. Pour plus d'informations, consultez Spécification d'une adresse réseau de serveur (mise en miroir de base de données).

Accès réseau

L'accès aux ports de l'autre instance ou des autres instances de serveur doit être autorisé via TCP à chaque instance de serveur. Ceci est d'autant plus important que les instances de serveur peuvent se trouver dans différents domaines, entre lesquels aucune relation d'approbation n'a été établie (domaines non approuvés). Ce qui réduit considérablement les communications entre les instances de serveur.

Préparation de la base de données miroir

Que vous démarriez la mise en miroir pour la première fois ou que vous la redémarriez après l'avoir supprimée, vérifiez que la base de données est préparée pour la mise en miroir.

Lors de la création de la base de données en miroir sur le serveur miroir, assurez-vous que vous restaurez la sauvegarde de la base de données principale en spécifiant le même nom de base de données à l'aide de WITH NORECOVERY. En outre, toutes les sauvegardes du journal créées après la réalisation de cette sauvegarde doivent également être appliquées, à nouveau avec WITH NORECOVERY.

En outre, nous recommandons, si possible, que le chemin d'accès (notamment la lettre de lecteur) de la base de données miroir soit identique au chemin d'accès de la base de données principale. Si les structures de fichiers doivent différer, par exemple si la base de données principale se trouve sur le lecteur « F: », alors qu'aucun lecteur F: ne se trouve sur le système miroir, vous devez inclure l'option MOVE dans l'instruction RESTORE.

Important

Si vous déplacez les fichiers de base de données pendant la création de la base de données miroir, vous risquez de ne pas pouvoir ajouter ultérieurement de fichiers à la base de données sans suspendre la mise en miroir.

Si la mise en miroir de bases de données a été arrêtée, toutes les sauvegardes du journal réalisées ultérieurement sur la base de données principale doivent être appliquées à la base de données miroir avant de redémarrer la mise en miroir.

Pour plus d'informations, consultez Procédure : préparer une base de données miroir pour la mise en miroir (Transact-SQL).

Échec d'opération de création de fichier

Pour pouvoir ajouter un fichier sans compromettre une session de mise en miroir, il est nécessaire 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 corriger le problème :

Le propriétaire de la base de données doit supprimer la session de mise en miroir et restaurer une sauvegarde complète du groupe de fichiers qui contient le fichier ajouté.
Le propriétaire doit ensuite sauvegarder le fichier journal contenant l'opération d'ajout de fichier sur le serveur principal et restaurer manuellement la sauvegarde de fichier journal sur la base de données miroir à l'aide des options WITH NORECOVERY et WITH MOVE. Cette opération crée le chemin d'accès spécifié sur le serveur miroir et restaure le nouveau fichier à cet emplacement.
Pour préparer la base de données pour une nouvelle session de mise en miroir, le propriétaire doit également restaurer à l'aide de WITH NO RECOVERY toutes les autres sauvegardes de fichiers journaux à partir du serveur principal.

Pour plus d'informations, consultez Suppression d'une mise en miroir des bases de données, Procédure : préparer une base de données miroir pour la mise en miroir (Transact-SQL), Procédure : établir une session de mise en miroir de bases de données au moyen de l'authentification Windows (Transact-SQL), Utilisation de certificats pour la mise en miroir de bases de données ou Procédure : configurer une session de mise en miroir de bases de données (SQL Server Management Studio).

Démarrage de la mise en miroir (Transact-SQL)

L'ordre dans lequel les instructions ALTER DATABASE database_name SET PARTNER ='serveur_partenaire' sont exécutées est essentiel.

La première instruction doit être exécutée sur le serveur miroir. Lorsque cette instruction est exécutée, le serveur miroir n'essaie pas de contacter d'autre instance de serveur. Au lieu de cela, le serveur miroir indique à sa base de données de patienter que le serveur miroir soit contacté par le serveur principal.
La seconde instruction ALTER DATABASE doit être exécutée sur le serveur principal. Cette instruction spécifie au serveur principal d'essayer de se connecter au serveur miroir. Une fois cette connexion créée, le miroir essaie de se connecter au serveur principal via une autre connexion.

Pour plus d'informations, consultez ALTER DATABASE (Transact-SQL).

Message d'erreur 1418

Ce message SQL Server indique que l'adresse réseau du serveur ne peut pas être atteinte ou n'existe pas, et il suggère de vérifier le nom de l'adresse réseau puis de réexécuter la commande. Pour plus d'informations, consultez MSSQLSERVER_1418.

Transactions entre bases de données

Lorsqu'une base de données est mise en miroir en mode haute sécurité avec le basculement automatique, un basculement automatique peut entraîner une résolution automatique et éventuellement incorrecte des transactions incertaines. Si un basculement automatique se produit sur l'une des bases de données pendant la validation d'une transaction entre bases de données, des incohérences logiques peuvent survenir entre les bases de données.

Les types de transactions entre bases de données qui peuvent être affectés par un basculement automatique sont les suivants :

Une transaction qui met à jour plusieurs bases de données dans la même instance SQL Server.
Les transactions qui utilisent Microsoft Distributed Transaction Coordinator (MS DTC).

Pour plus d'informations, consultez Mise en miroir de bases de données et transactions entre bases de données.

Voir aussi

Partager via