El registro de transacciones no registra las instrucciones SQL que se ejecutan, como es de esperar. En cambio, está registrando los cambios en los datos sin procesar en cada base de datos, de forma independiente.
Es posible que un proceso almacenado de una base de datos funcione por completo en el registro de transacciones de otra base de datos.
... database1..my_stored_procedure AS
BEGIN
INSERT INTO database2..table1 (col1) values (1);
^^ changes written to database2's tlog
INSERT INTO database2..table2 (col1) values (2);
^^ changes written to database2's tlog
END
^^ when this transaction is committed, COMMIT is recorded in database2's tlog
O para que haga cambios en ambos.
... database2..my_other_stored_procedure AS
BEGIN
INSERT INTO database1..table1 (col1) values (1);
^^ changes written to database1's tlog
INSERT INTO database2..table1 (col1) values (2);
^^ changes written to database2's tlog
END
^^ when this transaction is committed, COMMIT is recorded in BOTH database1's and database2's tlog
Lo que se registra en el registro de transacciones son los cambios de datos reales , no las declaraciones SQL que causaron que ocurrieran. Las entradas en cada archivo de registro de transacciones son completamente independientes, excepto en la medida en que COMMIT se escribe en los dos archivos de registro al mismo tiempo, una vez que se confirma la transacción.
La misma lógica se aplica si tiene una transacción más grande que ejecuta varios procedimientos almacenados en varias bases de datos. Una vez que COMPROMETE su transacción, el COMPROMISO se registrará en el registro de cada base de datos que participó en la transacción.
Es perfectamente posible restaurar una copia de seguridad de la base de datos2 y reproducir sus registros de transacciones en un servidor que no tiene base de datos1.
Este comportamiento permite cierta flexibilidad en cómo se presentan los procedimientos y las vistas en SQL Server. Muchos administradores de bases de datos mantienen sus procedimientos almacenados, especialmente los de mantenimiento, en una base de datos (por ejemplo Admin
) que está completamente separada de las bases de datos de aplicaciones / usuarios, y escriben los resultados de la operación de mantenimiento en esa base de datos. Afortunadamente, es posible restaurar una de las bases de datos de usuarios a un servidor de desarrollo sin necesidad de copiarlas Admin
.