Základy protokolu transakcí serveru SQL Server

Co je protokol transakcí?

V systémech relačních databází existuje požadavek, že transakce musí být trvalé. Toto je „D“ ve vlastnostech ACID transakcí. Systém musí zajistit, že pokud dojde k náhlému zhroucení, bude možné transakci přehrát. SQL Server splňuje tento požadavek zachycováním všech transakcí do fyzického souboru zvaného soubor protokolu transakcí .

V podstatě pokaždé, když je transakce potvrzena, SQL Server zaznamená změny vytvořené touto transakcí do protokolu transakcí. I když transakce nebyla uložena v datovém souboru, je k dispozici v transakčním protokolu a lze ji přehrát v případě náhlého selhání.

Modely obnovení a protokoly transakcí

SQL Server funguje ve třech modelech obnovy – Full, Bulk Logged a Simple.

V režimu úplné obnovy jsou protokolovány VŠECHNY transakce. Databáze tak může být plně obnovena, pokud dojde k havárii. To také znamená, že zálohu databáze lze obnovit do určitého okamžiku, pokud je transakce nebo související záloha dostupná. V režimech Úplné a Hromadně protokolované obnovy jsou protokoly transakcí zkráceny, kdykoli je provedena záloha protokolu.

V režimu Simple Recovery jsou stále protokolovány VŠECHNY transakce. Operace protokolu transakcí je však zkrácena pokaždé, když databáze provede kontrolní bod.

Kontrolní bod nastane, když SQL Server zapíše do datového souboru špinavé vyrovnávací paměti. Špinavé vyrovnávací paměti jsou důležité stránky uložené v paměti, které byly změněny transakcemi, například že stav v paměti neodpovídá stavu na disku. O tom zde však diskutovat nebudeme. V režimu Simple Recovery zaznamená SQL Server všechny tyto změny do protokolu transakcí, aby je uchoval, dokud nebudou trvalé.

Struktura protokolu transakcí

Protokol transakcí je fyzický soubor viditelný na vrstvě OS serveru, kde je hostována databáze SQL Server. Každá databáze má jeden transakční protokol, ale je možné konfigurovat více. Jde o to, že více transakčních protokolů SQL nepřináší žádné výhody z hlediska výkonu. SQL Server zapisuje do transakčního protokolu postupně – jeden soubor musí být plný, než se začne používat další soubor. Více souborů na samostatných discích však může zachránit den, pokud se první soubor zaplní.

Interně je soubor protokolu transakcí řadou virtuálních souborů protokolu. Velikost a počet těchto souborů má vliv na čas potřebný k zálohování databáze nebo jejímu uvedení do režimu online. Vždy je dobré nastavit správnou velikost protokolu transakcí a zajistit, aby nastavení automatického růstu odpovídalo očekávané úrovni aktivity. Pak k nárůstu souborů nedojde příliš často.

Co způsobuje růst protokolu?

Začněme vytvořením malé databáze pomocí kódu ve výpisu 1. Datový soubor má velikost 4 MB, soubor protokolu má pro začátek 2 MB. Vaše produkční databáze by nikdy neměly takovou velikost, zvláště s populární praxí předběžného přidělení . Tyto velikosti jsme zvolili pouze pro demonstrační účely.

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

V této databázi vytvoříme jedinou tabulku pro další příkazy jazyka pro manipulaci s daty (DML) (výpis 2).

-- Listing 2: Create a Table

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

Spuštěním kódu ve výpisu 3 zkontrolujeme a ověříme, co jsme udělali.

