Transactions entre bases de données non prises en charge pour la mise en miroir de bases de données ou les groupes de disponibilité AlwaysOn (SQL Server)
Les transactions entre bases de données et les transactions distribuées ne sont pas prises en charge par Groupes de disponibilité AlwaysOn et par la mise en miroir de bases de données. En effet, l'atomicité/intégrité des transactions ne peut pas être garantie pour les raisons suivantes :
Pour les transactions entre bases de données : chaque base de données est validée indépendamment. Par conséquent, même pour les bases de données dans un seul groupe de disponibilité, un basculement peut se produire après qu'une base de données a validé 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 aggravé car après un basculement, la base de données mise en miroir figure 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 mêmes deux partenaires, il n'y a aucune garantie que les deux bases de données basculent au même moment.
Pour les transactions distribuées : après un basculement, le nouveau principal/réplica principal ne peut pas se connecter au coordinateur de transaction distribuée sur le principal/réplica principal. Par conséquent, le nouveau 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 pourrait se produire si le serveur principal d'origine de la base de données A n'avait pas envoyé le journal pour la transaction entre bases de données 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 présenter 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.