Inhalt der Transaktionsprotokolldatei im Detail

Ich habe eine Frage zum Inhalt des Transaktionsprotokolls (nennen wir es kurz LDF). Ich gehe von einer Datenbank mit vollständigem Wiederherstellungsmodell aus.

Ich habe gelesen, dass die LDF-Datei jeden Vorgang in der Datenbank enthält (protokolliert) (dh im vollständigen Wiederherstellungsmodus). Wie unterscheidet es sich von der Protokollierung während BEGIN TRAN; COMMAND(s); COMMIT? Ich frage, weil Sie anscheinend Transaktionen zurücksetzen können, aber Standardbefehle nicht zurücksetzen können (im vollständigen Wiederherstellungsmodus).

Ich vermute, dass sich der Inhalt, der während der Transaktion in der LDF-Datei protokolliert wird, von der regulären vollständigen Wiederherstellungsprotokollierung unterscheidet. Ist das richtig? Wo ist der Unterschied? Ist es nur die Einbeziehung von "Rückgängig" -Operationen für jede Aktion?

In einem ähnlichen Zusammenhang habe ich gehört, dass es kommerzielle Tools gibt, mit denen Standardabfragen unter Verwendung einer LDF-Datei mit vollständiger Wiederherstellung "rückgängig gemacht / rückgängig gemacht" werden können. Wie machen Sie das? Analysieren sie den LDF-Inhalt und versuchen, inverse / rückgängig zu machen?

Der Unterschied besteht darin, dass das, was Sie "Standardbefehle" nennen, implizite Transaktionen enthält (wie bei "nicht explizit" und nicht realen impliziten Transaktionen, die etwas anderes bedeuten ). Jedes Mal, wenn Sie einen INSERTBefehl ohne explizite Transaktion ausgeben , wird eine Transaktion geöffnet. Daten einfügen und automatisch festschreiben. Dies wird als Autocommit-Transaktion bezeichnet.

Dies ist auch der Grund, warum Sie dies nicht rückgängig machen können INSERT: Es ist bereits festgeschrieben. Die Regel ist also dieselbe wie bei expliziten Transaktionen: Sie können kein Rollback durchführen, sobald sie festgeschrieben wurden .

Sie können direkt in SQL Server sehen, was ich meine.

Microsoft liefert SQL Server mit einem DMF mit dem Namen DMF aus sys.fn_dblog, mit dem das Transaktionsprotokoll einer bestimmten Datenbank durchsucht werden kann.

Für dieses einfache Experiment werde ich die AdventureWorks-Datenbank verwenden:

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

Hier mache ich zwei Einfügungen: eine mit und eine ohne explizite Transaktion.

In der Protokolldatei können Sie sehen, dass es absolut keinen Unterschied zwischen den beiden gibt:

Die rote ist die INSERTinnerhalb einer Autocommit-Transaktion und die blaue ist die INSERTmit einer expliziten Transaktion.

Die von Ihnen erwähnten Tools von Drittanbietern analysieren das Datenbankprotokoll und generieren normalen T-SQL-Code, um die Vorgänge rückgängig zu machen oder zu wiederholen. Normalerweise meine ich, dass sie nichts Besonderes tun, als ein Skript zu generieren, das genau das Gegenteil von dem bewirkt, was in der Protokolldatei enthalten ist.

Ich werde anhand des ApexSQL-Protokollbeispiels erklären, wie kommerzielle Tools funktionieren

In diesem Zusammenhang habe ich gehört, dass es kommerzielle Tools gibt, mit denen Standardabfragen mithilfe einer LDF-Datei mit vollständiger Wiederherstellung rückgängig gemacht / rückgängig gemacht werden können. Wie machen Sie das? Analysieren sie den LDF-Inhalt und versuchen, inverse / rückgängig zu machen?

Ja, sie lesen die LDF-Dateien (online oder getrennt) und die trn-Dateien (Transaktionsprotokollsicherungen), finden heraus, welche Transaktion stattgefunden hat, und erstellen ein Skript, das das Gleiche oder das Gegenteil bewirkt.

Beachten Sie jedoch, dass das Rückgängig- und das Wiederherstellungsskript nicht genau mit den ausgeführten Skripten übereinstimmen müssen, der Effekt jedoch genau gleich ist.

Zum Beispiel, wenn das ausgeführte Skript war:

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

Das Transaktionsprotokoll zeichnet auf, dass die Zeile in der Tabelle mit den Spaltenwerten 9, 'New Loc22', '41BC2FF6-F0FC-475F-8EB9-CEC1805AA0F6' und '2002/06/01 00: 00: 00.000' gelöscht wird. In der Tabellenstruktur liest das Tool, dass der Primärschlüssel die Spalte AddressType ist, und erstellt das folgende Wiederherstellungsskript:

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

Beachten Sie, dass die Transaktion an die Primärschlüsselspalte gebunden ist, nicht an die Spalte, die in der ursprünglichen where-Klausel verwendet wird. In ähnlicher Weise lautet das Rückgängig-Skript:

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

Haftungsausschluss: Ich arbeite für ApexSQL als Support Engineer