Transacciones entre bases de datos no compatibles para la creación de reflejo de la base de datos o grupos de disponibilidad de AlwaysOn (SQL Server)
Las transacciones entre bases de datos y las transacciones distribuidas no son compatibles con Always On grupos de disponibilidad ni mediante la creación de reflejo de la base de datos. Esto se debe a que la integridad o la atomicidad de las transacciones no se puede garantizar por las siguientes razones:
Para las transacciones entre bases de datos: cada base de datos se confirma independientemente. Por consiguiente, incluso para las bases de datos de un solo grupo de disponibilidad, podría producirse una conmutación por error después de que una base de datos confirme una transacción, pero antes de que lo haga la otra. En el caso de la creación de reflejo de la base de datos, este problema se ha compuesto porque después de una conmutación por error, la base de datos reflejada suele estar en una instancia de servidor diferente de la otra base de datos e incluso si ambas bases de datos están reflejadas entre los mismos dos asociados, no hay ninguna garantía de que ambas bases de datos conmuten por error al mismo tiempo.
Para las transacciones distribuidas: después de una conmutación por error, el nuevo servidor principal o la nueva réplica principal no puede conectarse al coordinador de transacciones distribuidas en el servidor principal o la réplica principal anterior. Por lo tanto, el nuevo servidor principal o la nueva réplica principal no puede obtener el estado de la transacción.
En el siguiente ejemplo de creación de reflejo de la base de datos se muestra cómo podría producirse una incoherencia lógica. En este ejemplo, una aplicación utiliza una transacción entre bases de datos para insertar dos filas de datos: una fila se inserta en una tabla de una base de datos reflejada, A, y la otra fila se inserta en una tabla de otra base de datos, B. La base de datos A se está reflejando en modo de alta seguridad con conmutación automática por error. Mientras la transacción se confirma, la base de datos A deja de estar disponible y la sesión de creación de reflejo se conmuta por error automáticamente al reflejo de la base de datos A.
Después de la conmutación por error, la transacción entre bases de datos podría confirmarse correctamente en la base de datos B, pero no en la base de datos conmutada por error. Esto se produciría si el servidor principal original de la base de datos A no hubiese enviado el registro de transacciones entre bases de datos al servidor reflejado antes del error. Después de la conmutación por error, esa transacción no existiría en el nuevo servidor principal. Las bases de datos A y B se volverían incoherentes porque los datos insertados en la base de datos B se mantienen intactos, pero los datos insertados en la base de datos A se pierden.
Su puede producir un escenario similar cuando se usa una transacción de MS DTC. Por ejemplo, después de la conmutación por error, el nuevo servidor principal contacta con MS DTC. Sin embargo, MS DTC.no tiene conocimiento del nuevo servidor principal y termina las transacciones que están "preparadas para confirmar" y que otras bases de datos consideran confirmadas.
Importante
El uso de creación de reflejo de la base de datos o de grupos de disponibilidad junto con DTC no da como resultado una instalación no admitida de SQL Server. Sin embargo, si una base de datos forma parte de una sesión de creación de reflejo de la base de datos o de un grupo de disponibilidad y también se usa DTC en la base de datos, Microsoft solo investigará los problemas de compatibilidad si no están relacionados con el uso combinado de creación de reflejo de la base de datos o de grupos de disponibilidad con DTC.