sql >> Databáze >  >> RDS >> Sqlserver

Protokol transakcí serveru SQL – část 1

Každá databáze SQL Server obsahuje kromě datových souborů jeden nebo více souborů protokolu transakcí. Soubory protokolu zaznamenávají všechny transakce a změny databáze provedené každým z nich.

Tento článek se zaměřuje na transakční protokol a na to, jak SQL Server zaznamenává změny dat, aby je mohl použít pro obnovu po havárii databáze.

Úvod do souboru protokolu transakcí serveru SQL Server

Jak si pamatujeme, každá transakce je „vše nebo nic“. Pokud selže část transakce, selže celá transakce a stav databáze zůstane nezměněn.

SQL Server ukládá záznam o každé transakci provedené v databázi do souboru protokolu. Pokud nějaká katastrofa způsobí vypnutí serveru SQL, použije protokol transakcí k obnovení databáze do konzistentního stavu s integritou dat.

Po restartu SQL Server spustí proces zotavení z havárie. Čte soubor protokolu transakcí, aby zajistil, že všechna platná data jsou uložena v datových souborech a že nepotvrzené transakce budou vráceny zpět.

Během normálního provozu používá SQL Server také protokol transakcí. Informace obsažené v souboru jsou nezbytné k identifikaci toho, co SQL Server potřebuje udělat, když se transakce vrátí zpět kvůli chybě nebo uživatelem zadanému příkazu ROLLBACK.

Jak SQL Server používá protokol transakcí

Transakční protokol je fyzický soubor s příponou LDF . SQL Server jej automaticky vytvoří pro každou novou databázi spolu s primárním datovým souborem (.MDF ), který ukládá databázové objekty a samotná data.

Kdykoli kód T-SQL změní databázový objekt nebo data, která obsahuje, podrobnosti o změně se zaznamenají jako záznam protokolu v souboru protokolu transakcí.

Záznam protokolu obsahuje informace o konkrétní změně provedené v databázi (např. vložení jednoho řádku). Proto budeme mít řadu záznamů protokolu, které budou plně popisovat účinky jedné transakce.

Architektura protokolu transakcí

Zaznamenat pořadová čísla

Záznam protokolu má jedinečné, automaticky se zvyšující sekvenční číslo protokolu (LSN ), což nám umožňuje najít tento záznam v protokolu transakcí. LSN popisuje změnu dat a obsahuje následující informace:

  • operaci a dotčený řádek
  • staré a nové verze dat
  • transakce, která provedla úpravu

LSN se skládá ze tří čísel:

LSN =::

Každá stránka datového souboru má v záhlaví stránky LSN, které identifikuje nejnovější záznam protokolu, jehož změna se na stránce projeví. To je zásadní pro obnovu po havárii.

Když je spuštěno zotavení po havárii, porovnává LSN záznamů protokolu pro potvrzené nebo nepotvrzené transakce s LSN na stránkách datových souborů, aby se zjistilo, zda je u těchto konkrétních záznamů protokolu třeba provést nějaké opakování nebo vrácení.

Při vytváření databáze je osvědčeným postupem zadat velikost protokolu transakcí . Pokud to neuděláte, SQL Server automaticky vytvoří protokol transakcí s výchozí velikostí.

Výchozí velikost protokolu transakcí nové databáze je větší z 0,5 MB nebo 25 % z celkové velikosti všech datových souborů vytvořených ve stejném příkazu CREATE DATABASE.

Musíte být velmi opatrní, protože nové části protokolu transakcí jsou vždy nulově inicializovány . Pokud máte příkaz CREATE DATABASE bez určení velikosti souboru protokolu a vytvoříte například databázi o velikosti 1 TB, SQL Server vytvoří protokol transakcí o velikosti 250 GB.

Protože protokol musí být nulově inicializován, nevyužívá okamžitou inicializaci souboru. Tato funkce byla přidána do SQL Server 2005, aby bylo možné vytvářet nebo zvětšovat datové soubory téměř okamžitě.

Když vytvoříme DATABÁZI, můžeme vidět, co se děje – k nulové inicializaci našeho protokolu dojde pomocí příznaku trasování 3004 který vypíše zprávy o nulové inicializaci a příznak trasování 3605 což umožňuje tisk těchto zpráv protokolu pomocí příznaku trasování 3004.

