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 plutôt Groupes de disponibilité AlwaysOn.
La mise en miroir de bases de données, introduite dans SQL Server 2005, est une solution permettant d'accroître la disponibilité de la base de données et la redondance des données. SQL Server Native Client fournissant le support implicite pour la mise en miroir de bases de données, le développeur n'a pas besoin d'écrire de code ou 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 base de données par base de données, conserve une copie de la 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 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 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 faire de sa base de données la base de données principale via 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.
[!REMARQUE]
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.
[!REMARQUE]
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, SQL Server Native Client 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.
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 les attributs de connexion et de chaîne de connexion. La propriété SSPROP_INIT_FAILOVERPARTNER a été ajoutée à la propriété DBPROPSET_SQLSERVERDBINIT définie et le mot clé FailoverPartner est un nouvel attribut de chaîne de connexion de 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é, autrement dit jusqu'à ce que CoUninitialize soit appelé, ou tant que l'application détient une référence à un objet géré par le fournisseur OLE DB SQL Server Native Client (objet source de données, par exemple).
Pour plus d'informations sur la prise en charge par le fournisseur OLE DB SQL Server Native Client de 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 DB SQL Server Native Client prend en charge la mise en miroir de bases de données via les attributs de connexion et de chaîne de connexion. Plus précisément, l'attribut SQL_COPT_SS_FAILOVER_PARTNER a été ajouté pour être utilisé avec les fonctions SQLSetConnectAttr et SQLGetConnectAttr; et le mot clé Failover_Partner a été ajouté comme nouvel attribut de chaîne de connexion.
Le cache de basculement est conservé tant que l'application possède au moins un handle d'environnement alloué. En revanche, il est perdu lorsque le dernier handle d'environnement est libéré.
[!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
Concepts
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)