Hvad er en transaktionslog?
Der er et krav i relationelle databasesystemer, at transaktioner skal være holdbare. Dette er "D" i ACID-egenskaberne for transaktioner. Systemet skal sikre, at hvis der sker et pludseligt nedbrud, kan transaktionen afspilles igen. SQL Server opfylder dette krav ved at fange alle transaktioner i en fysisk fil kaldet en transaktionslogfil .
I det væsentlige, hver gang en transaktion er begået, registrerer SQL Server ændringer produceret af den pågældende transaktion i en transaktionslog. Selvom transaktionen ikke er blevet fastholdt i datafilen, er den tilgængelig i transaktionsloggen og kan afspilles igen i tilfælde af et pludseligt nedbrud.
Gendannelsesmodeller og transaktionslogfiler
SQL Server fungerer under tre gendannelsesmodeller – Fuld, Bulk Logged og Simple.
Under fuld gendannelsestilstand logges ALLE transaktioner. Databasen kan således gendannes fuldt ud, hvis der sker et nedbrud. Dette betyder også, at databasens backup kan gendannes til et bestemt tidspunkt, hvis transaktionen eller den relaterede backup er tilgængelig. Under Fuld og Bulk-Logged Recovery-tilstande afkortes transaktionslogfiler, når der udføres en logbackup.
I Simple Recovery-tilstanden bliver ALLE transaktioner stadig logget. Imidlertid afkortes transaktionslogoperationen, hver gang databasen udfører kontrolpunktet.
Et kontrolpunkt sker, når SQL Server skriver beskidte buffere til datafilen. Beskidte buffere er essentielle sider, der er gemt i hukommelsen, som er blevet ændret af transaktioner, såsom at tilstanden i hukommelsen ikke matcher tilstanden på disken. Det vil vi dog ikke diskutere her. I Simple Recovery-tilstand fanger SQL Server alle disse ændringer i transaktionsloggen for at beholde dem, indtil de fortsætter.
Transaktionslogstrukturen
Transaktionsloggen er en fysisk fil, der er synlig på OS-laget på serveren, hvor SQL Server-databasen er hostet. Hver database har en transaktionslog, men det er muligt at konfigurere flere. Sagen er, at det at have flere transaktions-SQL-logfiler ikke giver nogen ydeevnefordele. SQL Server skriver til transaktionsloggen sekventielt – én fil skal være fuld, før den næste fil tages i brug. Dog kan flere filer, der sidder på separate diske, redde dagen, hvis den første fil bliver fuld.
Internt er transaktionslogfilen en række virtuelle logfiler. Størrelsen og antallet af disse filer påvirker den tid, det tager at sikkerhedskopiere databasen eller bringe den online. Det er altid en god idé at tilpasse transaktionsloggen korrekt og sikre, at indstillingerne for automatisk vækst passer til det forventede aktivitetsniveau. Så vil filvæksterne ikke ske for ofte.
Hvad får loggen til at vokse?
Lad os starte med at oprette en lille database ved hjælp af koden i Listing 1. Datafilen er 4MB stor, logfilen er 2MB til at starte med. Dine produktionsdatabaser ville aldrig være af denne størrelse, især med den populære praksis med forudallokering . Vi valgte sådanne størrelser udelukkende til demonstrationsformå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 database opretter vi en enkelt tabel til de yderligere datamanipulationssprog (DML)-sætninger (liste 2).
-- Listing 2: Create a Table
use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)
Ved at udføre koden i liste 3 kontrollerer og verificerer vi, hvad 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');
Vær opmærksom på Filstørrelsen kolonne. Vi fortsætter med at påkalde væksten i transaktionsloggen ved at køre INSERTs og DELETEs 100.000 gange (liste 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
Liste 4 indsætter en enkelt række i txn_log tabel og sletter den samme række og gentager denne handling 100.000 gange.
Samlet set vokser tabellen ikke på grund af denne aktivitet, men transaktionsloggen vokser markant. Når vi gentager forespørgslen i liste 3 efter at have kørt DML-sætningen fra liste 4, ser vi, hvor meget transaktionsloggen er vokset:
Transaktionsloggen voksede fra 4MB til 40MB på grund af denne aktivitet, selvom datafilen ikke blev ændret i størrelse. Dette viser os tydeligt, at transaktionslogstørrelsen ikke har meget at gøre med datastørrelsen. Indvirkningen på størrelsen kommer fra den aktivitet (DML), der sker på databasen.
Hvordan administrerer vi transaktionslogfiler?
Databaseadministratorer, der administrerer lokale forekomster af SQL Server af IaaS-installationer, bør sikkerhedskopiere og sikkerhedskopiere transaktionslogfilerne regelmæssigt. Det er nyttigt at have disaster recovery-konfigurationer såsom Log Shipping eller AlwaysOn AG . Sådanne konfigurationer laver sikkerhedskopierne automatisk.
I fuld gendannelsestilstand vil en SQL Server-logbackup afkorte de transaktionslogdele, der ikke længere er nødvendige for gendannelse. Logafkortningen sletter inaktive virtuelle logfiler. På denne måde rydder det plads i transaktionslogfiler til genbrug.
Koden i liste 6 viser størrelsen på transaktionsloggen og hvor meget ledig plads 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 også krympe den fysiske transaktionslog ved at bruge koden i liste 7. Før du krymper, skal du sørge for at have en backup af transaktionsloggen. I produktionen er det bedst at planlægge log-sikkerhedskopierne for at undgå ukontrolleret fysisk logfilvækst og sikre, at dataene bevares. Med muligheden for gendannelse efter katastrofe som Log Shipping eller AlwaysOn AG konfigureret, er dette allerede givet.
Vi kan forespørge på log_reuse_wait_desc kolonne på sys.databases katalogvisning for at bestemme eventuelle forhold, der forhindrer transaktionsloggen i at blive krympet. Bemærk, at vi forespurgte denne kolonne i liste 3.
Sådanne forhold kan være et afventende kontrolpunkt, en afventende log backup, løbende backup eller gendannelse, en aktiv langvarig transaktion og lignende aktiviteter i databasen.
-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO
Vi bruger koden i liste 8 til at sikkerhedskopiere databasen. I vores særlige tilfælde skal vi først lave en fuld backup, fordi log backups altid refererer til en fuld backup. Den "sidste" fulde backup starter kæden, når det drejer sig om retableringen på tidspunktet.
-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';
Når du kører en database i Simple Recovery-tilstand, afkortes transaktionsloggen ved hvert checkpoint . I denne tilstand er log backup ikke mulig.
Placeringen af transaktionslogfilen skal have den rigtige størrelse for at imødekomme de langvarige transaktioner, der sker lejlighedsvis. Ellers kan transaktionsloggen stadig fylde diskpladsen op. Figur 4 viser, hvad der sker med loggen internt, når der tages en backup. Bemærk, at den fysiske fil stadig er 40 MB, men vi har nu omkring 37 MB ledig plads.
Hvad sker der i simpel gendannelsestilstand?
Lad os nu indstille tranlogeksperimentet database til Simple Recovery-tilstand.
-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;
Når vi udfører koden præsenteret tidligere i liste 4, får vi en lidt anderledes adfærd.
Figur 6 viser væksten i transaktionsloggen i Simple Recovery-tilstand, når vi udfører koden i Listing 4. Størrelsen af den fysiske logfil er kun 15 MB. Det er halvt mindre, end det var under Full Recovery Model tidligere. Bemærk også den ledige plads på 11,5 MB.
Betyder det, at der var mindre trævækst?
Nej. Figur 7 viser, at mens sessionen var i gang, udførte vores SQL Server også flere checkpoints. Dette afkortede loggen og gav plads til, at transaktioner kunne genoptage voksende log med intervaller.
Konklusion
Transaktionsloggen er en utrolig vigtig komponent i en SQL Server-database. Det påvirker alt, hvad der kræver eller er afhængigt af gendannelse - sikkerhedskopier, gendannelser, katastrofegendannelse og så videre. Du kan også logge db-aktivitet.
I denne artikel har vi diskuteret arten af transaktionsloggen, aspekter ved at administrere den korrekt og demonstreret adfærden af DML i databaser med fuld eller enkel gendannelsestilstand på plads. Der er dog meget mere at lære om transaktionsloggen. Indtastningerne i referencerne ville være et godt udgangspunkt for dig.
Reference s
- Transaktionslog
- SQL-serverdatabaser og -lagring
Læs også
Vigtigheden af transaktionslog i SQL Server