Résoudre les problèmes de configuration de la mise en miroir de bases de données (SQL Server)

Cette rubrique fournit des informations pour vous aider à résoudre les problèmes de configuration d’une session de mise en miroir de bases de données.

Remarque

Vérifiez que vous respectez tous les prérequis pour la mise en miroir de bases de données.

Problème	Résumé
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 suggère de vérifier le nom de l’adresse réseau et de réémettre la commande. Pour plus d’informations, consultez la rubrique MSSQLSERVER_1418 .
Comptes	Traite des conditions nécessaires à la configuration correcte des comptes sous lesquels SQL Server s'exécute.
Points de terminaison	Décrit les conditions requises pour configurer correctement le point de terminaison de mise en miroir de bases de données de chaque instance de serveur.
SystemAddress	Résume les alternatives permettant de spécifier le nom système d’une instance de serveur dans une configuration de mise en miroir de bases de données.
Accès réseau	Documente l’exigence que chaque instance de serveur puisse accéder aux ports de l’autre instance de serveur ou d’instances via TCP.
Préparation de la base de données miroir	Résume les exigences de préparation de la base de données miroir pour permettre le démarrage de la mise en miroir.
Échec de l’opération de création de fichier	Décrit comment répondre à une opération de création de fichier ayant échoué.
Démarrage de la mise en miroir à l’aide de Transact-SQL	Décrit l’ordre requis pour les instructions ALTER DATABASE database_name SET PARTNER ='partner_server' .
Transactions inter-bases de données	Un basculement automatique peut entraîner une résolution automatique et éventuellement incorrecte des transactions incertaines. Pour cette raison, la mise en miroir de bases de données ne prend pas en charge les transactions entre bases de données.

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 s’exécutent dans les mêmes comptes de domaine, les chances de configuration incorrecte sont réduites.
2. Si les comptes s’exécutent dans différents domaines ou ne sont pas des comptes de domaine, la connexion d’un compte doit être créée dans master sur l’autre ordinateur, et cette connexion doit recevoir des autorisations CONNECT sur le point de terminaison. Pour plus d’informations, consultez Gérer les métadonnées durant la mise à disposition d’une base de données sur une autre instance de serveur (SQL Server). Cela inclut le compte de service réseau.
Si SQL Server s’exécute en tant que service qui utilise le compte système local, vous devez utiliser des certificats pour l’authentification. Pour plus d’informations, consultez Utiliser des certificats pour un point de terminaison de mise en miroir de bases de données (Transact-SQL).

Points de terminaison

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

