Utilisation de la mise en miroir de bases de données dans SQL Server Native Client

  • Article

S’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

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.

Important

SQL Server Native Client (souvent abrégé en SNAC) a été supprimé dans SQL Server 2022 (16.x) et SQL Server Management Studio 19 (SSMS). SQL Server Native Client (SQLNCLI ou SQLNCLI11) et le fournisseur Microsoft OLE DB pour SQL Server (SQLOLEDB) hérité ne sont pas recommandés dans les nouveaux développements. Utilisez à la place le nouveau Microsoft OLE DB Driver (MSOLEDBSQL) pour SQL Server ou le Microsoft ODBC Driver for SQL Server le plus récent. Pour SQLNCLI qui est fourni en tant que composant du moteur de base de données SQL Server (versions 2012 à 2019), consultez cette exception du cycle de vie du support.

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. SQL Server Native Client fournit une prise en charge implicite des miroir de base 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 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. 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. 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 les miroir de base de données via des 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, consultez Utilisation de mots clés de chaîne Connecter ion 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 base de données miroir ing, 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 les miroir de base de données via des attributs 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 SQLSet Connecter Attr et SQLGet Connecter Attr ; 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 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

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)