Utilisation de la mise en miroir de bases de données
S'applique à : 
SQL Server
Remarque
Cette fonctionnalité sera supprimée dans une version future de 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 Groupes de disponibilité Always On à la place.
La mise en miroir de bases de données, introduite dans SQL Server 2005 (9.x), est une solution permettant d'accroître la disponibilité de la base de données et la redondance des données. OLE DB Driver pour SQL Server assurant une prise en charge implicite pour la mise en miroir de bases de données, le développeur n’a pas besoin d’écrire de code ni de prendre une autre mesure une fois la mise en miroir configurée 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 automatique prend en charge le basculement rapide sans perte de transactions validées et un serveur de secours semi-automatique prend en charge le service forcé (avec 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, si possible, sur des ordinateurs différents.
L’instance de serveur de production, appelée serveur principal, communique avec l’instance de serveur de secours, appelée serveur miroir. Le serveur principal et le serveur miroir se comportent comme des partenaires au sein de la session de mise en miroir de bases de données. En cas d’échec du serveur principal, le serveur miroir peut créer sa base de données dans la base de données principale grâce à 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 Mise en miroir de bases de données (SQL Server).
Il est possible d'utiliser un alias lors de la spécification du nom d'une base de données miroir.
Notes
Pour plus d'informations sur les tentatives de connexion initiale et de reconnexion à 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).
Éléments de programmation à prendre en considération
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, toutes les modifications apportées à la base de données qui n'ont pas été validées sont perdues et la transaction en cours est annulé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 façon transparente vers la base de données miroir, qui fait désormais office 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. Si une application a essayé d'établir une connexion après un échec du serveur principal, le client ne connaît pas l'identité du partenaire de basculement. Afin que les clients puissent 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. L'attribut client est utilisé uniquement dans ce scénario ; si le serveur principal est disponible, il n'est pas utilisé. Si le partenaire de basculement fourni par le client ne fait pas référence à un serveur agissant comme 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 peut être déterminée en examinant l'attribut après que la connexion a été établie. Si possible, mettez en cache les informations sur le serveur partenaire pour mettre à jour la chaîne de connexion ou imaginer une stratégie de nouvelle tentative au cas où la première tentative d'établissement de la connexion échouerait.
Notes
Vous devez spécifier explicitement la base de données utilisée par une connexion si vous souhaitez recourir à cette fonctionnalité dans un DSN, une chaîne de connexion ou une propriété (ou un attribut) de connexion. Si vous ne le faites pas, OLE DB Driver pour SQL Server ne tente pas de basculer sur la base de données du serveur partenaire.
La mise en miroir est une fonctionnalité de la base de données. Il se peut que les applications qui utilisent plusieurs bases de données ne puissent pas exploiter cette fonctionnalité.
De plus, les noms de serveur ne respectent pas la casse, contrairement aux noms de base de données. Par conséquent, vous devez vous assurer que vous utilisez la même casse dans les DSN et les chaînes de connexion.
OLE DB Driver pour SQL Server
OLE DB Driver pour SQL Server prend en charge la mise en miroir de bases de données via les attributs de connexion et de chaîne de connexion. La propriété SSPROP_INIT_FAILOVERPARTNER a été ajoutée au jeu de propriétés DBPROPSET_SQLSERVERDBINIT et le mot clé FailoverPartner est un nouvel attribut de chaîne de connexion de DBPROP_INIT_PROVIDERSTRING. Pour plus d’informations, voir Utilisation de mots clés de chaîne de connexion avec OLE DB Driver pour SQL Server.
Le cache de basculement est conservé tant que le fournisseur est chargé, autrement dit jusqu’à ce que CoUninitialize soit appelé, ou tant que l’application détient une référence à un objet géré par OLE DB Driver pour SQL Server (objet source de données, par exemple).
Pour plus d’informations sur la prise en charge d’OLE DB Driver pour SQL Server en vue de la mise en miroir de bases de données, consultez Propriétés d'initialisation et d'autorisation.
Voir aussi
Fonctionnalités OLE DB Driver pour SQL Server
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)