Během své kariéry datového profesionála, jak v Microsoftu, tak jako konzultant, jsem zjistil, že jednou z nejvíce nepochopených částí databáze SQL Server je protokol transakcí. Nedostatek znalostí o tom, jak protokol transakcí funguje a jak je potřeba jej spravovat, nebo jen jednoduché mylné představy mohou vést ke všem druhům produkčních problémů, včetně:
- Protokol transakcí se vymyká kontrole a může mu docházet místo
- Problémy s výkonem v důsledku opakovaného zmenšování protokolu transakcí
- Problémy s výkonem způsobené problémem známým jako fragmentace VLF , o kterém jsem hovořil v tomto příspěvku
- Nemožnost obnovení do požadovaného bodu v čase pomocí záloh protokolu transakcí
- Nemožnost provést zálohu tail-logu během obnovy po havárii (vysvětlení záloh tail-log viz zde)
- Různé problémy týkající se převzetí služeb při selhání a obnovení výkonu
Tímto příspěvkem zahajuji příležitostnou sérii o transakčním protokolu a o tom, jak funguje a měl by být spravován, a v průběhu se dotknu všech výše uvedených problémů. V tomto příspěvku vysvětlím, co je protokolování a proč je vyžadováno.
Základní terminologie týkající se protokolování
Když mluvím o jakémkoli mechanismu v SQL Server, zjišťuji, že existuje problém s kuřecím masem a vejci, kdy musím použít slovo nebo frázi, než to vysvětlím. Abych se vyhnul tomuto problému v této sérii, začnu tím, že vysvětlím nějakou terminologii, kterou je třeba použít při diskuzi o protokolování, a mnohé z těchto pojmů rozšířím v průběhu série.
Transakce, potvrzení a vrácení
Transakce zahrnuje změnu nebo sadu změn v databázi. Má definovaný začátek a definovaný konec. Začátek je, když je použit příkaz BEGIN TRANSACTION nebo SQL Server automaticky zahájí transakci za vás. Konec může být jednou ze čtyř věcí:
- Transakce se potvrdí, když je proveden příkaz COMMIT TRANSACTION
- Transakce se potvrdí, když SQL Server automaticky potvrdí transakci v případě transakce automatického potvrzení
- Transakce se dokončí po provedení příkazu ROLLBACK TRANSACTION
- Po výskytu problému se transakce dokončí a SQL Server transakci automaticky vrátí
Když se transakce potvrdí, provedené změny jsou dokončeny v databázi a jsou trvalé v protokolu transakcí SQL Serveru na disku. Všimněte si, že jsem řekl „v protokolu transakcí“. Skutečné změny stránek datového souboru v paměti *nejsou* zapsány na disk při potvrzení transakce. Nemusí být trvalé v datových souborech, protože změny jsou již trvalé v protokolu transakcí. Nakonec budou stránky datového souboru zapsány na disk operací kontrolního bodu.
A naopak, když se transakce vrátí zpět, provedené změny dat již nejsou v databázi přítomny. V databázi budou stále docházet k určitým fyzickým změnám, protože vrácení transakce znamená provedení více změn, ale můžete si myslet, že vrácená transakce nemá vliv na data v databázi.
Kontrolní body a operace vrácení zpět jsou témata hodná jejich vlastních příspěvků, takže je vysvětlím později v seriálu.
Tyto tři pojmy probírám mnohem hlouběji v tutoriálu Úvod do SQL Server Transactions na blogu SentryOne.
Protokolování, záznamy protokolu a protokol transakcí serveru SQL Server
Protokolování jednoduše znamená vytvoření trvalého popisu změny v databázi, téměř vždy v kontextu transakce. Po provedení změny je změna popsána v záznamu protokolu. Záznam protokolu obvykle obsahuje dostatek informací, aby bylo možné změnu přehrát v databázi nebo v případě potřeby vrátit zpět do databáze.
Tento záznam protokolu bude zpočátku v paměti a může být zapsán na disk před potvrzením transakce, ale rozhodně musí být zapsán na disk před transakce může dokončit potvrzení, jinak by transakce nebyla trvalá. Výjimkou z tohoto pravidla je případ zpožděné trvanlivosti je povolena funkce, kterou Aaron Bertrand popisuje v tomto příspěvku.
Záznamy protokolu jsou uloženy v protokolu transakcí (jeden nebo více souborů protokolu na disku), který má poněkud složitou vnitřní architekturu, a o tom a mnohem více o záznamech protokolu pojednám v dalším příspěvku v sérii.
Obnova po havárii
Zhroucení je místo, kde se SQL Server neočekávaně vypnul a různé změněné databáze nebylo možné vypnout správně (ujistit se, že všechny změněné stránky datového souboru jsou zapsány na disk a databáze je označena jako čistě vypnutá).
Při spuštění SQL Server zkontroluje všechny databáze, aby zjistil, zda některé nebyly označeny jako čistě vypnuté. Pokud nějakou najde, musí tato databáze projít obnovením po havárii. Tím je zajištěno následující:
- U všech transakcí, které byly potvrzeny před selháním, zajistěte, aby se všechny změny v transakci projevily v databázi (tj. přehrajte transakci)
- U každé transakce, která nebyla potvrzena před havárií, zajistěte, aby se žádná ze změn v transakci neprojevila v databázi (tj. vrátit transakci zpět)
Jinými slovy, zotavení z havárie činí databázi transakčně konzistentní v době, kdy k havárii došlo. Používá se zotavení po havárii:
- Když se SQL Server spustí a najde databázi, kterou je třeba obnovit
- Během převzetí služeb při selhání do sekundární kopie databáze
- Na konci sekvence obnovy zahrnující zálohy (viz zde)
Obnova po havárii je složitý proces a vyžaduje několik dalších příspěvků v sérii, než to budu moci vysvětlit do hloubky.
Proč je vyžadováno protokolování?
Nejzákladnějším důvodem pro protokolování je umožnit databázi SQL Server, aby transakce byly trvalé, takže je lze obnovit během obnovy po havárii nebo vrátit zpět, pokud je to potřeba, během normálních databázových operací. Pokud by neexistovalo žádné protokolování, databáze by byla transačně nekonzistentní a po havárii by možná byla strukturálně poškozená.
Bez protokolování by však řada dalších funkcí na serveru SQL Server nebyla možná, včetně:
- Zálohy dat, které lze trvale obnovovat
- Zálohy protokolu transakcí serveru SQL Server, které lze použít během operace obnovy a implementovat odeslání protokolu
- Replikace, která spoléhá na schopnost sklízet transakce z transakčního protokolu
- Change Data Capture, který používá agenta transakční replikace Log Reader Agent ke sběru změn z protokolu transakcí
- Skupiny zrcadlení databáze a dostupnosti, které se spoléhají na odesílání záznamů protokolu do sekundárních kopií databáze pro přehrání
SQL Server (a všechny podobné databázové servery) používá to, co se nazývá protokolování s předběžným zápisem . To znamená, že popisy změn musí být zapsány na disk před samotnými změnami, aby byla zaručena možnost správné obnovy databáze po havárii. Pokud byla změna zapsána do datového souboru před záznamy protokolu, které ji popisují, a SQL Server by se zhroutil, nebylo by možné zjistit, co se má vrátit, a databáze by byla nekonzistentní. Toto řazení je neměnné bez ohledu na to, jaká úroveň izolace, typ transakce nebo zda je použita funkce odložené trvanlivosti. Nejprve protokolujte záznamy, později datové stránky.
Jen špička ledovce
Jak můžete vidět z tohoto úvodního příspěvku, obrovské množství jde do transakčního protokolu a přihlašování do databáze SQL Serveru a vše, co jsem dosud udělal, je definovat nějakou terminologii na vysoké úrovni a vysvětlit, proč je protokolování vyžadováno. Doufám, že se ke mně připojíte, když se budu rozvětvovat, a půjdete hlouběji, jak bude série postupovat!