Utilisation de la mise en miroir de bases de données

Remarque

Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez Always On groupes de disponibilité à la place.

La mise en miroir de bases de données, introduite dans SQL Server 2005, est une solution permettant d’augmenter la disponibilité des bases de données et la redondance des données. SQL Server Native Client fournit une prise en charge implicite de la mise en miroir de bases de données. Par conséquent, le développeur n’a pas besoin d’écrire du code ou de prendre d’autres mesures une fois qu’il a été configuré pour la base de données.

La mise en miroir de bases de données, implémentée pour chaque base de données, conserve une copie d’une base de données de production SQL Server sur un serveur de secours. Ce serveur est un serveur de secours automatique ou semi-automatique, selon la configuration et l'état de la session de mise en miroir de bases de données. Un serveur de secours à chaud prend en charge le basculement rapide sans perte de transactions validées, et un serveur de secours chaud prend en charge le service forcé (avec une perte de données possible).

La base de données de production est appelée base de données principale, et la copie de secours est appelée base de données miroir. La base de données principale et la base de données miroir doivent résider sur des instances distinctes de SQL Server (instances de serveur), et elles doivent résider sur des ordinateurs distincts si possible.

L’instance du serveur de production, appelée serveur principal, communique avec l’instance de serveur de secours, appelée serveur miroir. Les serveurs principaux et miroirs agissent en tant que partenaires au sein d’une session de mise en miroir de bases de données. Si le serveur principal échoue, le serveur miroir peut rendre sa base de données dans la base de données principale par le biais d’un processus appelé basculement. Par exemple, Partner_A et Partner_B sont deux serveurs partenaires, avec initialement la base de données principale sur Partner_A comme serveur principal et la base de données miroir sur Partner_B comme serveur miroir. Si Partner_A se retrouve hors connexion, la base de données sur Partner_B peut basculer pour devenir la base de données principale en cours. Lorsque Partner_A rejoint la session de mise en miroir, il devient le serveur miroir et sa base de données devient la base de données miroir.

D'autres configurations de mise en miroir de bases de données offrent des niveaux différents de performances et de sécurité des données, et prennent en charge diverses formes de basculement. Pour plus d’informations, consultez La mise en miroir de bases de données (SQL Server).

Il est possible d’utiliser un alias lors de la spécification du nom de la base de données miroir.

Remarque

Pour plus d’informations sur les tentatives de connexion initiales et les tentatives de reconnexion vers une base de données mise en miroir, consultez Connecter des clients à une session de mise en miroir de bases de données (SQL Server).

Considérations relatives à la programmation

Lorsque le serveur de la base de données principale échoue, l'application cliente reçoit des erreurs en réponse aux appels d'API, erreurs qui signifient que la connexion à la base de données a été perdue. Lorsque cela se produit, les modifications non validées apportées à la base de données sont perdues et la transaction actuelle est restaurée. Si cela se produit, l’application doit fermer la connexion (ou libérer l’objet source de données) et la rouvrir. La connexion est redirigée de manière transparente vers la base de données miroir, qui joue désormais le rôle de serveur principal.

Lorsqu'une connexion est établie, le serveur principal envoie au client l'identité de son partenaire de basculement à utiliser en cas de basculement. Lorsqu’une application a tenté d’établir une connexion après l’échec du serveur principal, le client ne connaît pas l’identité du partenaire de basculement. Pour permettre aux clients de faire face à ce scénario, une propriété d’initialisation et un mot clé de chaîne de connexion associé permettent au client de spécifier l’identité du partenaire de basculement par lui-même. L’attribut client est utilisé uniquement dans ce scénario ; si le serveur principal est disponible, il n’est pas utilisé. Si le serveur partenaire de basculement fourni par le client ne fait pas référence à un serveur agissant en tant que partenaire de basculement, la connexion est refusée par le serveur. Pour permettre aux applications de s’adapter aux modifications de configuration, l’identité du partenaire de basculement réel peut être déterminée en inspectant l’attribut une fois la connexion établie. Vous devez envisager de mettre en cache les informations du partenaire pour mettre à jour la chaîne de connexion ou concevoir une stratégie de nouvelle tentative en cas d’échec de la première tentative de connexion.

Remarque

Vous devez spécifier explicitement la base de données à utiliser par une connexion si vous souhaitez utiliser cette fonctionnalité dans un DSN, une chaîne de connexion ou une propriété/attribut de connexion. SQL Server Native Client ne tente pas de basculer vers la base de données partenaire si ce n’est pas le cas.

La mise en miroir est une fonctionnalité de la base de données. Les applications qui utilisent plusieurs bases de données peuvent ne pas être en mesure d’exploiter cette fonctionnalité.

En outre, les noms de serveur ne respectent pas la casse, mais les noms de base de données respectent la casse. Vous devez donc vous assurer que vous utilisez la même casse dans les chaînes de connexion et DSN.

Fournisseur OLE DB SQL Server Native Client

Le fournisseur OLE DB SQL Server Native Client prend en charge la mise en miroir de bases de données via des attributs de chaîne de connexion et de connexion. La propriété SSPROP_INIT_FAILOVERPARTNER a été ajoutée au jeu de propriétés DBPROPSET_SQLSERVERDBINIT, et le FailoverPartner mot clé est un nouvel attribut de chaîne de connexion pour DBPROP_INIT_PROVIDERSTRING. Pour plus d’informations, consultez Utilisation de mots clés de chaîne de connexion avec SQL Server Native Client.

Le cache de basculement est conservé tant que le fournisseur est chargé, c’est-à-dire jusqu’à ce que CoUninitialize soit appelé ou tant que l’application a une référence à un objet géré par le fournisseur OLE DB SQL Server Native Client, tel qu’un objet source de données.

Pour plus d’informations sur la prise en charge du fournisseur OLE DB SQL Server Native Client pour la mise en miroir de bases de données, consultez Propriétés d’initialisation et d’autorisation.

Pilote ODBC SQL Server Native Client

Le pilote ODBC SQL Server Native Client prend en charge la mise en miroir de bases de données par le biais d’attributs de chaîne de connexion et de chaîne de connexion. Plus précisément, l’attribut SQL_COPT_SS_FAILOVER_PARTNER a été ajouté pour une utilisation avec les fonctions SQLSetConnectAttr et SQLGetConnectAttr  ; et le Failover_Partner mot clé a été ajouté en tant qu’attribut de chaîne de connexion.

Le cache de basculement est conservé tant que l’application dispose d’au moins un handle d’environnement alloué. À l’inverse, il est perdu lorsque le dernier handle d’environnement est désalloué.

Remarque

Le Gestionnaire de pilotes ODBC a été amélioré pour prendre en charge la spécification du nom du serveur de basculement.

Voir aussi

Fonctionnalités de SQL Server Native Client
Connecter des clients à une session de mise en miroir de bases de données (SQL Server)
Mise en miroir de bases de données (SQL Server)