Prise en charge de la récupération d’urgence et de la haute disponibilité par OLE DB Driver pour SQL Server

S’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)Base de données SQL dans Microsoft Fabric

Télécharger le pilote OLE DB

Cet article évoque la prise en charge par OLE DB Driver pour SQL Server de Groupes de disponibilité Always On. Pour plus d’informations sur les groupes de disponibilité Always On, consultez Écouteurs de groupe de disponibilité, connectivité client et basculement d’application (SQL Server), Création et configuration des groupes de disponibilité (SQL Server), Clustering de basculement et groupes de disponibilité Always On (SQL Server) et Secondaires actifs : réplicas secondaires accessibles en lecture (Groupes de disponibilité Always On).

Vous pouvez spécifier l’écouteur d’un groupe de disponibilité donné dans la chaîne de connexion. Si une application OLE DB Driver pour SQL Server est connectée à une base de données dans un groupe de disponibilité qui bascule, la connexion d’origine est rompue et l’application doit ouvrir une nouvelle connexion pour reprendre le travail après le basculement.

Si vous ne vous connectez pas à un écouteur du groupe de disponibilité et si plusieurs adresses IP sont associées à un nom d’hôte, OLE DB Driver pour SQL Server effectue une itération séquentielle parmi toutes les adresses IP associées à l’entrée DNS. Cette opération peut prendre du temps si la première adresse IP retournée par le serveur DNS n'est liée à aucune carte d'interface réseau (NIC). Lors de la connexion à un écouteur de groupe de disponibilité, OLE DB Driver pour SQL Server tente d’établir une connexion à toutes les adresses IP en parallèle. Quand une tentative de connexion réussit, le pilote abandonne toutes les tentatives de connexion en attente.

Connexion avec MultiSubnet Failover

Spécifiez toujours MultiSubnetFailover=Oui lorsque la cible est Azure SQL Database, Azure SQL Managed Instance, SQL Database dans Microsoft Fabric, un écouteur de groupe Always On ou une instance de cluster de basculement SQL Server.

Lorsque le nom du serveur dans votre chaîne de connexion se résout à plus d’une adresse IP, MultiSubnetFailover=Yes demande à OLE DB Driver pour SQL Server d’ouvrir les connexions à toutes ces adresses en même temps et d’utiliser la première qui répond. Sans cela, le pilote essaie les adresses une par une. Une adresse qui ne répond pas bloque jusqu’à ce que le délai d’expiration TCP du système d’exploitation expire, ce qui peut épuiser le délai de connexion avant que le pilote n’atteigne une adresse qui répond. Après un basculement, l’adresse que le pilote essaie en premier peut être une adresse qui ne sert plus la base de données, donc une connexion qui réussirait contre une autre adresse échoue avec un délai d’attente à la place.

MultiSubnetFailover=Oui modifie la rapidité avec laquelle le client trouve la réplique qui sert la base de données. Cela ne change pas le temps que le serveur met à basculer.

MultiSubnetFailover=Oui est sûr sur les cibles IP uniques. Lorsque le DNS se résout à une seule adresse, le pilote effectue une seule tentative de connexion, donc le paramètre ne coûte rien quand il n’est pas nécessaire.

Pour plus d’informations sur les mots clés de chaîne de connexion, consultez Utilisation de mots clés de chaîne de connexion avec OLE DB Driver pour SQL Server.

Utilisez les instructions suivantes pour la connexion à un serveur dans un groupe de disponibilité ou dans une instance de cluster de basculement :

• Réglez la propriété de connexion MultiSubnetFailover sur Oui.

• Pour vous connecter à un groupe de disponibilité, spécifiez l'écouteur du groupe de disponibilité en tant que serveur dans votre chaîne de connexion.

• Vous ne pouvez pas utiliser MultiSubnetFailover sur un autre protocole que TCP.

• Se connecter à une instance SQL Server configurée avec plus de 64 adresses IP provoque une défaillance de connexion.

• Vous ne pouvez pas utiliser MultiSubnetFailover avec le miroir de base de données. Le pilote renvoie une erreur lorsque le serveur signale que la base de données est en miroir. Le miroir de base de données est obsolète dans toutes les versions supportées de SQL Server. Utilisez plutôt les groupes de disponibilité Always On.

• Le type d'authentification, authentification SQL Server, authentification Kerberos ou authentification Windows, n'affecte pas le comportement d'une application utilisant la propriété de connexion MultiSubnetFailover.