-- 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ěnujte pozornost Velikost souboru sloupec. Pokračujeme ve vyvolání nárůstu transakčního protokolu 100 000 spuštěními příkazů INSERT a DELETE (výpis 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

Výpis 4 vloží jeden řádek do txn_log tabulku a odstraní stejný řádek, přičemž tuto akci zopakuje 100 000krát.

Celkově se tabulka díky této činnosti nerozrůstá, ale výrazně roste transakční log. Když zopakujeme dotaz ve výpisu 3 po spuštění příkazu DML z výpisu 4, uvidíme, jak moc se rozrostl protokol transakcí:

Protokol transakcí se díky této aktivitě zvětšil ze 4 MB na 40 MB, i když se velikost datového souboru nezměnila. To nám jasně ukazuje, že velikost protokolu transakcí má jen málo společného s velikostí dat. Dopad na velikost je způsoben činností (DML) probíhající v databázi.

Jak spravujeme protokoly transakcí?

Správci databází, kteří spravují místní instance SQL Server nebo instalace IaaS, by měli pravidelně zálohovat protokoly transakcí. Je užitečné mít konfigurace obnovy po havárii, jako je Log Shipping nebo AlwaysOn AG . Takové konfigurace provádějí zálohování automaticky.

V režimu úplného obnovení záloha protokolu SQL Server zkrátí části protokolu transakcí, které již nejsou potřebné pro obnovení. Zkrácení protokolu odstraní neaktivní soubory virtuálního protokolu. Tímto způsobem se uvolní místo v protokolech transakcí pro opětovné použití.

Kód ve výpisu 6 ukazuje velikost transakčního protokolu a kolik v něm máme volného místa.

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

Můžeme také zmenšit fyzický protokol transakcí pomocí kódu ve výpisu 7. Před zmenšením se ujistěte, že máte zálohu protokolu transakcí. Ve výrobě je nejlepší naplánovat zálohování protokolů, aby se zabránilo nekontrolovanému růstu souborů fyzického protokolu a zajistilo se zachování dat. S možností obnovení po havárii, jako je Log Shipping nebo AlwaysOn AG nakonfigurováno, toto je již uděleno.

Můžeme se zeptat na log_reuse_wait_desc ve sloupci sys.databases zobrazení katalogu k určení jakýchkoli podmínek, které brání zmenšení protokolu transakcí. Všimněte si, že jsme dotazovali tento sloupec ve výpisu 3.

Takovými podmínkami mohou být nevyřízený kontrolní bod, nevyřízená záloha protokolu, probíhající zálohování nebo obnova, aktivní dlouhotrvající transakce a podobné aktivity v databázi.

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

K zálohování databáze používáme kód ve výpisu 8. V našem konkrétním případě musíme nejprve provést úplnou zálohu, protože zálohy protokolů vždy odkazují na úplnou zálohu. „Poslední“ plná záloha zahajuje řetězec při řešení obnovy v určitém okamžiku.

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

Při spuštění databáze v režimu Simple Recovery se protokol transakcí ořízne v každém kontrolním bodě . V tomto režimu není možné zálohovat protokoly.

Umístění souboru protokolu transakcí by mělo mít správnou velikost, aby vyhovovalo dlouhotrvajícím transakcím, ke kterým příležitostně dochází. Jinak může protokol transakcí stále zaplnit místo na disku. Obrázek 4 ukazuje, co se stane s protokolem interně po vytvoření zálohy. Všimněte si, že fyzický soubor má stále 40 MB, ale nyní máme asi 37 MB volného místa.

Co se stane v režimu jednoduchého obnovení?

Nyní nastavíme translogexperiment databáze do režimu Simple Recovery.

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

Když spustíme kód uvedený dříve ve výpisu 4, dostaneme trochu jiné chování.

Obrázek 6 ukazuje nárůst protokolu transakcí v režimu Simple Recovery, když spustíme kód ve výpisu 4. Velikost souboru fyzického protokolu je pouhých 15 MB. Je to o polovinu méně, než tomu bylo u modelu úplné obnovy dříve. Všimněte si také volného místa 11,5 MB.

Znamená to, že došlo k menšímu růstu log?

Ne. Obrázek 7 ukazuje, že zatímco relace probíhala, náš SQL Server také provedl několik kontrolních bodů. To zkrátilo protokol a poskytlo prostor pro transakce, aby v intervalech obnovovaly rostoucí protokol.

Závěr

Protokol transakcí je neuvěřitelně důležitou součástí databáze SQL Server. Ovlivňuje vše, co vyžaduje obnovu nebo na ní spoléhá – zálohy, obnovy, zotavení po havárii a tak dále. Můžete také zaznamenat aktivitu databáze.

V tomto článku jsme diskutovali o povaze transakčního protokolu, aspektech jeho správné správy a demonstrovali jsme chování DML v databázích s režimy úplné nebo jednoduché obnovy. O transakčním protokolu se však můžete dozvědět mnohem více. Záznamy v referencích by pro vás byly dobrým výchozím bodem.

Reference s

1. Protokol transakcí
2. Databáze a úložiště SQL Server

Přečtěte si také

Význam transakčního protokolu v SQL Server