Établissement de la connexion initiale à une session de mise en miroir de bases de données

Nouveau : 14 avril 2006

Pour établir la connexion initiale avec une base de données mise en miroir, un client doit fournir une chaîne de connexion contenant au minimum le nom d'une instance de serveur. Ce nom de serveur obligatoire doit identifier l'instance du serveur principal actuel et est appelé nom du partenaire initial.

Éventuellement, la chaîne de connexion peut également fournir le nom d'une autre instance de serveur, qui doit alors identifier l'instance du serveur miroir actuel, à utiliser si le partenaire initial n'est pas disponible lors de la première tentative de connexion. Ce deuxième nom est appelé nom du partenaire de basculement.

La chaîne de connexion doit également contenir un nom de base de données. Cette information est requise pour permettre au fournisseur d'accès aux données d'effectuer des tentatives de basculement.

À la réception d'une chaîne de connexion, le fournisseur d'accès aux données stocke le nom du partenaire initial et, le cas échéant, le nom du partenaire de basculement dans un cache de la mémoire volatile du client (pour le code managé, le cache se limite au domaine d'application). Une fois mis en cache, le nom du partenaire initial n'est jamais mis à jour par le fournisseur d'accès aux données. Lorsque le client fournit le nom du partenaire de basculement, le fournisseur d'accès aux données stocke aussi ce nom temporairement pour pouvoir se connecter s'il ne peut pas le faire en utilisant le nom du partenaire initial.

Une session de mise en miroir de bases de données ne fournit aucune protection contre les problèmes d'accès au serveur qui sont spécifiques aux clients, comme lorsqu'un ordinateur client n'arrive pas à communiquer avec le réseau. Une tentative de connexion à une base de données mise en miroir peut également échouer pour diverses raisons qui n'ont aucun rapport avec le fournisseur d'accès aux données ; par exemple, une tentative de connexion peut échouer parce que l'instance du serveur principal est inactive, comme c'est le cas pendant le basculement de la base de données, ou à cause d'une erreur réseau.

Lorsque le fournisseur d'accès aux données tente de se connecter, il commence par utiliser le nom du partenaire initial. En règle générale, si l'instance de serveur spécifiée est disponible et qu'il s'agit bien de l'instance du serveur principal actuel, la tentative de connexion aboutit.

Remarque :
Si la session de mise en miroir est suspendue, le client se connecte généralement au serveur principal et télécharge le nom du partenaire. Cependant, le client ne peut pas accéder à la base de données tant que la mise en miroir n'a pas redémarré.

Si cette tentative échoue, le fournisseur d'accès aux données essaie de se connecter à l'aide du nom du partenaire de basculement (s'il est disponible). Si l'un des noms de partenaire identifie correctement le serveur principal actuel, le fournisseur d'accès aux données réussit généralement à ouvrir la connexion initiale. Une fois cette connexion établie, le fournisseur d'accès aux données télécharge le nom d'instance de serveur du serveur miroir actuel. Ce nom est stocké dans le cache en tant que nom du partenaire de basculement et remplace, le cas échéant, le nom du partenaire de basculement fourni par le client. Par la suite, le fournisseur de données .NET Framework pour SQL Server ne met pas à jour le nom du partenaire de basculement. En revanche, SQL Native Client met le cache à jour à chaque fois qu'une connexion ou réinitialisation de connexion ultérieure retourne un nom de partenaire différent.

La figure suivante représente une connexion cliente au partenaire initial, Partner_A, pour une base de données en miroir appelée Db_1. Cette figure illustre le cas où le nom du partenaire initial fourni par le client identifie correctement le serveur principal actuel, Partner_A. La tentative de connexion initiale aboutit et le fournisseur d'accès aux données stocke le nom du serveur miroir (actuellement Partner_B) en tant que nom du partenaire de basculement dans le cache local. Pour terminer, le client se connecte à la copie principale de la base de données Db_1.

La tentative de connexion initiale peut échouer, entre autres, à cause d'une erreur réseau ou d'une instance de serveur inactive. Étant donné que le partenaire initial est alors indisponible, pour que le fournisseur d'accès aux données puisse essayer de se connecter au partenaire de basculement, le client doit avoir fourni le nom de ce dernier dans la chaîne de connexion.

Si ce n'est pas le cas et que le nom du partenaire de basculement n'est pas disponible, la tentative de connexion initiale se poursuit jusqu'à l'expiration de la connexion réseau ou jusqu'à ce qu'une erreur soit retournée (exactement comme pour une base de données qui n'est pas mise en miroir).

Lorsque le nom du partenaire de basculement est fourni dans la chaîne de connexion, le comportement du fournisseur d'accès aux données dépend du protocole réseau et du système d'exploitation du client, comme indiqué ci-après :

• Pour TCP/IP, si le client exécute Microsoft Windows XP ou version ultérieure, les tentatives de connexion sont régies par un algorithme de tentative de connexion qui est spécifique à la mise en miroir de bases de données. L'algorithme de tentative de connexion détermine la durée maximale (la durée d'essai) allouée à l'ouverture d'une connexion pendant une tentative de connexion donnée. Pour plus d'informations, consultez Algorithme de délai entre deux tentatives de connexion (pour les connexions TCP/IP).
• Pour les autres protocoles réseau et pour les clients n'exécutant pas Microsoft Windows XP ou version ultérieure
  Si une erreur se produit ou si le partenaire initial est indisponible, la tentative de connexion initiale attend l'expiration du délai d'attente de la connexion réseau ou du délai d'attente de la connexion du fournisseur d'accès aux données. En général, ce délai est de l'ordre de 20 à 30 secondes. Ensuite, si la connexion du fournisseur d'accès aux données n'a pas expiré, le fournisseur tente de se connecter au partenaire de basculement. Si le délai d'attente de la connexion expire avant l'établissement de la connexion ou si le partenaire de basculement est indisponible, la tentative de connexion échoue. Par contre, si le partenaire de basculement est disponible avant l'expiration du délai d'attente de la connexion et qu'il s'agit désormais du serveur principal, la tentative de connexion aboutit généralement.

Chaînes de connexion pour une base de données en miroir

La chaîne de connexion fournie par le client contient des informations que le fournisseur d'accès aux données utilise pour se connecter à la base de données. Cette section présente les mots clés qui sont tout particulièrement appropriés pour se connecter à une base de données en miroir à l'aide d'une connexion au pilote ODBC de SQL Native Client. Pour plus d'informations sur l'ensemble des mots clés de chaînes de connexion, consultez Using Connection String Keywords with SQL Native Client.

Attribut Network

La chaîne de connexion doit contenir l'attribut Network pour spécifier le protocole réseau. Cela permet d'assurer la persistance du protocole réseau spécifié entre les connexions avec différents partenaires. TCP/IP est le meilleur protocole pour se connecter à une base de données mise en miroir. Pour garantir que le client exige TCP/IP à chaque fois qu'il se connecte aux partenaires, la chaîne de connexion doit fournir l'attribut suivant :

Network=dbmssocn; 

Important :
Nous vous recommandons de laisser TCP/IP en haut de la liste de protocoles d'un client. Toutefois, si la chaîne de connexion spécifie l'attribut Network, l'ordre de cette liste est ignoré.

Sinon, pour garantir que le client exige des canaux nommés à chaque fois qu'il se connecte aux partenaires, la chaîne de connexion doit fournir l'attribut suivant :

Network=dbnmpntw; 

Important :
Étant donné que le protocole des canaux nommés n'utilise pas l'algorithme de tentative de connexion TCP/IP, une tentative de connexion utilisant des canaux nommés risque, dans de nombreux cas, d'expirer avant de se connecter à une base de données mise en miroir.

Attribut Server

La chaîne de connexion doit contenir un attribut Server indiquant le nom du partenaire initial, lequel doit identifier l'instance du serveur principal actuel.

La façon la plus simple d'identifier l'instance de serveur consiste à spécifier son nom : <server_name>[\<SQL_Server_instance_name>]. Par exemple :

Server=Partner_A;

ou

Server=Partner_A\Instance_2;

Cependant, lorsque le nom système est utilisé, le client doit effectuer une recherche DNS pour obtenir l'adresse IP du serveur et une requête SQL Server Browser pour obtenir le numéro de port du serveur sur lequel le partenaire réside. Ces recherches et requêtes peuvent être évitées en spécifiant l'adresse IP et le numéro de port du partenaire dans l'attribut Server, au lieu de spécifier le nom du serveur. Cette méthode est recommandée afin de minimiser la possibilité de délais externes pendant la connexion à ce partenaire.

Remarque :
Il est nécessaire d'effectuer une requête SQL Server Browser si la chaîne de connexion spécifie le nom de l'instance nommée et pas le port.

Pour spécifier l'adresse IP et le numéro de port, l'attribut Server doit se présenter sous la forme suivante : Server=<ip_address>,<port>. Par exemple :

Server=123.34.45.56,4724; 

Remarque :
L'adresse IP peut être une adresse IPv4 (IP version 4) ou IPv6 (IP version 6).

Attribut Database

En outre, la chaîne de connexion doit spécifier l'attribut Database pour fournir le nom de la base de données mise en miroir. Si la base de données est indisponible lors de la tentative de connexion du client, une exception est générée.

Par exemple, pour se connecter explicitement à la base de données AdventureWorks sur le serveur principal Partner_A, un client doit utiliser la chaîne de connexion suivante :

" Server=Partner_A; Database=AdventureWorks "

Remarque :
Cette chaîne omet les informations d'authentification. Pour plus d'informations sur les mots clés à utiliser pour l'authentification intégrée, consultez Using Connection String Keywords with SQL Native Client.

Important :

L'intégration du préfixe du protocole avec l'attribut Server (Server=tcp:<servername>) est incompatible avec l'attribut Network et si vous spécifiez le protocole dans les deux endroits, vous allez probablement obtenir une erreur. Par conséquent, il est recommandé qu'une chaîne de connexion spécifie le protocole à l'aide de l'attribut Network et spécifie uniquement le nom du serveur dans l'attribut Server ("Network=dbmssocn; Server=<servername>").

Attribut Failover Partner

Outre le nom du partenaire initial, le client peut aussi spécifier le nom du partenaire de basculement, lequel doit identifier l'instance du serveur miroir actuel. Le partenaire de basculement est spécifié par l'attribut Failover Partner. La façon la plus simple d'identifier l'instance de serveur consiste à spécifier son nom système : <server_name>[\<SQL_Server_instance_name>].

Sinon, l'adresse IP et le numéro de port peuvent être fournis dans l'attribut Failover Partner. Si la tentative de connexion initiale échoue au cours de la première connexion à la base de données, la tentative de connexion au partenaire de basculement ne sera pas tributaire de DNS et de SQL Server Browser. Une fois qu'une connexion est établie, le nom du partenaire de basculement sera remplacé par le nom du partenaire de basculement, si bien qu'en cas de basculement, les connexions redirigées feront appel à DNS et à SQL Server Browser.

Remarque :
Lorsque seul le nom du partenaire initial est fourni, les développeurs d'applications n'ont rien à faire, ni aucun code à écrire, mis à part le code relatif à la reconnexion.

Remarque :

Les développeurs d'applications en code managé fournissent le nom du partenaire de basculement dans la propriété ConnectionString de l'objet SqlConnection. Pour plus d'informations sur l'utilisation de cette chaîne de connexion, consultez « Database Mirroring Support in the .NET Framework Data Provider for SQL Server » (en anglais) dans la documentation ADO.NET qui fait partie du kit de développement logiciel (SDK) Microsoft .NET Framework.

Exemple de chaîne de connexion

Par exemple, pour se connecter explicitement à l'aide de TCP/IP à la base de données AdventureWorks sur Partner_A ou sur Partner_B, une application cliente peut fournir la chaîne de connexion suivante :

"Server=Partner_A; Failover Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"

Sinon, le client peut utiliser l'adresse IP et le numéro de port pour identifier le partenaire initial, Partner_A ; par exemple, si l'adresse IP est 250.65.43.21 et le numéro de port est 4734, la chaîne de connexion est la suivante :

"Server=250.65.43.21,4734; Failover Partner=Partner_B; Database=AdventureWorks; Network=dbmssocn"

Voir aussi

Concepts

Protocoles réseau et points de terminaison TDS
Présentation de la mise en miroir de bases de données
Défaillances possibles pendant la mise en miroir d'une base de données

Autres ressources

Connexion au moteur de base de données SQL Server
Using Connection String Keywords with SQL Native Client
Utilisation de SQL Server Browser

Aide et Informations

Assistance sur SQL Server 2005