Contenido del archivo de registro de transacciones con más detalle

Tengo una pregunta sobre el contenido del registro de transacciones (llamémoslo LDF para abreviar). Asumo una base de datos con modelo de recuperación completa.

He leído que el archivo LDF contiene (registros) todas y cada una de las operaciones en la base de datos (que está en modo de recuperación completa). ¿Cómo es diferente de iniciar sesión durante BEGIN TRAN; COMMAND(s); COMMIT? Le pregunto porque aparentemente puede revertir las transacciones, pero no puede revertir los comandos estándar (en modo de recuperación completa).

Supongo que durante la transacción, el contenido que se registra en el archivo LDF es diferente que en el registro de recuperación completa regular. ¿Está bien? ¿Cómo es diferente? ¿Es solo la inclusión de operaciones de "deshacer" para cada acción?

En una nota relacionada, he escuchado que existen herramientas comerciales para "deshacer / deshacer" consultas estándar utilizando el archivo LDF de recuperación completa. ¿Cómo lo hicieron? ¿Analizan el contenido de LDF e intentan realizar operaciones inversas / deshacer?

La diferencia es que lo que llama "comandos estándar" tienen transacciones implícitas (como en "no explícito" y no en transacciones implícitas reales que significan algo diferente ), por lo que cada vez que emita un INSERTcomando sin una transacción explícita, se abrirá una transacción, inserte los datos y confirme automáticamente. Esto se llama una transacción de confirmación automática.

Esta es también la razón por la que no puede revertir esto INSERT: ya está comprometido. Por lo tanto, la regla es la misma que las transacciones explícitas: no puede deshacer una vez que se hayan confirmado .

Puedes ver lo que quiero decir directamente desde SQL Server.

Microsoft envía SQL Server con un DMF llamado sys.fn_dblogque se puede usar para mirar dentro del registro de transacciones de una base de datos determinada.

Para este simple experimento, voy a usar la base de datos AdventureWorks:

USE AdventureWorks2008;
GO

SELECT TOP 10 *
FROM dbo.Person;
GO

INSERT INTO dbo.Person (FirstName, MiddleName, LastName, Gender, Date)
VALUES ('Never', 'Stop', 'Learning', 'M', GETDATE());
COMMIT;

BEGIN TRAN;
INSERT INTO dbo.Person (FirstName, MiddleName, LastName, Gender, Date)
VALUES ('Never', 'Stop', 'Learning', 'M', GETDATE());
COMMIT;
GO

SELECT *
FROM sys.fn_dblog(NULL, NULL);
GO

Aquí estoy haciendo dos inserciones: una con y otra sin una transacción explícita.

En el archivo de registro puede ver que no hay absolutamente ninguna diferencia entre los dos:

El rojo es INSERTdentro de una transacción de confirmación automática y el azul es INSERTcon una transacción explícita.

En cuanto a las herramientas de terceros que menciona, sí, analizan el registro de la base de datos y generan un código T-SQL normal para "deshacer" o "rehacer" las operaciones. Por normal quiero decir que no hacen nada especial aparte de generar un script que tendrá el efecto de hacer exactamente lo contrario de lo que está en el archivo de registro.

Explicaré cómo funcionan las herramientas comerciales, en el ejemplo de ApexSQL Log

Y en una nota relacionada, escuché que existen herramientas comerciales para "revertir / deshacer" consultas estándar utilizando el archivo LDF de recuperación completa. ¿Cómo lo hicieron? ¿Analizan el contenido de LDF e intentan realizar operaciones inversas / deshacer?

Sí, leen el archivo LDF (en línea o separado) y los archivos trn (copias de seguridad del registro de transacciones), encuentran qué transacción ha sucedido y crean un script que hará lo mismo o lo contrario.

Sin embargo, tenga en cuenta que la secuencia de comandos deshacer y rehacer no tiene que ser exactamente la misma que las ejecutadas, pero el efecto será exactamente el mismo.

Por ejemplo, si el script ejecutado fue:

DELETE FROM [Person].[AddressType] WHERE Name  = 'New Loc22'

El registro de transacciones registrará que la fila en la tabla con los valores de columna 9, 'New Loc22', '41BC2FF6-F0FC-475F-8EB9-CEC1805AA0F6' y '2002/06/01 00: 00: 00.000' se elimina. Desde la estructura de la tabla, la herramienta leerá que la clave primaria es la columna AddressType y creará el siguiente script de rehacer:

DELETE FROM [Person].[AddressType] WHERE [AddressTypeID] = 9

Tenga en cuenta que la transacción está vinculada a la columna Clave principal, no a la columna utilizada en la cláusula where original. Del mismo modo, el script de deshacer será:

INSERT INTO [Person].[AddressType] ([AddressTypeID], [Name], [rowguid], [ModifiedDate]) VALUES (9, N'New loc22' COLLATE SQL_Latin1_General_CP1_CI_AS, '41bc2ff6-f0fc-475f-8eb9-cec1805aa0f6', '20020601 00:00:00.000')

Descargo de responsabilidad: trabajo para ApexSQL como ingeniero de soporte