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)
Grupos de disponibilidad AlwaysOn y la creación de reflejo de la base de datos no admiten las transacciones entre bases de datos ni las transacciones distribuidas. 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. Para la creación de reflejo de la base de datos este problema puede agravarse porque, después de una conmutación por error, la base de datos reflejada está normalmente en una instancia del servidor diferente al de la otra base de datos, e incluso si ambas bases de datos se reflejan entre los dos mismos asociados, no existe ninguna garantía de que ambas bases de datos se conmutarán 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.