Grunderna i SQL Server Transaction Log

Vad är en transaktionslogg?

Det finns ett krav i relationsdatabassystem att transaktioner ska vara varaktiga. Detta är "D" i ACID-egenskaperna för transaktioner. Systemet måste säkerställa att om en plötslig krasch inträffar kan transaktionen spelas upp igen. SQL Server uppfyller detta krav genom att fånga alla transaktioner i en fysisk fil som kallas en transaktionsloggfil .

I huvudsak, varje gång en transaktion genomförs, registrerar SQL Server ändringar som produceras av den transaktionen i en transaktionslogg. Även om transaktionen inte har bevarats i datafilen är den tillgänglig i transaktionsloggen och kan spelas upp igen vid en plötslig krasch.

Återställningsmodeller och transaktionsloggar

SQL Server fungerar under tre återställningsmodeller – Fullständig, Bulk Logged och Simple.

I Full återställningsläge loggas ALLA transaktioner. Således kan databasen återställas helt om en krasch inträffar. Detta innebär också att databassäkerhetskopian kan återställas till en viss tidpunkt om transaktionen eller den relaterade säkerhetskopian är tillgänglig. Under lägena för fullständig och bulkloggad återställning trunkeras transaktionsloggar närhelst en loggsäkerhetskopiering utförs.

I läget Enkel återställning loggas fortfarande ALLA transaktioner. Transaktionsloggoperationen trunkeras dock varje gång databasen kör kontrollpunkten.

En kontrollpunkt inträffar när SQL Server skriver smutsiga buffertar till datafilen. Smutsiga buffertar är viktiga sidor lagrade i minnet som har ändrats av transaktioner, som att tillståndet i minnet inte matchar tillståndet på disken. Vi kommer dock inte att diskutera detta här. I läget för enkel återställning fångar SQL Server alla dessa ändringar i transaktionsloggen för att behålla dem tills de kvarstår.

Transaktionsloggstrukturen

Transaktionsloggen är en fysisk fil som är synlig på OS-lagret på servern där SQL Server-databasen är värd. Varje databas har en transaktionslogg, men det är möjligt att konfigurera fler. Saken är att det inte medför några prestandafördelar att ha flera SQL-transaktionsloggar. SQL Server skriver till transaktionsloggen sekventiellt – en fil måste vara full innan nästa fil tas i bruk. Däremot kan flera filer som sitter på separata diskar rädda dagen om den första filen blir full.

Internt är transaktionsloggfilen en serie virtuella loggfiler. Storleken och antalet av dessa filer påverkar den tid det tar att säkerhetskopiera databasen eller föra den online. Det är alltid en bra idé att dimensionera transaktionsloggen korrekt och se till att inställningarna för automatisk tillväxt passar den förväntade aktivitetsnivån. Då kommer filtillväxten inte att ske för ofta.

Vad får loggen att växa?

Låt oss börja med att skapa en liten databas med koden i Listing 1. Datafilen är 4MB stor, loggfilen är 2MB till att börja med. Dina produktionsdatabaser skulle aldrig få den här storleken, särskilt med den populära metoden förtilldelning . Vi valde sådana storlekar endast för demonstrationsändamål.

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

I den databasen skapar vi en enda tabell för ytterligare datamanipulationsspråk (DML)-satser (lista 2).

-- Listing 2: Create a Table

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

Genom att köra koden i Lista 3 kontrollerar och verifierar vi vad vi har gjort.

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

