Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les transactions entre bases de données et les transactions distribuées ne sont pas prises en charge par les groupes de disponibilité Always On ou par la mise en miroir de bases de données. Cela est dû au fait que l’atomicité/l’intégrité des transactions ne peut pas être garantie pour les raisons suivantes :
Pour les transactions inter-bases de données : chaque base de données valide indépendamment. Par conséquent, même pour les bases de données d’un groupe de disponibilité unique, un basculement peut se produire après qu’une base de données valide une transaction, mais avant que l’autre base de données ne le fasse. Pour la mise en miroir de bases de données, ce problème est composé, car après un basculement, la base de données mise en miroir se trouve généralement sur une instance de serveur différente de l’autre base de données, et même si les deux bases de données sont mises en miroir entre les deux partenaires, il n’existe aucune garantie que les deux bases de données basculeront en même temps.
Pour les transactions distribuées : après un basculement, le nouveau serveur principal/réplica principal ne peut pas se connecter au coordinateur de transactions distribuées sur le serveur principal/réplica principal précédent. Par conséquent, le nouveau serveur principal/réplica principal ne peut pas obtenir l’état de la transaction.
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. Cela se produit si le serveur principal d’origine de la base de données A n’avait pas envoyé le journal de la transaction inter-bases de données au serveur miroir avant l’échec. 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 similaire peut se produire lors de l’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.
Important
L’utilisation de la mise en miroir de bases de données ou des groupes de disponibilité avec DTC n’entraîne pas d’installation SQL Server non supportée. Toutefois, si une base de données fait partie d’une session de mise en miroir de bases de données ou d’un groupe de disponibilité et qu’elle est également utilisée dans la base de données, les problèmes de support sont examinés par Microsoft uniquement s’ils ne sont pas liés à l’utilisation combinée de la mise en miroir de bases de données ou des groupes de disponibilité avec DTC.