sql >> Database >  >> RDS >> Sqlserver

Basisprincipes van SQL Server-transactielogboek

Wat is een transactielogboek?

Er is een vereiste in relationele databasesystemen dat transacties duurzaam moeten zijn. Dit is "D" in de ACID-eigenschappen van transacties. Het systeem moet ervoor zorgen dat bij een plotselinge crash de transactie opnieuw kan worden afgespeeld. SQL Server voldoet aan deze vereiste door alle transacties vast te leggen in een fysiek bestand dat een transactielogbestand wordt genoemd .

In wezen registreert SQL Server elke keer dat een transactie wordt doorgevoerd de wijzigingen die door die transactie worden geproduceerd in een transactielogboek. Zelfs als de transactie niet in het gegevensbestand is bewaard, is deze beschikbaar in het transactielogboek en kan deze opnieuw worden afgespeeld in het geval van een plotselinge crash.

Herstelmodellen en transactielogboeken

SQL Server werkt onder drie herstelmodellen:Full, Bulk Logged en Simple.

In de modus Volledig herstel worden ALLE transacties vastgelegd. Zo kan de database volledig worden hersteld als er een crash optreedt. Dit betekent ook dat de databaseback-up kan worden hersteld naar een specifiek tijdstip als de transactie of de bijbehorende back-up beschikbaar is. In de modi Full en Bulk-Logged Recovery worden transactielogboeken afgekapt wanneer er een logback-up wordt uitgevoerd.

In de Simple Recovery-modus worden ALLE transacties nog steeds geregistreerd. De transactielogbewerking wordt echter afgebroken telkens wanneer de database het controlepunt uitvoert.

Een controlepunt vindt plaats wanneer SQL Server vuile buffers naar het gegevensbestand schrijft. Vuile buffers zijn essentiële pagina's die in het geheugen zijn opgeslagen en die door transacties zijn gewijzigd, bijvoorbeeld omdat de status in het geheugen niet overeenkomt met de status op de schijf. We zullen dit hier echter niet bespreken. In de Simple Recovery-modus legt SQL Server al deze wijzigingen vast in het transactielogboek om ze te bewaren totdat ze blijven bestaan.

De transactielogboekstructuur

Het transactielogboek is een fysiek bestand dat zichtbaar is op de besturingssysteemlaag van de server waarop de SQL Server-database wordt gehost. Elke database heeft één transactielogboek, maar het is mogelijk om er meer te configureren. Het punt is dat het hebben van meerdere SQL-logboeken voor transacties geen prestatievoordelen met zich meebrengt. SQL Server schrijft achtereenvolgens naar het transactielogboek - één bestand moet vol zijn voordat het volgende bestand in gebruik wordt genomen. Meerdere bestanden op aparte schijven kunnen echter de dag redden als het eerste bestand vol raakt.

Intern is het transactielogbestand een reeks virtuele logbestanden. De grootte en het aantal van die bestanden hebben invloed op de tijd die nodig is om een ​​back-up van de database te maken of deze online te zetten. Het is altijd een goed idee om het transactielogboek de juiste grootte te geven en ervoor te zorgen dat de instellingen voor automatisch groeien passen bij het verwachte activiteitsniveau. Dan zal de bestandsgroei niet al te vaak gebeuren.

Wat doet het logboek groeien?

Laten we beginnen met het maken van een kleine database met behulp van de code in Listing 1. Het gegevensbestand is 4 MB groot, het logbestand is om te beginnen 2 MB. Uw productiedatabases zouden nooit zo groot zijn, zeker niet met de populaire praktijk van pre-allocatie . We hebben dergelijke maten alleen voor demonstratiedoeleinden gekozen.

-- 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 die database maken we een enkele tabel voor de verdere DML-instructies (Data Manipulation Language) (Lijst 2).

-- Listing 2: Create a Table

use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)

Door de code in Listing 3 uit te voeren, controleren en verifiëren we wat we hebben gedaan.

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

