Mise en miroir de bases de données et transactions entre bases de données

La mise en miroir de base de données n'est pas prise en charge par les transactions entre bases de données ou les transactions distribuées. En effet, l'atomicité/intégrité des transactions ne peut pas être garantie pour les raisons suivantes :

• Transactions de bases de données croisées : après un basculement, la base de données miroir réside sur une autre instance de serveur et dans une base séparée de la base de données qui n'a pas été mise en miroir. Même si les bases de données sont en miroir entre les deux partenaires identiques, il n'y a aucune garantie que les deux bases de données basculent simultanément.

• Transactions distribuées : après un basculement, le nouveau serveur principal ne peut pas se connecter au coordinateur de transaction distribuée du serveur principal précédent qui utilise le même ID de ressource. Par conséquent, le nouveau serveur principal ne peut pas obtenir le statut de la transaction.

L'exemple 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 serveur 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.