Následující ukázka ukazuje, jak můžete vidět, jak probíhá nulování souboru protokolu.

1. Spusťte následující skript, abyste se ujistili, že nemáme databázi s názvem DBTest2014

USE master;
GO
 
IF DATABASEPROPERTY(N'DBTest2014', N'Version')>0
  BEGIN
    ALTER DATABASE DBTest2014 SET SINGLE_USER
      WITH ROLLBACK IMMEDIATE;
    DROP DATABASE DBTest2014;
  END
GO

2. Povolte příznaky trasování pro sledování nulové inicializace

DBCC TRACEON (3605, 3004, -1);
GO
3. Flush the error log
EXEC sp_cycle_errorlog;
GO

3. Vytvořte databázi

CREATE DATABASE DBTest2014 ON PRIMARY (
  NAME = N'DBTest2014',
  FILENAME = N'D:\DBTest2014_data.mdf')
LOG ON (
  NAME= N'DBTest2014_log',
  FILENAME= N'D:\DBTest2014_log.ldf',
  SIZE = 10MB,
  FILEGROWTH = 10 MB);
GO

4. Přečtěte si soubor protokolu chyb

EXEC sys.xp_readerrorlog;
GO

Virtuální soubory protokolu

Protokol transakcí je interně rozdělen na řadu částí nazývaných virtuální soubory protokolu (VLF ) pro zjednodušení správy.

Kdykoli je vytvořen protokol transakcí, poskytuje určitý počet VLF. Nově vytvořené VLF jsou neaktivní a nepoužívané. Aktivní VLF nelze znovu použít, dokud nebude deaktivován vymazáním protokolu.

Existuje však jedna výjimka – první VLF v nové databázi je vždy aktivní, protože každý transakční protokol musí mít alespoň jeden aktivní VLF.

Každý soubor protokolu má také stránku záhlaví souboru který zabere 8 kB na začátku souboru protokolu transakcí. Stránka záhlaví souboru ukládá metadata o souboru, jako je velikost a nastavení automatického růstu.

Počet a velikost VLF v nové části protokolu transakcí určuje SQL Server. Není možné jej nakonfigurovat.

Pokud je nově přidaná velikost:

  • <1 MB je pro diskusi irelevantní
  • <64 MB budou 4 nové VLF (každá o 1/4 velikosti růstu)
  • 64 MB až 1 GB bude 8 nových VLF (každý o 1/8 velikosti růstu)
  • > 1 GB bude 16 nových VLF (každý o 1/16 velikosti růstu)

To platí pro původně vytvořený protokol transakcí a pro každý manuální nebo automatický růst, ke kterému dojde. Když znáte vzorec potenciálního počtu VLF a jejich potenciální velikosti, pomáhá to spravovat protokol. Příliš málo nebo příliš mnoho VLF může způsobit problémy s výkonem operací protokolu transakcí.

Pořadové číslo VLF

Každý VLF má pořadové číslo, které jednoznačně identifikuje VLF v transakčním protokolu. Pořadové číslo se zvýší o jednu pokaždé, když systém správy protokolů aktivuje další VLF. Řetěz sekvenčních čísel udává aktuálně aktivní sadu VLF.

Začátek aktivní části protokolu transakcí začíná VLF, který má nejnižší pořadové číslo a je stále aktivní. Neaktivní VLF mají pořadová čísla, ale nejsou součástí aktivní části protokolu.

Aktivní část protokolu obsahuje záznamy protokolu, které SQL Server z nějakého důvodu vyžaduje.

Když poprvé vytvoříte novou databázi, pořadová čísla VLF nezačínají na 1. Začínají jakýmkoli nejvyšším pořadovým číslem VLF v protokolu transakcí modelové databáze plus 1 . Je nemožné vyčerpat pořadová čísla VLF. SQL Server má kód, který vynutí vypnutí instance, pokud se pořadové číslo VLF někdy zalomí kolem nuly (pokud je další pořadové číslo VLF menší než předchozí).

VLF a bloky protokolu