Let op de Bestandsgrootte kolom. We gaan verder met het aanroepen van de transactielogboekgroei door INSERTs en DELETEs 100.000 keer uit te voeren (Lijst 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 voegt een enkele rij toe aan de txn_log tabel en verwijdert dezelfde rij, waarbij deze actie 100.000 keer wordt herhaald.

Over het algemeen groeit de tabel niet vanwege deze activiteit, maar het transactielogboek groeit aanzienlijk. Wanneer we de query in Listing 3 herhalen na het uitvoeren van de DML-instructie van Listing 4, zien we hoeveel het transactielogboek is gegroeid:

Het transactielogboek groeide door deze activiteit van 4 MB naar 40 MB, hoewel het gegevensbestand niet in grootte werd gewijzigd. Dit laat ons duidelijk zien dat de transactieloggrootte weinig te maken heeft met de datagrootte. De impact op de grootte is van de activiteit (DML) die plaatsvindt in de database.

Hoe beheren we transactielogboeken?

Databasebeheerders die on-premises exemplaren van SQL Server of IaaS-installaties beheren, moeten regelmatig back-ups maken van de transactielogboeken. Het is handig om de noodherstelconfiguraties te hebben, zoals Log Shipping of AlwaysOn AG . Dergelijke configuraties doen de back-ups automatisch.

In de modus Volledig herstel zal een back-up van het SQL Server-logboek de gedeelten van het transactielogboek afkappen die niet langer nodig zijn voor herstel. De logafbreking verwijdert inactieve virtuele logbestanden. Op deze manier maakt het ruimte vrij in transactielogboeken voor hergebruik.

De code in Listing 6 toont de grootte van het transactielogboek en hoeveel vrije ruimte we erin hebben.

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

We kunnen het fysieke transactielogboek ook verkleinen met behulp van de code in Listing 7. Zorg ervoor dat u een back-up van het transactielogboek hebt voordat u gaat verkleinen. In productie is het het beste om de logboekback-ups te plannen om ongecontroleerde fysieke groei van logboekbestanden te voorkomen en ervoor te zorgen dat de gegevens behouden blijven. Met de noodhersteloptie zoals Log Shipping of AlwaysOn AG geconfigureerd, is dit al toegestaan.

We kunnen de log_reuse_wait_desc . opvragen kolom op de sys.databases catalogusweergave om eventuele voorwaarden te bepalen die voorkomen dat het transactielogboek wordt verkleind. Merk op dat we deze kolom in Listing 3 hebben opgevraagd.

Dergelijke voorwaarden kunnen een wachtend checkpoint, een in behandeling zijnde logback-up, een doorlopende back-up of herstel, een actieve langlopende transactie en soortgelijke activiteiten in de database zijn.

-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO

We gebruiken de code in Listing 8 om een ​​back-up van de database te maken. In ons specifieke geval moeten we eerst een volledige back-up maken, omdat logback-ups altijd verwijzen naar een volledige back-up. De "laatste" volledige back-up start de keten bij het afhandelen van het herstel op een bepaald tijdstip.

-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';

Wanneer een database wordt uitgevoerd in de modus Eenvoudig herstel, wordt het transactielogboek bij elk controlepunt afgekapt . In deze modus zijn logback-ups niet mogelijk.

De locatie van het transactielogboekbestand moet de juiste grootte hebben om rekening te houden met de langlopende transacties die af en toe plaatsvinden. Anders kan het transactielogboek nog steeds de schijfruimte opvullen. Afbeelding 4 laat zien wat er intern met het logboek gebeurt als er een back-up wordt gemaakt. Merk op dat het fysieke bestand nog steeds 40 MB is, maar we hebben nu ongeveer 37 MB vrije ruimte.

Wat gebeurt er in de eenvoudige herstelmodus?

Laten we nu het tranlogexperiment instellen database naar de modus Simple Recovery.

-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;

Wanneer we de code uitvoeren die eerder in Lijst 4 is gepresenteerd, krijgen we iets ander gedrag.

Afbeelding 6 toont de groei van het transactielogboek in de modus Eenvoudig herstel wanneer we de code in Listing 4 uitvoeren. De grootte van het fysieke logbestand is slechts 15 MB. Het is de helft minder dan het was onder het Full Recovery Model eerder. Let ook op de vrije ruimte van 11,5 MB.

Betekent dit dat er minder loggroei was?

Nee. Figuur 7 laat zien dat terwijl de sessie in uitvoering was, onze SQL Server ook verschillende checkpoints uitvoerde. Dit verkortte het logboek en gaf ruimte voor transacties om met tussenpozen het groeiende logboek te hervatten.

Conclusie

Het transactielogboek is een ongelooflijk belangrijk onderdeel van een SQL Server-database. Het heeft invloed op alles wat herstel vereist of afhankelijk is:back-ups, herstel, herstel na noodgevallen, enzovoort. U kunt ook db-activiteit loggen.

In dit artikel hebben we de aard van het transactielogboek besproken, aspecten van correct beheer ervan, en het gedrag van DML gedemonstreerd in databases met volledige of eenvoudige herstelmodi. Er is echter nog veel meer te leren over het transactielogboek. De vermeldingen in de referenties zouden een goed startpunt voor u zijn.

Referentie s

  1. Transactielogboek
  2. SQL Server-databases en opslag

Lees ook

Belang van transactielogboek in SQL Server


  1. In plaats van trigger in SQL Server verliest SCOPE_IDENTITY?

  2. SELECT-query met CASE-voorwaarde en SUM()

  3. Oracle Entity Framework - Genereer entiteit uit tabellen in verschillende schema's

  4. Hoe @@MAX_CONNECTIONS werkt in SQL Server