Was ist ein Transaktionsprotokoll?
In relationalen Datenbanksystemen besteht die Anforderung, dass Transaktionen dauerhaft sein müssen. Dies ist „D“ in den ACID-Eigenschaften von Transaktionen. Das System muss sicherstellen, dass bei einem plötzlichen Absturz die Transaktion wiederholt werden kann. SQL Server erfüllt diese Anforderung, indem alle Transaktionen in einer physischen Datei namens Transaktionsprotokolldatei erfasst werden .
Im Wesentlichen zeichnet SQL Server jedes Mal, wenn eine Transaktion festgeschrieben wird, Änderungen auf, die von dieser Transaktion in einem Transaktionsprotokoll erzeugt wurden. Selbst wenn die Transaktion nicht in der Datendatei gespeichert wurde, ist sie im Transaktionsprotokoll verfügbar und kann im Falle eines plötzlichen Absturzes wiederholt werden.
Wiederherstellungsmodelle und Transaktionsprotokolle
SQL Server arbeitet mit drei Wiederherstellungsmodellen – Vollständig, Massenprotokolliert und Einfach.
Im vollständigen Wiederherstellungsmodus werden ALLE Transaktionen protokolliert. Somit kann die Datenbank im Falle eines Absturzes vollständig wiederhergestellt werden. Dies bedeutet auch, dass die Datenbanksicherung zu einem bestimmten Zeitpunkt wiederhergestellt werden kann, wenn die Transaktion oder die zugehörige Sicherung verfügbar ist. Im vollständigen und massenprotokollierten Wiederherstellungsmodus werden Transaktionsprotokolle immer dann abgeschnitten, wenn eine Protokollsicherung ausgeführt wird.
Im einfachen Wiederherstellungsmodus werden weiterhin ALLE Transaktionen protokolliert. Die Transaktionsprotokolloperation wird jedoch jedes Mal abgeschnitten, wenn die Datenbank den Prüfpunkt ausführt.
Ein Prüfpunkt findet statt, wenn SQL Server Dirty Buffers in die Datendatei schreibt. Schmutzige Puffer sind wichtige Seiten, die im Speicher gespeichert sind und durch Transaktionen geändert wurden, z. B. wenn der Zustand im Speicher nicht mit dem Zustand auf der Festplatte übereinstimmt. Wir werden dies hier jedoch nicht diskutieren. Im einfachen Wiederherstellungsmodus erfasst SQL Server all diese Änderungen im Transaktionsprotokoll, um sie beizubehalten, bis sie beibehalten werden.
Die Struktur des Transaktionsprotokolls
Das Transaktionsprotokoll ist eine physische Datei, die auf der Betriebssystemebene des Servers sichtbar ist, auf dem die SQL Server-Datenbank gehostet wird. Jede Datenbank hat ein Transaktionsprotokoll, aber es ist möglich, mehr zu konfigurieren. Die Sache ist die, dass das Vorhandensein mehrerer SQL-Transaktionsprotokolle keine Leistungsvorteile bringt. SQL Server schreibt sequentiell in das Transaktionsprotokoll – eine Datei muss voll sein, bevor die nächste Datei verwendet wird. Allerdings können mehrere Dateien auf separaten Datenträgern den Tag retten, wenn die erste Datei voll wird.
Intern ist die Transaktionsprotokolldatei eine Reihe virtueller Protokolldateien. Die Größe und Anzahl dieser Dateien wirkt sich auf die Zeit aus, die zum Sichern der Datenbank oder zum Onlineschalten benötigt wird. Es ist immer eine gute Idee, das Transaktionsprotokoll richtig zu dimensionieren und sicherzustellen, dass die Einstellungen für die automatische Vergrößerung dem erwarteten Aktivitätsniveau entsprechen. Dann wird das Dateiwachstum nicht allzu oft vorkommen.
Was lässt das Protokoll wachsen?
Beginnen wir mit dem Erstellen einer kleinen Datenbank mit dem Code in Listing 1. Die Datendatei ist 4 MB groß, die Protokolldatei ist zunächst 2 MB groß. Ihre Produktionsdatenbanken würden niemals diese Größe erreichen, insbesondere mit der beliebten Praxis der Vorabzuweisung . Wir haben solche Größen lediglich zu Demonstrationszwecken gewählt.
-- Listing 1: Create a Small Database
create database tranlogexperiment
on primary
( name = N'tranlogexperiment', filename = N'C:\MSSQL\Data\tranlogexperiment.mdf', size = 4MB , FILEGROWTH = 1024KB )
log on
( name = N'Test1_log', filename = N'E:\MSSQL\Log\Test1_log.ldf' , size = 2MB , FILEGROWTH = 1024KB );
go
In dieser Datenbank erstellen wir eine einzelne Tabelle für die weiteren DML-Anweisungen (Data Manipulation Language) (Listing 2).
-- Listing 2: Create a Table
use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)
Indem wir den Code in Listing 3 ausführen, überprüfen und verifizieren wir, was wir getan haben.
-- Listing 3: Check Recovery Model and File Sizes
select name, recovery_model_desc, log_reuse_wait_desc from sys.databases where name='tranlogexperiment';
select DB_NAME(database_id) [Database Name]
, type_desc [Database Name]
, name [Logical file Name]
, physical_name [Physical file Name]
, size*8/1024 [File Size (MB)]
, growth*8/1024 [File Growth (MB)]
from sys.master_files where database_id=DB_ID('tranlogexperiment');
Achten Sie auf die Dateigröße Säule. Wir fahren fort, das Wachstum des Transaktionsprotokolls aufzurufen, indem wir INSERTs und DELETEs 100.000 Mal ausführen (Listing 4).
-- Listing 4: Create a Small Table
use tranlogexperiment
go
insert into txn_log values (1, 'Kenneth','Igiri', 'NG');
delete from txn_log where ID=1;
go 100000
Listing 4 fügt eine einzelne Zeile in das txn_log ein Tabelle und löscht dieselbe Zeile, wobei diese Aktion 100.000 Mal wiederholt wird.
Insgesamt wächst die Tabelle durch diese Aktivität nicht, aber das Transaktionsprotokoll wächst erheblich. Wenn wir die Abfrage in Listing 3 wiederholen, nachdem wir die DML-Anweisung aus Listing 4 ausgeführt haben, sehen wir, wie stark das Transaktionsprotokoll gewachsen ist:
Das Transaktionsprotokoll wuchs aufgrund dieser Aktivität von 4 MB auf 40 MB, obwohl die Größe der Datendatei nicht geändert wurde. Dies zeigt uns deutlich, dass die Größe des Transaktionsprotokolls wenig mit der Datengröße zu tun hat. Die Auswirkung auf die Größe ergibt sich aus der Aktivität (DML), die in der Datenbank stattfindet.
Wie verwalten wir Transaktionsprotokolle?
Datenbankadministratoren, die lokale Instanzen von SQL Server oder IaaS-Installationen verwalten, sollten die Transaktionsprotokolle regelmäßig sichern. Es ist hilfreich, über Notfallwiederherstellungskonfigurationen wie Protokollversand oder AlwaysOn AG zu verfügen . Solche Konfigurationen führen die Backups automatisch durch.
Im vollständigen Wiederherstellungsmodus kürzt eine SQL Server-Protokollsicherung die Transaktionsprotokollteile, die nicht mehr für die Wiederherstellung benötigt werden. Die Protokollkürzung löscht inaktive virtuelle Protokolldateien. Auf diese Weise wird Platz in Transaktionsprotokollen zur Wiederverwendung freigegeben.
Der Code in Listing 6 zeigt die Größe des Transaktionslogs und wie viel freien Speicherplatz wir darin haben.
-- Listing 6: Change Recovery Model
USE [tranlogexperiment]
GO
SELECT DB_NAME() AS [Database Name],
name AS [Logical File Name],
type_desc,
size/128.0 AS [Current Size (MB)],
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS [Free Space (MB)]
FROM sys.database_files
WHERE type IN (0,1);
Wir können auch das physische Transaktionsprotokoll mit dem Code in Listing 7 verkleinern. Stellen Sie vor dem Verkleinern sicher, dass Sie eine Sicherungskopie des Transaktionsprotokolls haben. In der Produktion ist es am besten, die Protokollsicherungen zu planen, um ein unkontrolliertes Wachstum der physischen Protokolldateien zu vermeiden und sicherzustellen, dass die Daten erhalten bleiben. Mit der Disaster-Recovery-Option wie Log Shipping oder AlwaysOn AG konfiguriert, dies ist bereits gewährt.
Wir können log_reuse_wait_desc abfragen Spalte in der sys.databases Katalogansicht, um alle Bedingungen zu ermitteln, die verhindern, dass das Transaktionsprotokoll verkleinert wird. Beachten Sie, dass wir diese Spalte in Listing 3 abgefragt haben.
Solche Bedingungen können ein ausstehender Prüfpunkt, eine ausstehende Protokollsicherung, eine laufende Sicherung oder Wiederherstellung, eine aktive lang andauernde Transaktion und ähnliche Aktivitäten in der Datenbank sein.
-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO
Wir verwenden den Code in Listing 8, um die Datenbank zu sichern. In unserem speziellen Fall müssen wir zuerst eine vollständige Sicherung durchführen, da Log-Sicherungen immer auf eine vollständige Sicherung verweisen. Die „letzte“ vollständige Sicherung beginnt die Kette, wenn es um die Point-in-Time-Wiederherstellung geht.
-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';
Beim Ausführen einer Datenbank im einfachen Wiederherstellungsmodus wird das Transaktionsprotokoll an jedem Prüfpunkt abgeschnitten . Log-Backups sind in diesem Modus nicht möglich.
Der Speicherort der Transaktionsprotokolldatei sollte die richtige Größe haben, um die lang andauernden Transaktionen aufzunehmen, die gelegentlich auftreten. Andernfalls kann das Transaktionsprotokoll immer noch den Speicherplatz füllen. Abbildung 4 zeigt, was intern mit dem Protokoll passiert, wenn eine Sicherung erstellt wird. Beachten Sie, dass die physische Datei immer noch 40 MB groß ist, aber wir haben jetzt etwa 37 MB freien Speicherplatz.
Was passiert im einfachen Wiederherstellungsmodus?
Lassen Sie uns nun das Tranlogexperiment einstellen Datenbank in den einfachen Wiederherstellungsmodus.
-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;
Wenn wir den zuvor in Listing 4 vorgestellten Code ausführen, erhalten wir ein etwas anderes Verhalten.
Abbildung 6 zeigt das Wachstum des Transaktionsprotokolls im einfachen Wiederherstellungsmodus, wenn wir den Code in Listing 4 ausführen. Die Größe der physischen Protokolldatei beträgt nur 15 MB. Es ist die Hälfte weniger als zuvor unter dem vollständigen Wiederherstellungsmodell. Beachten Sie auch den freien Speicherplatz von 11,5 MB.
Bedeutet dies, dass es weniger Log-Wachstum gab?
Nein. Abbildung 7 zeigt, dass unser SQL Server während der Ausführung der Sitzung auch mehrere Checkpoints durchgeführt hat. Dadurch wurde das Protokoll abgeschnitten und es wurde Platz für Transaktionen geschaffen, um das wachsende Protokoll in Intervallen fortzusetzen.
Schlussfolgerung
Das Transaktionsprotokoll ist eine unglaublich wichtige Komponente einer SQL Server-Datenbank. Es wirkt sich auf alles aus, was eine Wiederherstellung erfordert oder darauf angewiesen ist – Sicherungen, Wiederherstellungen, Notfallwiederherstellung und so weiter. Sie können auch DB-Aktivitäten protokollieren.
In diesem Artikel haben wir die Art des Transaktionsprotokolls und Aspekte seiner ordnungsgemäßen Verwaltung erörtert und das Verhalten von DML in Datenbanken mit vollständigen oder einfachen Wiederherstellungsmodi demonstriert. Es gibt jedoch noch viel mehr über das Transaktionsprotokoll zu erfahren. Die Einträge in den Referenzen wären ein guter Ausgangspunkt für Sie.
Referenz s
- Transaktionsprotokoll
- SQL Server-Datenbanken und -Speicherung
Lesen Sie auch
Bedeutung des Transaktionsprotokolls in SQL Server