Var uppmärksam på Filstorleken kolumn. Vi fortsätter att anropa tillväxten i transaktionsloggen genom att köra INSERT och DELETE 100 000 gånger (lista 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

Lista 4 infogar en enda rad i txn_log tabell och tar bort samma rad och upprepar denna åtgärd 100 000 gånger.

Sammantaget växer inte tabellen på grund av denna aktivitet, men transaktionsloggen växer avsevärt. När vi upprepar frågan i Lista 3 efter att ha kört DML-satsen från Lista 4, ser vi hur mycket transaktionsloggen har växt:

Transaktionsloggen växte från 4MB till 40MB på grund av denna aktivitet även om datafilen inte ändrades i storlek. Detta visar oss tydligt att transaktionsloggens storlek inte har mycket att göra med datastorleken. Inverkan på storleken beror på aktiviteten (DML) som sker i databasen.

Hur hanterar vi transaktionsloggar?

Databasadministratörer som hanterar lokala instanser av SQL Server av IaaS-installationer bör säkerhetskopiera och säkerhetskopiera transaktionsloggarna regelbundet. Det är bra att ha katastrofåterställningskonfigurationer som Log Shipping eller AlwaysOn AG . Sådana konfigurationer gör säkerhetskopieringarna automatiskt.

I fullständigt återställningsläge kommer en SQL Server-loggsäkerhetskopiering att trunkera de transaktionsloggdelar som inte längre behövs för återställning. Loggavkortningen tar bort inaktiva virtuella loggfiler. På så sätt rensar det utrymme i transaktionsloggar för återanvändning.

Koden i Lista 6 visar storleken på transaktionsloggen och hur mycket ledigt utrymme vi har i den.

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

Vi kan också krympa den fysiska transaktionsloggen med koden i Lista 7. Innan du krymper, se till att ha en säkerhetskopia av transaktionsloggen. I produktionen är det bäst att schemalägga loggsäkerhetskopiorna för att undvika okontrollerad fysisk tillväxt av loggfiler och säkerställa att data bevaras. Med katastrofåterställningsalternativet som Log Shipping eller AlwaysOn AG konfigurerat, detta är redan beviljat.

Vi kan fråga log_reuse_wait_desc kolumnen i sys.databases katalogvy för att fastställa eventuella villkor som hindrar transaktionsloggen från att krympas. Lägg märke till att vi frågade efter den här kolumnen i lista 3.

Sådana förhållanden kan vara en pågående kontrollpunkt, en väntande loggsäkerhetskopiering, pågående säkerhetskopiering eller återställning, en aktiv långvarig transaktion och liknande aktiviteter i databasen.

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

Vi använder koden i Listing 8 för att säkerhetskopiera databasen. I vårt specifika fall måste vi först göra en fullständig säkerhetskopia eftersom loggsäkerhetskopior alltid refererar till en fullständig säkerhetskopia. Den "sista" fullständiga säkerhetskopian startar kedjan när man hanterar återställningen vid tidpunkten.

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

När du kör en databas i Simple Recovery-läge, trunkeras transaktionsloggen vid varje kontrollpunkt . I detta läge är loggsäkerhetskopior inte möjliga.

Placeringen av transaktionsloggfilen bör ha rätt storlek för att rymma de långvariga transaktioner som händer ibland. Annars kan transaktionsloggen fortfarande fylla upp diskutrymmet. Figur 4 visar vad som händer med loggen internt när en säkerhetskopia tas. Observera att den fysiska filen fortfarande är 40 MB, men vi har nu cirka 37 MB ledigt utrymme.

Vad händer i enkelt återställningsläge?

Låt oss nu ställa in tranlogexperimentet databas till enkelt återställningsläge.

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

När vi exekverar koden som presenterades tidigare i Lista 4 får vi något annorlunda beteende.

Figur 6 visar transaktionsloggens tillväxt i Simple Recovery-läge när vi exekverar koden i Listing 4. Storleken på den fysiska loggfilen är bara 15 MB. Det är hälften mindre än det var under Full Recovery Model tidigare. Lägg också märke till det lediga utrymmet på 11,5 MB.

Betyder det att det var mindre stocktillväxt?

Nej. Figur 7 visar att medan sessionen kördes utförde vår SQL Server också flera kontrollpunkter. Detta trunkerade loggen och gav utrymme för transaktioner att återuppta växande logg med intervaller.

Slutsats

Transaktionsloggen är en otroligt viktig komponent i en SQL Server-databas. Det påverkar allt som kräver eller förlitar sig på återställning – säkerhetskopiering, återställning, katastrofåterställning och så vidare. Du kan också logga db-aktivitet.

I den här artikeln har vi diskuterat transaktionsloggens karaktär, aspekter av att hantera den på rätt sätt och visat beteendet hos DML i databaser med Full eller Simple Recovery-lägen på plats. Det finns dock mycket mer att lära sig om transaktionsloggen. Posterna i referenserna skulle vara en bra utgångspunkt för dig.

Referens s

1. Transaktionslogg
2. SQL-serverdatabaser och lagring

Läs också

Betydelsen av transaktionslogg i SQL Server