• Vous pouvez augmenter la valeur du temps d’attente de connexion pour gérer le temps de basculement et réduire les tentatives de réouverture de connexion applicative. La valeur par défaut est 15 secondes. Le même réglage s’appelle Timeout lorsque vous le configurez dans IDBInitialize::Initialize, et il correspond à la DBPROP_INIT_TIMEOUT propriété. Pour Azure SQL Database sans serveur avec la pause automatique activée, utilisez un délai de connexion d’au moins 60 secondes. Une base de données en pause automatique reprend lors de la première tentative de connexion, et cette tentative peut échouer avec l’erreur 40613 pendant que la base de données reprend, donc l’application doit réessayer. Pour plus d’informations, voir Mise en pause automatique et reprise automatique.

• Les transactions distribuées ne sont pas prises en charge.

Si le routage en lecture seule n’est pas effectif, la connexion à un emplacement de type réplica secondaire dans un groupe de disponibilité échoue dans les situations suivantes :

1. Si l’emplacement du réplica secondaire n’est pas configuré pour accepter des connexions.
2. Si une application utilise ApplicationIntent=ReadWrite et que l’emplacement de la réplique secondaire est configuré pour un accès en lecture seule.

Une connexion échoue si une réplique primaire est configurée pour rejeter les charges de travail en lecture seule et que la chaîne de connexion contient ApplicationIntent=ReadOnly.

Mise à niveau depuis le miroir de base de données

Une erreur de connexion survient si le chaîne de connexion contient à la fois les mots-clés MultiSubnetFailover et Failover_Partner. Une erreur survient également si vous utilisez MultiSubnetFailover et que le SQL Server renvoie une réponse du partenaire de basculement, indiquant qu'il fait partie d'une paire de miroir de base de données.

Si vous mettez à niveau une application OLE DB Driver pour SQL Server qui utilise actuellement le miroir de base de données vers un scénario multi-sous-réseaux, supprimez la propriété de connexion Failover_Partner et remplacez-la par MultiSubnetFailover réglée sur Oui. Remplacez le nom du serveur dans la chaîne de connexion par un écouteur de groupe de disponibilité. Si un chaîne de connexion utilise Failover_Partner et MultiSubnetFailover=Oui, le pilote génère une erreur. Cependant, si un chaîne de connexion utilise Failover_Partner et MultiSubnetFailover=Non (ou ApplicationIntent=ReadWrite), l’application utilise le miroir de base de données.

Le pilote renvoie une erreur si vous utilisez le miroir de base de données sur la réplique primaire du groupe de disponibilité, et si vous utilisez MultiSubnetFailover=Yes dans la chaîne de connexion qui se connecte à une réplique primaire au lieu d’un écouteur de groupe de disponibilité.

Définir MultiSubnetFailover de manière programmatique

Les propriétés de connexion équivalentes sont :

• SSPROP_INIT_MULTISUBNETFAILOVER
• DBPROP_INIT_PROVIDERSTRING

Une application OLE DB Driver pour SQL Server peut utiliser l’une des méthodes suivantes pour définir l’option MultiSubnetFailover :

• IDBInitialize::Initialize
  Utilise l’ensemble de propriétés précédemment configuré pour initialiser la source de données et créer l’objet source de données. Spécifiez MultiSubnetFailover comme propriété fournisseur ou comme partie intégrante de la chaîne de propriétés étendue.
• IDataInitialize::GetDataSource
  Prend une chaîne de connexion d’entrée qui peut contenir le mot-clé MultiSubnetFailover.
• IDBProperties::SetProperties
  Pour définir la valeur de la propriété MultiSubnetFailover , appelez IDBProperties ::SetProperties en passant la propriété SSPROP_INIT_MULTISUBNETFAILOVER avec la valeur VARIANT_TRUE ou VARIANT_FALSE, ou la propriété DBPROP_INIT_PROVIDERSTRING contenant MultiSubnetFailover=Oui ou MultiSubnetFailover=Non.

Exemple

DBPROP rgPropMultisubnet;

rgPropMultisubnet.dwPropertyID = SSPROP_INIT_MULTISUBNETFAILOVER;
rgPropMultisubnet.dwOptions = DBPROPOPTIONS_REQUIRED;
rgPropMultisubnet.dwStatus = DBPROPSTATUS_OK;
rgPropMultisubnet.colid = DB_NULLID;
V_VT(&(rgPropMultisubnet.vValue)) = VT_BOOL;
V_BOOL(&(rgPropMultisubnet.vValue)) = VARIANT_TRUE;

DBPROPSET PropSet;

PropSet.rgProperties = &rgPropMultisubnet;
PropSet.cProperties = 1;
PropSet.guidPropertySet = DBPROPSET_SQLSERVERDBINIT;
IDBProperties* pIDBProperties = NULL;
hr = pIDBInitialize->QueryInterface(IID_IDBProperties, (void **)&pIDBProperties);
pIDBProperties->SetProperties(1, &PropSet);

