Transactions - Groupes de disponibilité Always On et mise en miroir de bases de données

S'applique à : SQL Server

Cet article décrit la prise en charge des transactions entre bases de données et distribuées pour des groupes de disponibilité Always On et la mise en miroir de bases de données.

Prise en charge des transactions distribuées

SQL Server 2017 prend en charge les transactions distribuées pour les bases de données des groupes de disponibilité. Cette prise en charge comprend les bases de données sur la même instance de SQL Server ou les bases de données sur différentes instances de SQL Server. Les transactions distribuées ne sont pas prises en charge pour les bases de données configurées pour la mise en miroir de bases de données.

Pour configurer un groupe de disponibilité pour les transactions distribuées, consultez Configurer de groupe de disponibilité pour les transactions distribuées.

Pour plus d’informations, consultez :

• Guide d’Administration de DTC
• Guide du développeur de DTC
• Informations de référence pour les programmeurs de DTC

SQL Server 2016 SP1 et versions antérieures : Prise en charge des transactions entre bases de données dans la même instance de SQL Server

Dans SQL Server 2016 SP1 et versions antérieures, les transactions entre bases de données dans la même instance de SQL Server ne sont pas prises en charge pour les groupes de disponibilité. Une même instance de SQL Server ne peut pas héberger deux bases de données d’une transaction entre bases de données si l’une ou les deux bases de données sont dans un groupe de disponibilité. Cette limitation s’applique aussi quand ces bases de données font partie du même groupe de disponibilité.

En outre, les transactions de bases de données croisées ne sont non plus prises en charge pour la mise en miroir de bases de données.

SQL Server 2016 SP1 et versions antérieures : Prise en charge des transactions distribuées

Les transactions distribuées sont prises en charge avec les groupes de disponibilité quand les bases de données sont hébergées par différentes instances de SQL Server. Cela s’applique aussi aux transactions distribuées entre des instances de SQL Server et un autre serveur compatible DTC.

MSDTC (Microsoft Distributed Transaction Coordinator ou DTC) est un service Windows qui fournit une infrastructure de transaction pour les systèmes distribués. MSDTC permet aux applications clientes d’intégrer plusieurs sources de données dans une transaction, laquelle est ensuite validée sur tous les serveurs inclus dans la transaction. Par exemple, vous pouvez utiliser MSDTC pour coordonner des transactions qui s’étendent sur plusieurs bases de données sur des serveurs différents.

SQL Server 2016 introduit la possibilité d’utiliser des transactions distribuées dans lesquelles une ou plusieurs bases de données de la transaction sont dans un groupe de disponibilité. Avant SQL Server 2016, les transactions distribuées n’étaient pas prises en charge pour les bases de données dans les groupes de disponibilité. SQL Server 2016 peut inscrire un gestionnaire de ressources par base de données. Cette nouvelle fonctionnalité permet aux transactions distribuées d’inclure des bases de données dans les groupes de disponibilité.

Les conditions suivantes doivent être remplies :

• Les groupes de disponibilité doivent s’exécuter sur Windows Server 2012 R2 ou version supérieure. Pour Windows Server 2012 R2, vous devez installer la mise à jour KB3090973 disponible à l’adresse https://support.microsoft.com/kb/3090973.

• Availability groups must be created with the CREATE AVAILABILITY GROUP et la clause WITH DTC_SUPPORT = PER_DB . Actuellement, vous ne pouvez pas modifier un groupe de disponibilité.

• Toutes les instances de SQL Server qui participent au groupe de disponibilité doivent avoir la version SQL Server 2016 ou ultérieure.

Absence de prise en charge des transactions distribuées

Les cas spécifiques où les transactions distribuées ne sont pas prises en charge sont notamment les suivants :

• Dans SQL Server 2016 SP1 et versions antérieures, quand plusieurs bases de données impliquées dans la transaction sont dans le même groupe de disponibilité.

• Dans SQL Server 2016 SP1 et versions antérieures, quand au moins une base de données est dans un groupe de disponibilité et qu’une autre se trouve sur la même instance de SQL Server.

• Le groupe de disponibilité n’a pas été créé avec l’activation de la transaction distribuée.

• Mise en miroir de bases de données.

Exemple de scénario de mise en miroir de bases de données

L'exemple de mise en miroir de bases de données suivant illustre la manière dont une incohérence logique pourrait se produire. Dans cet exemple, une application utilise une transaction entre bases de données pour insérer deux lignes de données : une ligne est insérée dans une table dans une base de données mise en miroir, A, et l'autre ligne est insérée dans une table dans une autre base de données, B. La base de données A est mise en miroir en mode haute sécurité avec basculement automatique. Pendant la validation de la transaction, la base de données A devient indisponible et la session de mise en miroir bascule automatiquement vers le miroir de la base de données A.

Après le basculement, il se peut que la transaction entre bases de données soit validée correctement dans la base de données B mais pas dans la base de données basculée. Par exemple, quand le serveur principal d’origine de la base de données A n’a pas envoyé le journal pour la transaction entre bases de données au serveur miroir avant le basculement. Après le basculement, cette transaction n'existerait pas sur le nouveau serveur principal. Les bases de données A et B deviendraient incohérentes car les données insérées dans la base de donnes B demeureraient intactes, alors que celles insérées dans la base de données A auraient été perdues.

Un scénario semblable peut se produire en cas d’utilisation d'une transaction MS DTC. Par exemple, après un basculement, le nouveau principal contacte MS DTC. Mais MS DTC n'a aucune connaissance du nouveau serveur principal et interrompt toute transaction en « préparation pour validation », considérée comme validée dans d'autres bases de données.

Étapes suivantes

Groupes de disponibilité Always On : interopérabilité (SQL Server)