Assurez-vous que chaque instance de serveur (le serveur principal, le serveur miroir et le témoin, le cas échéant) possède 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 la forme d’authentification, créez un point de terminaison de mise en miroir de bases de données pour l’authentification Windows (Transact-SQL) ou utilisez des certificats pour un point de terminaison de mise en miroir de bases de données (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 les vues de catalogue sys.database_mirroring_endpoints et sys.tcp_endpoints .
Pour les problèmes de configuration complexes de la mise en miroir de bases de données, nous vous recommandons de vérifier chaque instance de serveur pour déterminer si elle é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 suivante.
```
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 endpoint, utilisez l’instruction Transact-SQL suivante.
```
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 RÔLE est correct. Sur chaque instance de serveur, utilisez l’instruction Transact-SQL suivante.
```
SELECT role FROM sys.database_mirroring_endpoints;  
GO  
```
Pour plus d’informations, consultez sys.database_mirroring_endpoints (Transact-SQL).

La connexion pour le compte de service à partir de l’autre instance de serveur nécessite l’autorisation CONNECT. Assurez-vous que la connexion de l'autre serveur possède l'autorisation CONNECT. Pour déterminer qui a l’autorisation CONNECT pour un point de terminaison, sur chaque instance de serveur, utilisez l’instruction Transact-SQL suivante.

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

Pour le nom système d’une instance de serveur dans une configuration de mise en miroir de bases de données, vous pouvez utiliser n’importe quel nom qui identifie sans ambiguïté le système. L’adresse du serveur peut être un nom système (si les systèmes se trouvent dans le même domaine), un nom de domaine complet ou une adresse IP (de préférence, une adresse IP statique). L’utilisation du nom de domaine pleinement qualifié est garantie de fonctionner. Pour plus d’informations, consultez Spécifier une adresse réseau de serveur (Mise en miroir de bases de données).

Accès réseau

Chaque instance de serveur doit être en mesure d’accéder aux ports de l’autre instance de serveur ou d’instances via TCP. Cela est particulièrement important si les instances de serveur se trouvent dans des domaines différents qui ne font pas confiance les uns aux autres (domaines non approuvés). Cela limite une grande partie de la communication entre les instances de serveur.

Préparation de la base de données miroir

Si vous démarrez la mise en miroir pour la première fois ou si vous la recommencez après la suppression de la mise en miroir, vérifiez que la base de données miroir est préparée pour la mise en miroir.

Lorsque vous créez la base de données miroir sur le serveur miroir, veillez à restaurer la sauvegarde de la base de données principale en spécifiant le même nom de base de données WITH NORECOVERY. En outre, toutes les sauvegardes de journal créées après cette sauvegarde doivent également être appliquées, toujours sans restauration.

En outre, nous vous recommandons, si possible, que le chemin d’accès du fichier (y compris la lettre de lecteur) de la base de données miroir soit identique à celui de la base de données principale. Si les chemins d’accès au fichier doivent différer, par exemple, si la base de données principale se trouve sur le lecteur « F : », mais que le système miroir ne dispose pas d’un lecteur F : , vous devez inclure l’option MOVE dans l’instruction RESTORE.

Important

Si vous déplacez les fichiers de base de données lorsque vous créez la base de données miroir, il se peut que vous ne puissiez pas ajouter de fichiers à la base de données ultérieurement sans que la mise en miroir soit suspendue.

Si la mise en miroir de bases de données a été arrêtée, toutes les sauvegardes de journaux suivantes effectuées sur la base de données principale doivent être appliquées à la base de données miroir avant que la mise en miroir puisse être redémarrée.

Pour plus d’informations, consultez Préparer une base de données miroir pour la mise en miroir (SQL Server).

Échec de l’opération Create-File

L’ajout d’un fichier sans impact sur une session de mise en miroir nécessite que le chemin d’accès du fichier existe sur les deux serveurs. Par conséquent, si vous déplacez les fichiers de base de données lors de la création de la base de données miroir, une opération de complément ultérieure peut échouer sur la base de données miroir et entraîner la suspension de la mise en miroir.

Pour résoudre 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 journal contenant l’opération de fichier complémentaire sur le serveur principal et restaurer manuellement la sauvegarde du 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 de fichier spécifié sur le serveur miroir et restaure le nouveau fichier à cet emplacement.
Pour préparer la base de données à une nouvelle session de miroir, le propriétaire doit également restaurer SANS RÉCUPÉRATION toutes les autres sauvegardes de journaux en attente depuis le serveur principal.

Pour plus d’informations, consultez Suppression de la mise en miroir de bases de données (SQL Server),préparer une base de données miroir pour la mise en miroir (SQL Server),établir une session de mise en miroir de bases de données à l’aide de l’authentification Windows (Transact-SQL), utiliser des certificats pour un point de terminaison de mise en miroir de bases de données (Transact-SQL) ou établir une session de mise en miroir de bases de données à l’aide de l’authentification Windows (SQL Server Management Studio).

Démarrage de la mise en miroir à l’aide de Transact-SQL

L’ordre dans lequel les instructions ALTER DATABASE database_name SET PARTNER ='partner_server' sont émises est très importante.

La première instruction doit être exécutée sur le serveur miroir. Lorsque cette instruction est émise, le serveur miroir n’essaie pas de contacter une autre instance de serveur. Au lieu de cela, le serveur miroir indique à sa base de données d’attendre que le serveur miroir ait été contacté par le serveur principal.
La deuxième instruction ALTER DATABASE doit être exécutée sur le serveur principal. Cette instruction amène le serveur principal à essayer de se connecter au serveur miroir. Une fois cette connexion créée, le miroir tente ensuite de se connecter au serveur principal sur une autre connexion.

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

Remarque

Pour plus d’informations sur l’utilisation de SQL Server Management Studio pour démarrer la mise en miroir, consultez Établir une session de mise en miroir de bases de données à l’aide de l’authentification Windows (SQL Server Management Studio).

Transactions inter-bases de données

Lorsqu’une base de données est mise en miroir en mode haute sécurité avec basculement automatique, un basculement automatique peut entraîner une résolution automatique, éventuellement incorrecte, des transactions douteuses. Si un basculement automatique se produit sur l’une ou l’autre base de données pendant qu’une transaction inter-bases de données est validée, des incohérences logiques peuvent se produire entre les bases de données.

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

Transaction qui met à jour plusieurs bases de données dans la même instance de SQL Server.
Transactions qui utilisent microsoft Distributed Transaction Coordinator (MS DTC).

Pour plus d’informations, consultez Transactions inter-bases de données non prises en charge pour la mise en miroir de bases de données ou les groupes de disponibilité AlwaysOn (SQL Server).

Voir aussi

Configuration de la mise en miroir de bases de données (SQL Server)
Sécurité du transport pour la mise en miroir de bases de données et les groupes de disponibilité AlwaysOn (SQL Server)

Last updated on 2017-06-13

Partager via