V rámci VLF existují bloky protokolu různé velikosti. Minimální velikost bloku protokolu je 512 bajtů a bloků protokolu rostou až do maximální velikosti 60 kB . Velikost je nastavena, když nastane jeden z následujících případů:

  • Transakce vygeneruje záznam protokolu k potvrzení dokončení přerušení transakce
  • Velikost bloku protokolu dosahuje 60 kB bez potvrzení nebo přerušení transakce

Uvnitř bloku protokolu jsou záznamy protokolu (v diagramu vybarveny). Záznamy protokolu mají také variabilní velikost. Diagram ukazuje, že záznamy protokolu z více souběžných transakcí mohou existovat ve stejném bloku protokolu. Záznamy protokolu jsou uloženy v pořadí zapsaném podobně jako soubor datové stránky.

Každý VLF obsahuje hlavičku VLF s následujícími informacemi:

  • Zda je VLF aktivní nebo ne.
  • Pořadové číslo protokolu při vytvoření VLF.
  • Aktuální paritní bity pro všechny 512bajtové bloky ve VLF.

Paritní bity začínají na 64 pro úplně první použití VLF. Pokud se VLF stane neaktivním, ale dále se znovu aktivuje, paritní bity se stanou 128. Tyto bity se používají při obnově po havárii.

Zkoumání podrobností protokolu transakcí – DBCC LOGINFO

Jediný způsob, jak se podívat na strukturu protokolu transakcí, je použít nezdokumentované DBCC LOGINFO příkaz. Syntaxe příkazu je:

DBCC LOGINFO [({'dbname | dbid'})]

Pokud nezadáte název databáze a dbid , vypíše vám obsah protokolu pro aktuální databázi.

Výsledkem je jeden řádek pro každý VLF, který je v protokolu transakcí pro danou databázi. Vrácená pole jsou:

  • RecoveryUnitId — přidáno v SQL Server 2012, ale momentálně se nepoužívá
  • ID souboru — ID souboru protokolu transakcí v databázi.
  • Velikost souboru — Velikost VLF v bajtech.
  • Počáteční odsazení — počáteční offset VLF v souboru protokolu transakcí v bajtech
  • FSeqNo — Pořadové číslo VLF
  • Stav — Zda je VLF aktivní nebo ne (0 =neaktivní, 2 =aktivní, 1 – nepoužívá se)
  • Parita — aktuální paritní bity (64 nebo 128 nebo 0, pokud VLF nebyl nikdy aktivní)
  • VytvořteLSN — LSN při vytvoření VLF (0 =VLF byl vytvořen při prvotním vytvoření souboru protokolu transakcí). Všechny ostatní VLF přidané po počátečním vytvoření souboru protokolu transakcí budou mít nenulovou hodnotu CreateLSN.

Pro DBTest2014 můžeme provést následující příkaz databáze, kterou jsme vytvořili dříve:

DBCC LOGINFO (N'DBTest2014');
GO

Podívejte se na výsledek:

DBCC SQLPERF (LOGSPACE)

Jediným způsobem, jak v Transact-SQL prozkoumat množství použitého protokolu, je DBCC SQLPERF. Syntaxe příkazu je:

DBCC SQLPERF
(
     [ LOGSPACE ]
     |
          [ "sys.dm_os_latch_stats" , CLEAR ]
     |
     [ "sys.dm_os_wait_stats" , CLEAR ]
)
     [WITH NO_INFOMSGS ]

Příkaz vrátí sadu výsledků s jedním řádkem na databázi:

  • Název databáze
  • Velikost protokolu (MB)
  • Využité místo protokolu (%)
  • Stav:vždy nastaven na nulu

V mém prostředí následující příkaz:

DBCC SQLPERF (LOGSPACE);
GO

Vrátí následující výsledek:

V příštím článku se podíváme na záznamy protokolu.


  1. Jak vrátit výsledky dotazu jako seznam oddělený čárkami v PostgreSQL

  2. Jak volat uloženou proceduru Oracle, která obsahuje uživatelsky definovaný typ v jazyce Java?

  3. Určení umístění příslušného souboru tnsnames.ora

  4. Zlepšete ladění výkonu SQL Server pomocí těchto 3 tipů