Contenuto del file di registro delle transazioni in modo più dettagliato


11

Ho una domanda sul contenuto del registro delle transazioni (chiamiamolo LDF in breve). Sto assumendo un database con modello di recupero completo.

Ho letto che il file LDF contiene (registri) ogni singola operazione nel database (che è in modalità di recupero completo). In che cosa differisce dalla registrazione durante BEGIN TRAN; COMMAND(s); COMMIT? Lo sto chiedendo perché a quanto pare è possibile ripristinare le transazioni, ma non è possibile ripristinare i comandi standard (in modalità di recupero completo).

Immagino che durante la transazione i contenuti che vengono registrati nel file LDF siano diversi rispetto alla normale registrazione con recupero completo. È giusto? Come è diverso? È solo l'inclusione di operazioni "annulla" per ogni azione?

In una nota correlata, ho sentito che esistono strumenti commerciali per "ripristinare / annullare" le query standard utilizzando il file LDF di recupero completo. Come lo fanno? Analizzano i contenuti LDF e provano a creare operazioni inverse / annulla?


Risposte:


11

La differenza è che quelli che chiami "comandi standard" hanno transazioni implicite (come in "implicite non esplicite" e non reali che significano qualcosa di diverso ), quindi ogni volta che emetti un INSERTcomando senza una transazione esplicita, si aprirà una transazione, inserire i dati e impegnarsi automaticamente. Questa è chiamata transazione autocommit.

Questo è anche il motivo per cui non è possibile eseguire il rollback di questo INSERT: è già impegnato. Quindi la regola è la stessa delle transazioni esplicite: non è possibile eseguire il rollback dopo che sono state impegnate .

Puoi vedere cosa intendo direttamente da SQL Server.

Microsoft spedisce SQL Server con un DMF chiamato sys.fn_dblogche può essere utilizzato per cercare nel registro delle transazioni di un determinato database.

Per questo semplice esperimento userò il database 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

Qui sto facendo due inserti: uno con e uno senza una transazione esplicita.

Nel file di registro puoi vedere che non c'è assolutamente alcuna differenza tra i due:

Autocommit vs Transazioni esplicite

Quello rosso è INSERTall'interno di una transazione con autocommit e quello blu è INSERTcon una transazione esplicita.

Per quanto riguarda gli strumenti di terze parti citati, sì, analizzano il registro del database e generano il normale codice T-SQL per "annullare" o "ripetere" le operazioni. Normalmente intendo che non fanno nulla di speciale oltre a generare uno script che avrà l'effetto di fare esattamente l'opposto di ciò che è nel file di registro.


7

Spiegherò come funzionano gli strumenti commerciali, nell'esempio Log di ApexSQL

E sulla nota correlata ho sentito che esistono strumenti commerciali per "ripristinare / annullare" le query standard utilizzando il file LDF di recupero completo. Come lo fanno? Analizzano i contenuti LDF e provano a creare operazioni inverse / annulla?

Sì, leggono il file LDF (online o distaccato) e i file trn (backup del registro delle transazioni), trovano quale transazione è avvenuta e creano uno script che farà lo stesso o il contrario.

Si noti tuttavia che lo script di annullamento e ripetizione non deve essere esattamente lo stesso di quelli eseguiti, ma l'effetto sarà esattamente lo stesso.

Ad esempio, se lo script eseguito era:

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

Il registro delle transazioni registrerà che la riga nella tabella con i valori di colonna 9, "New Loc22", "41BC2FF6-F0FC-475F-8EB9-CEC1805AA0F6" e "2002/06/01 00: 00: 00.000" è eliminata. Dalla struttura della tabella, lo strumento leggerà che la chiave primaria è la colonna AddressType e creerà il seguente script redo:

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

Si noti che la transazione è legata alla colonna Chiave primaria, non alla colonna utilizzata nella clausola where originale. Allo stesso modo, lo script di annullamento sarà:

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')

inserisci qui la descrizione dell'immagine

Disclaimer: lavoro per ApexSQL come tecnico dell'assistenza

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.