Spécification de l’intention d’application

Vous pouvez spécifier le mot clé ApplicationIntent dans votre chaîne de connexion. Les valeurs assignables sont ReadWrite (par défaut) ou ReadOnly.

Lorsque vous définissez ApplicationIntent=ReadOnly, le client demande une charge de travail de lecture lors de la connexion. Le serveur applique l’intention au moment de la connexion et pendant une instruction de base de données USE.

Le mot clé ApplicationIntent ne fonctionne pas avec les bases de données en lecture seule héritées.

Cibles de ReadOnly

Lorsqu’une connexion choisit ReadOnly, elle est affectée à l’une des configurations spéciales suivantes qui peuvent exister pour la base de données :

• Toujours allumé. Une base de données peut autoriser ou interdire les charges de travail en lecture sur la base de données ciblée du groupe de disponibilité. Ce choix est contrôlé à l’aide de la clause ALLOW_CONNECTIONS des instructions Transact-SQL PRIMARY_ROLE et SECONDARY_ROLE.

• Géoréplication

• Lecture du scale-out

Si aucune cible spéciale n’est disponible, la base de données normale est utilisée pour la lecture.

Le mot clé ApplicationIntent active le routage en lecture seule.

Routage en lecture seule

Le routage en lecture seule est une fonctionnalité qui permet de garantir la disponibilité d'un réplica de base de données en lecture seule. Pour activer le routage en lecture seule, tous les éléments suivants s’appliquent :

• Vous devez vous connecter à un écouteur de groupe de disponibilité Always On.

• Le mot clé de chaîne de connexion ApplicationIntent doit avoir la valeur ReadOnly.

• L’administrateur de base de données doit configurer le groupe de disponibilité pour activer le routage en lecture seule.

Plusieurs connexions utilisant le routage en lecture seule ne sont pas nécessairement toutes établies avec le même réplica en lecture seule. Les modifications apportées à la synchronisation de base de données ou à la configuration du routage du serveur peuvent entraîner des connexions clientes à différents réplicas en lecture seule.

Vous pouvez vérifier que toutes les demandes en lecture seule se connectent au même réplica en lecture seule. Pour cela, ne transmettez pas d’écouteur de groupe de disponibilité au mot clé de chaîne de connexion Server. Au lieu de cela, spécifiez le nom de l'instance en lecture seule.

Le routage en lecture seule est susceptible de prendre plus de temps que la connexion à l’instance principale. En effet, il se connecte d’abord à l’instance principale, puis recherche le meilleur secondaire accessible en lecture disponible. En raison de ces multiples étapes, passez à un délai d’expiration login d’au moins 30 secondes.

Intention de l'Application

Le pilote OLE DB Driver pour SQL Server prend en charge le mot-clé de chaîne de connexion ApplicationIntent. Pour plus d’informations sur les mots clés de chaîne de connexion, consultez Utilisation de mots clés de chaîne de connexion avec OLE DB Driver pour SQL Server.

Définir ApplicationIntent de façon programmatique

Les propriétés de connexion équivalentes sont :

• SSPROP_INIT_APPLICATIONINTENT
• DBPROP_INIT_PROVIDERSTRING

Un pilote OLE DB Driver pour SQL Server peut utiliser l’une des méthodes suivantes pour spécifier l’intention de l’application :

• IDBInitialize::Initialize
  Utilise l’ensemble de propriétés précédemment configuré pour initialiser la source de données et créer l’objet source de données. Spécifiez l'intention de l'application en tant que propriété de fournisseur ou dans le cadre de la chaîne de propriétés étendues.
• IDataInitialize::GetDataSource
  Prend une chaîne de connexion d’entrée qui peut contenir le mot-clé Application Intent.
• IDBProperties::SetProperties
  Pour définir la valeur de la propriété ApplicationIntent , appelez IDBProperties ::SetProperties en passant la propriété SSPROP_INIT_APPLICATIONINTENT avec la valeur ReadWrite ou ReadOnly, ou la propriété DBPROP_INIT_PROVIDERSTRING contenant la valeur contenant ApplicationIntent=Lecture seule ou ApplicationIntent=LectureÉcriture.

Vous pouvez spécifier l’intention d’application dans le champ Propriétés d’intention d’application de l’onglet Tous dans la boîte de dialogue Propriétés du lien de données .

Lorsque vous établissez des connexions implicites, la connexion implicite utilise le paramètre d’intention d’application de la connexion parente. De même, plusieurs sessions créées à partir d’une même source de données héritent du paramètre d’intention d’application de la source.

Contenu connexe

• Fonctionnalités OLE DB Driver pour SQL Server
• Utilisation de mots clés de chaîne de connexion avec OLE DB Driver pour SQL Server