AZ SQL Server tranzakciónaplójának architektúrája és kezelési útmutatója

Vonatkozik a következőkre:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalitikai Platform System (PDW)SQL adatbázis a Microsoft Fabric-ben

Minden SQL Server-adatbázis rendelkezik egy tranzakciónaplóval, amely rögzíti az egyes tranzakciók által végrehajtott összes tranzakciót és adatbázis-módosítást. A tranzakciónapló az adatbázis kritikus összetevője, és rendszerhiba esetén előfordulhat, hogy a tranzakciónaplóra szükség lehet az adatbázis konzisztens állapotba helyezéséhez. Ez az útmutató a tranzakciónapló fizikai és logikai architektúrájáról nyújt információt. Az architektúra megismerése javíthatja a tranzakciónaplók kezelésének hatékonyságát.

Tranzakciónapló logikai architektúrája

Az SQL Server tranzakciónaplója logikailag úgy működik, mintha a tranzakciónapló naplórekordok sztringje. Minden naplórekordot egy naplóütemezési szám (LSN) azonosít. A rendszer minden új naplórekordot a napló logikai végébe ír egy olyan LSN-vel, amely magasabb, mint az előtte lévő rekord LSN-e. A naplórekordok létrehozásakor a rendszer soros sorrendben tárolja a naplórekordokat, így ha az LSN2 nagyobb, mint az LSN1, akkor az LSN2 által hivatkozott naplórekord által leírt változás az LSN1 naplórekord által leírt módosítás után történt. Minden naplórekord tartalmazza annak a tranzakciónak az azonosítóját, amelyhez tartozik. Minden tranzakció esetében a tranzakcióhoz társított összes naplórekord külön-külön van összekapcsolva egy láncban a tranzakció visszaállítását felgyorsító visszafelé mutató mutatókkal.

Az LSN alapstruktúrája a [VLF ID:Log Block ID:Log Record ID]. További információt a VLF és a naplóblokkok szakaszaiban talál.

Íme egy példa egy LSN-re: 00000031:00000da0:0001ahol 0x31 a VLF azonosítója, 0xda0 a naplóblokk azonosítója, és 0x1 a naplóblokk első naplórekordja. LSN-példák esetén tekintse meg sys.dm_db_log_info DMV kimenetét, és vizsgálja meg az oszlopot vlf_create_lsn .

Az adatmódosítások naplórekordjai vagy a végrehajtott logikai műveletet rögzítik, vagy a módosított adatok előtti és utáni képeket rögzítik. Az előző kép az adatok másolata a művelet végrehajtása előtt; az after image az adatok másolata a művelet végrehajtása után.

A művelet helyreállításának lépései a naplórekord típusától függenek:

• Logikai művelet naplózva

  • A logikai művelet továbbgördítéséhez a rendszer ismét végrehajtja a műveletet.
  • A logikai művelet visszaállításához a fordított logikai művelet lesz végrehajtva.

• Kép naplózása előtt és után

  • A művelet előregördítéséhez az utóképet kell alkalmazni.
  • A művelet visszaállításához az előző állapotot visszaállítja.

A tranzakciónapló számos művelettípust rögzít. Ezek a műveletek a következők:

• Az egyes tranzakciók kezdete és vége.

• Minden adatmódosítás (beszúrás, frissítés vagy törlés). A módosítások közé tartozik a rendszer által tárolt eljárások vagy az adatdefiníciós nyelv (DDL) utasításainak módosítása bármely táblában, beleértve a rendszertáblákat is.

• Minden kiterjedés és oldal allokáció vagy felszabadítás.

• Tábla vagy index létrehozása vagy elvetése.

A rendszer a visszaállítási műveleteket is naplózza. Minden tranzakció helyet foglal le a tranzakciónaplóban, hogy elegendő naplóterület legyen a visszaállítás támogatásához, amelyet egy explicit visszaállítási utasítás okoz, vagy ha hiba történik. A fenntartott terület mennyisége a tranzakcióban végrehajtott műveletektől függ, de általában megegyezik az egyes műveletek naplózásához használt területtel. Ezt a fenntartott területet a tranzakció befejezésekor szabadítjuk fel.

A naplófájl azon szakaszát, amelynek az adatbázis egészére kiterjedő sikeres visszaállításhoz jelen kell lennie az első naplórekordból az utolsó írásos naplórekordra, a napló aktív részének, aktív naplójának vagy farkának nevezzük. Ez a naplónak az a része, amely szükséges az adatbázis teljes helyreállításához. Az aktív napló egyik része sem csonkítható. Az első naplórekord naplóütemezési száma (LSN) a minimális helyreállítási LSN (MinLSN) néven ismert. A tranzakciónapló által támogatott műveletekről további információt a tranzakciónaplóban talál.

A különbségi és naplóalapú biztonsági mentések egy későbbi időpontra növelik a visszaállított adatbázist, amely egy magasabb LSN-nek felel meg.

Tranzakciónapló fizikai struktúrája

Az adatbázis tranzakciónaplója egy vagy több fizikai fájlra van leképzve. Fogalmilag a naplófájl a naplórekordok karakterlánca. A naplórekordok sorrendje fizikailag hatékonyan van tárolva a tranzakciónaplót megvalósító fizikai fájlok készletében. Minden adatbázishoz legalább egy naplófájlnak kell lennie.

Virtuális naplófájlok (VLF-ek)

Az SQL Server adatbázismotorja az egyes fizikai naplófájlokat belsőleg több virtuális naplófájlra (VLF-ekre) osztja. A virtuális naplófájlok mérete nem rögzített, és a fizikai naplófájlokhoz nincs rögzített számú virtuális naplófájl. Az adatbázismotor dinamikusan választja ki a virtuális naplófájlok méretét a naplófájlok létrehozása vagy kiterjesztése során. Az adatbázismotor megpróbál fenntartani néhány virtuális fájlt. A naplófájlok kiterjesztése után a virtuális fájlok mérete a meglévő napló méretének és az új fájlnövekmény méretének összege. A virtuális naplófájlok méretét vagy számát a rendszergazdák nem konfigurálhatják vagy állíthatják be.

Virtuális naplófájl létrehozása

A virtuális naplófájl (VLF) létrehozása a következő módszert követi:

• Ha az SQL Server 2014 (12.x) és újabb verzióiban a következő növekedés kisebb, mint az aktuális napló fizikai méretének 1/8-a, hozzon létre 1 VLF-et, amely lefedi a növekedési méretet.
• Ha a következő növekedés meghaladja az aktuális naplóméret 1/8-át, akkor alkalmazza a 2014 előtti módszert, azaz:
  • Ha a növekedés kisebb, mint 64 MB, hozzon létre 4 virtuális merevlemezt, amelyek lefedik a növekedési méretet (például 1 MB-os növekedéshez hozzon létre 4 256 KB méretű virtuális gépet).
    • Az Azure SQL Database-ben és az SQL Server 2022-től (16.x) (minden kiadás) kezdődően a logika kissé eltérő. Ha a növekedés kisebb vagy egyenlő 64 MB-nál, az adatbázismotor csak egy VLF-t hoz létre a növekedés méretének fedezésére.
  • Ha a növekedés 64 MB-tól 1 GB-ig terjed, hozzon létre 8 virtuális merevlemezt, amelyek lefedik a növekedési méretet (például 512 MB-os növekedéshez hozzon létre 8 64 MB méretű virtuális gépet).
  • Ha a növekedés nagyobb, mint 1 GB, hozzon létre 16 virtuális merevlemezt, amelyek lefedik a növekedési méretet, például 8 GB-os növekedés esetén, hozzon létre 16 512 MB méretű virtuális gépet.

Ha a naplófájlok nagy méretűre nőnek sok kis lépésben, akkor sok virtuális naplófájlt fognak létrehozni. Ez lelassíthatja az adatbázis indítását, a biztonsági mentési és visszaállítási műveleteket, és tranzakciós replikációt/CDC- és Always On-késést okozhat. Ezzel szemben, ha a naplófájlok nagy méretűre vannak beállítva néhány vagy csak egy növekményes mérettel, akkor néhány nagyon nagy virtuális naplófájlt tartalmaznak. A tranzakciónapló szükséges méretének és automatikus beállításának megfelelő becsléséről további információt a Tranzakciónapló-fájl méretének kezelése című javaslatok című szakaszban talál.

Javasoljuk, hogy a naplófájlokat a szükséges végső mérethez közel hozza létre az optimális VLF-elosztás eléréséhez szükséges növekményekkel, és viszonylag nagy growth_increment értékkel.

Tekintse meg az alábbi tippeket az aktuális tranzakciónapló-méret optimális VLF-eloszlásának meghatározásához:

• Az argumentum által SIZE megadott ALTER DATABASE a naplófájl kezdeti mérete.
• A growth_increment érték (más néven az autogrow érték), amelyet a FILEGROWTHALTER DATABASE argumentuma állít be, a fájlhoz adott terület minden alkalommal, amikor új területre van szükség.

A fájl- és fájlcsoportbeállításokról FILEGROWTH és SIZE argumentumokról ALTER DATABASEaz ALTER DATABASE (Transact-SQL) című témakörben olvashat bővebben.

Tip

Ha meg szeretné határozni az adott példány összes adatbázisának aktuális tranzakciónapló-méretéhez tartozó optimális VLF-eloszlást, valamint a szükséges méret eléréséhez szükséges növekedési növekményeket, tekintse meg ezt a Fixing-VLFs szkriptet a GitHubon.

Mi történik, ha túl sok VLF van?

Az adatbázis-helyreállítási folyamat kezdeti szakaszaiban az SQL Server az összes tranzakciós naplófájlban felderíti az összes VLF-et, és összeállítja ezeknek a virtuális fájloknak a listáját. Ez a folyamat az adott adatbázisban található virtuális merevlemezek számától függően hosszú időt vehet igénybe. Minél több VLF van, annál hosszabb a folyamat. Az adatbázisban sok VLF keletkezhet, ha a tranzakciónapló automatikus vagy manuális növekedése gyakran, kis lépésekben történik. Amikor a VLF-k száma eléri a több százezres tartományt, a következő tünetek némelyikét vagy többségét tapasztalhatja:

• Egy vagy több adatbázis nagyon hosszú időt vesz igénybe a helyreállítás befejezéséhez az SQL Server indítása során.
• Az adatbázis visszaállítása nagyon hosszú időt vesz igénybe.
• Az adatbázis csatolásának kísérlete nagyon hosszú időt vesz igénybe.
• Az adatbázis-tükrözés beállításakor az 1413-at, az 1443-at és az 1479-et jelző hibaüzenet jelenik meg, amely időtúllépést jelez.
• Amikor megpróbál visszaállítani egy adatbázist, memóriahasználattal kapcsolatos hibák, például a 701-es hibaüzenet léphetnek fel.
• A tranzakciós replikáció vagy a változásadat-rögzítés jelentős késést okozhat.

Az SQL Server hibanaplójának vizsgálatakor azt tapasztalhatja, hogy az adatbázis-helyreállítási folyamat elemzési fázisa előtt jelentős mennyiségű időt töltenek el. Például:

2022-05-08 14:42:38.65 spid22s Starting up database 'lot_of_vlfs'.
2022-05-08 14:46:04.76 spid22s Analysis of database 'lot_of_vlfs' (16) is 0% complete (approximately 0 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.

Emellett az SQL Server naplózhat egy MSSQLSERVER_9017 hibát, ha olyan adatbázist állít vissza, amely nagy számú VLF-sel rendelkezik:

Database %ls has more than %d virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.

További információ: MSSQLSERVER_9017.

Nagy számú VLF-et tartalmazó adatbázisok javítása

Ha a VLF-ek teljes számát ésszerű mennyiségben (például legfeljebb néhány ezer) szeretné tartani, az alábbi lépések végrehajtásával visszaállíthatja a tranzakciós naplófájlt, hogy kisebb számú VLF-et tartalmazzon:

1. ** A tranzakció naplófájlok manuális összehúzása.

2. Egy lépésben manuálisan növelje a fájlokat a szükséges méretre a következő T-SQL-szkripttel:

   ALTER DATABASE <database name> MODIFY FILE (NAME='Logical file name of transaction log', SIZE = <required size>);

   Note

   Ez a lépés az SQL Server Management Studióban is lehetséges az adatbázis tulajdonságainak lap használatával.

Miután beállította a tranzakciónapló-fájl új elrendezését kevesebb virtuális naplófájllel, tekintse át és végezze el a szükséges módosításokat a tranzakciónapló automatikus növekedési beállításaiban. Ez a beállításellenőrzés biztosítja, hogy a naplófájl ne ütközjön ugyanazzal a problémával a jövőben.

A műveletek elvégzése előtt győződjön meg arról, hogy rendelkezik érvényes visszaállítható biztonsági mentéssel, ha később problémák merülnek fel.

Az adott példány összes adatbázisának aktuális tranzakciónapló-méretéhez tartozó optimális VLF-eloszlás meghatározásához és a szükséges méret eléréséhez szükséges növekedésnövekedéshez a következő GitHub-szkripttel javíthatja ki a VLF-eket.

Naplóblokkok

Minden VLF egy vagy több naplóblokkot tartalmaz. Minden naplóblokk a naplórekordokból áll (4 bájtos határhoz igazítva). A naplóblokkok mérete változó, és mindig 512 bájtos egész szám (az SQL Server által támogatott minimális szektorméret), maximális mérete 60 KB. A naplóblokk az I/O alapegysége a tranzakciónaplózáshoz.

Összefoglalva, a naplóblokkok olyan naplórekordok tárolói, amelyeket a tranzakciónaplózás alapegységeként használnak a naplórekordok lemezre írásakor.

A VLF-ben lévő összes naplóblokkot egyedileg kezeli a blokkeltolás. Az első blokk mindig olyan blokkeltolással rendelkezik, amely túlmutat a VLF első 8 KB-ján.

A VLF általában mindig naplóblokkokkal van feltöltve. Lehetséges, hogy a VLF utolsó naplóblokkja üres (például nem tartalmaz naplórekordokat). Ez akkor fordul elő, ha egy írandó naplórekord nem fér el az aktuális naplóblokkban, és akkor is, ha a VLF-en maradt hely nem elegendő a naplórekord tárolásához. Ebben az esetben létrejön egy üres naplóblokk, amely kitölti a VLF-et. A naplórekord beszúrásra kerül a következő VLF első blokkjába.

A tranzakciónapló körkörös jellege

A tranzakciónapló egy körkörös fájl. Vegyük például azt az adatbázist, amelynek egy fizikai naplófájlja négy virtuális merevlemezre van osztva. Az adatbázis létrehozásakor a logikai naplófájl a fizikai naplófájl elején kezdődik. A logikai napló végén új naplórekordok jelennek meg, és a fizikai napló vége felé bővülnek. A naplók csonkolása felszabadítja azokat a virtuális naplókat, amelyek rekordjai a minimális helyreállítási naplósorozatszám (MinLSN) előtt jelennek meg. A MinLSN a sikeres adatbázisszintű visszaállításhoz szükséges legrégebbi naplórekord naplósorozatszáma. A példaadatbázis tranzakciónaplója az alábbi ábrán láthatóhoz hasonlóan fog kinézni.

Amikor a logikai napló vége eléri a fizikai naplófájl végét, az új naplórekordok a fizikai naplófájl elejére kerülnek.

Ez a ciklus végtelenül ismétlődik, amíg a logikai napló vége nem éri el a logikai napló elejét. Ha a régi naplórekordokat elég gyakran csonkolja, hogy mindig elegendő helyet hagyjon a következő ellenőrzőponton létrehozott összes új naplórekordnak, a napló soha nem töltődik be. Ha azonban a logikai napló vége eléri a logikai napló elejét, két dolog egyike következik be:

• Ha a FILEGROWTH beállítás engedélyezve van a naplóhoz, és a lemezen szabad terület áll rendelkezésre, a fájl a growth_increment paraméterben megadott mennyiséggel bővül, és az új naplórekordok hozzá lesznek adva a bővítményhez. A beállítással kapcsolatos további információkért lásd: FILEGROWTHALTER DATABASE (Transact-SQL) Fájl- és fájlcsoportbeállítások.

• Ha a FILEGROWTH beállítás nincs engedélyezve, vagy a naplófájlt tartalmazó lemezen kevesebb szabad terület van, mint a growth_increment megadott mennyiség, a rendszer 9002-s hibát okoz. További információ: A teljes tranzakciónapló hibaelhárítása (SQL Server 9002-s hiba).

Ha a napló több fizikai naplófájlt tartalmaz, a logikai napló végighalad az összes fizikai naplófájlon, mielőtt visszafut az első fizikai naplófájl elejére.

Important

A tranzakciónapló méretének kezelésével kapcsolatos további információkért lásd a tranzakciónapló-fájl méretének kezelését ismertető témakört.

Napló csonkolása

A napló csonkolása elengedhetetlen ahhoz, hogy a napló ne töltődjön fel. A naplófuttatás törli az inaktív virtuális naplófájlokat egy SQL Server-adatbázis logikai tranzakciónaplójából, és helyet szabadít fel a logikai naplóban, hogy a fizikai tranzakciónapló újra felhasználja őket. Ha egy tranzakciós naplót soha nem csonkítanak, az végül teljesen kitölti a fizikai naplófájljaihoz lefoglalt összes lemezterületet. Mielőtt azonban a naplót csonkítanák, ellenőrzőpont-műveletet kell végrehajtani. Az ellenőrzőpont az aktuális memóriabeli módosított lapokat (más néven piszkos oldalakat) és a tranzakciónapló adatait írja a memóriából a lemezre. Az ellenőrzőpont végrehajtásakor a tranzakciónapló inaktív része újrahasználhatóként lesz megjelölve. Ezt követően a napló csonkolása felszabadíthatja az inaktív részt. Az ellenőrzőpontokról további információt az Adatbázis ellenőrzőpontjai (SQL Server) című témakörben talál.

Az alábbi ábrák egy tranzakciós naplót mutatnak a csonkolás előtt és után. Az első ábrán egy olyan tranzakciónapló látható, amelyet még nem csonkolt le. Jelenleg négy virtuális naplófájlt használ a logikai napló. A logikai napló az első virtuális naplófájl elején kezdődik, és a 4. virtuális naplónál ér véget. A MinLSN rekord a 3. virtuális naplóban található. Az 1. virtuális napló és a 2. virtuális napló csak inaktív naplórekordokat tartalmaz. Ezek a rekordok csonkíthatók. Az 5. virtuális napló még használaton kívül van, és nem része az aktuális logikai naplónak.

A második diagram bemutatja, hogyan jelenik meg a napló a rövidítés után. Az 1. virtuális napló és a 2. virtuális napló újra felhasználható. A logikai napló most a 3. virtuális napló elején kezdődik. A virtuális napló 5 még használaton kívül van, és nem része az aktuális logikai naplónak.

A napló csonkolása a következő események után automatikusan megtörténik, kivéve, ha valamilyen okból késik:

• Az egyszerű helyreállítási modell szerint, egy ellenőrzőpont után.
• Teljes vagy tömegesen naplózott helyreállítási modell esetén, a napló biztonsági mentése után, ha az előző biztonsági mentés óta történt egy ellenőrzőpont.

A napló csonkolását különböző tényezők késleltethetik. A napló csonkolásának hosszú késleltetése esetén a tranzakciónapló kitölthető. További információért lásd: A napló csonkolását késleltető tényezők és Teljes tranzakciónapló (SQL Server 9002-es hiba) hibaelhárítása.

Előrekönyvelésű tranzakciónapló

Ez a szakasz az előre írt tranzakciónapló szerepét ismerteti a lemez adatmódosításainak rögzítésében. Az SQL Server egy írás előtti naplózási (WAL) algoritmust használ, amely garantálja, hogy a rendszer nem ír adatokat a lemezre, mielőtt a kapcsolódó naplórekordot lemezre írták. Ez fenntartja egy tranzakció ACID-tulajdonságait.

A WAL-ról további információt az SQL Server I/O alapjaiban talál.

A tranzakciónaplóval kapcsolatos írási naplózás működésének megértéséhez fontos tudnia, hogy a rendszer hogyan írja a módosított adatokat a lemezre. Az SQL Server egy puffer-gyorsítótárat (más néven pufferkészletet) tart fenn, amelybe adatoldalakat olvas be az adatok lekérésekor. Ha egy lap módosul a puffergyorsítótárban, a rendszer nem írja vissza azonnal a lemezre; ehelyett a lap piszkosként van megjelölve. Egy adatlap több logikai írást is tartalmazhat, mielőtt fizikailag lemezre íródott volna. Minden logikai íráshoz a rendszer egy tranzakciónapló-rekordot szúr be a módosítást rögzítő naplógyorsítótárba. A naplórekordokat a lemezre kell írni, mielőtt a társított piszkos lapot eltávolítanák a puffergyorsítótárból, és lemezre íranák. Az ellenőrzőpont-folyamat rendszeres időközönként ellenőrzi a puffergyorsítótárat egy megadott adatbázis lapjaival, és az összes piszkos lapot lemezre írja. Az ellenőrzőpontok időt takaríthatnak meg egy későbbi helyreállítás során, ha létrehoznak egy pontot, ahol az összes piszkos lap garantáltan lemezre lett írva.

Módosított adatlap írása a puffergyorsítótárból a lemezre az oldal kiürítése. Az SQL Server olyan logikával rendelkezik, amely megakadályozza, hogy a társított naplórekord megírása előtt a rendszer kiürítse a piszkos lapokat. A naplórekordokat a rendszer a naplópufferek kiürítésekor írja a lemezre. Ez akkor fordul elő, amikor egy tranzakció véglegesítése történik, vagy a naplópufferek megtelnek.

Tranzakciónapló biztonsági mentései

Ez a szakasz a tranzakciónaplók biztonsági mentésére és visszaállítására (alkalmazására) vonatkozó fogalmakat ismerteti. A teljes és tömegesen naplózott helyreállítási modellekben a tranzakciónaplók (naplók biztonsági mentései) rutinszerű biztonsági mentése szükséges az adatok helyreállításához. Biztonsági másolatot készíthet a naplóról, amíg a teljes biztonsági mentés fut. A helyreállítási modellekről további információt az SQL Server-adatbázisok biztonsági mentése és visszaállítása című témakörben talál.

Az első napló biztonsági mentésének létrehozása előtt létre kell hoznia egy teljes biztonsági másolatot, például egy adatbázis biztonsági mentését, vagy az elsőt a fájlmentések készletében. Az adatbázis visszaállítása csak fájl biztonsági másolatok használatával bonyolulttá válhat. Ezért javasoljuk, hogy amikor teheti, kezdje a teljes adatbázis-biztonsági mentéssel. Ezt követően a tranzakciónapló rendszeres biztonsági mentése szükséges. Ez nemcsak minimalizálja a munka elvesztésének kitettségét, hanem lehetővé teszi a tranzakciós napló csonkolását is. A tranzakciónaplót általában minden hagyományos naplómentés után csonkítják.

A visszaállítandó naplók biztonsági mentéseinek számának korlátozásához elengedhetetlen az adatok rutinszerű biztonsági mentése. Ütemezhet például heti teljes adatbázis-biztonsági mentést és napi különbségi adatbázis-biztonsági mentéseket.

A helyreállítási stratégia megvalósításakor gondolja át a szükséges RTO-t és RPO-t , és különösen a teljes és differenciált adatbázis-biztonsági mentési ütemet.

A tranzakciónaplók biztonsági mentéséről további információt a Tranzakciónapló biztonsági másolatai (SQL Server) című témakörben talál.

Biztonsági mentés gyakorisága és üzleti követelményei

Elég gyakran kell biztonsági másolatot készítenie a naplókról, hogy támogassa az üzleti követelményeket, különösen a munkavesztéssel szembeni tűrőképességét, például a sérült naplótárolók okozhatják.

A naplók biztonsági mentésének megfelelő gyakorisága attól függ, hogy milyen tűréshatáron van a munkaveszteségnek való kitettség, és hány napló biztonsági mentést tárolhat, kezelhet és esetleg visszaállíthat. A helyreállítási stratégia megvalósításakor gondolja át a szükséges helyreállítási időkorlátot (RTO) és helyreállításipont-célkitűzést (RPO), és különösen a naplók biztonsági mentési ütemét.

Ha 15–30 percenként készít biztonsági másolatot a naplóról, az elég lehet. Ha vállalata megköveteli a munkaveszteség-kitettség minimalizálását, érdemes lehet gyakrabban biztonsági másolatot készíteni a naplókról. A gyakoribb naplók biztonsági mentésének előnye, hogy növeli a naplók csonkolásának gyakoriságát, ami kisebb naplófájlokat eredményez.

A naplólánc

A naplók biztonsági mentéseinek folyamatos sorozatát naplóláncnak nevezzük. A naplólánc az adatbázis teljes biztonsági mentésével kezdődik. Az új naplóláncok általában csak akkor indulnak el, ha az adatbázisról először készít biztonsági másolatot, vagy a helyreállítási modell egyszerű helyreállításról teljes vagy tömegesen naplózott helyreállításra vált. Ha nem írja felül a meglévő biztonsági mentési csoportokat teljes adatbázis-biztonsági mentés létrehozásakor, a meglévő naplólánc érintetlen marad. Ha a naplólánc érintetlen, visszaállíthatja az adatbázist bármely teljes adatbázis-biztonsági mentésből a médiakészletben, majd az összes későbbi napló biztonsági mentésből egészen a helyreállítási pontig. A helyreállítási pont lehet az utolsó napló biztonsági mentésének vége, vagy egy adott helyreállítási pont bármelyik naplóbeli biztonsági mentésben. További információ: Tranzakciónaplók biztonsági mentései (SQL Server).

Az adatbázis meghibásodási pontig történő visszaállításához a naplóláncnak érintetlennek kell lennie. Vagyis a tranzakciónaplók biztonsági mentéseinek töretlen sorozatának egészen a meghibásodási pontig ki kell terjednie. Ha a naplósorozatnak el kell indulnia, az a visszaállítandó adatmásolatok típusától függ: adatbázis, részleges vagy fájl. Adatbázis vagy részleges biztonsági mentés esetén a napló biztonsági mentéseinek sorozatának az adatbázis végétől vagy a részleges biztonsági mentéstől kell terjednie. Fájlok biztonsági mentéseinek halmaza esetében a naplómentések sorozatának a teljes fájlmentés készletétől kell indulnia. További információért lásd: Tranzakciónapló-biztonsági mentések (SQL Server).

Napló biztonsági mentéseinek visszaállítása

A napló biztonsági mentésének visszaállítása a tranzakciónaplóban rögzített módosításokat továbbítja az adatbázis pontos állapotának újbóli létrehozásához a napló biztonsági mentési műveletének elindításakor. Adatbázis visszaállításakor vissza kell állítania a visszaállított teljes adatbázis-biztonsági mentés után létrehozott napló biztonsági másolatait, vagy az első visszaállított fájl biztonsági mentésének kezdetétől kezdve. A legutóbbi adatok vagy különbségi biztonsági mentések visszaállítása után általában vissza kell állítania egy napló biztonsági mentési sorozatát, amíg el nem éri a helyreállítási pontot. Ezután helyreállítja az adatbázist. Ezzel visszaállítja az összes olyan tranzakciót, amely nem volt teljes a helyreállítás megkezdésekor, és online állapotba helyezi az adatbázist. Az adatbázis helyreállítása után nem állíthat vissza több biztonsági másolatot. További információért lásd: Tranzakciónapló-biztonsági mentések (SQL Server).

Ellenőrzőpontok és a napló aktív része

Az ellenőrzőpontok kiürítik a piszkos adatoldalakat az aktuális adatbázis puffergyorsítótárából a lemezre. Ez minimálisra csökkenti a napló aktív részét, amelyet az adatbázis teljes helyreállítása során fel kell dolgozni. A teljes helyreállítás során a következő típusú műveletek hajthatók végre:

• A rendszer leállítása előtt a lemezre nem írt módosítások naplórekordjait előre görgetik.
• A rendszer visszaállítja a hiányos tranzakciókhoz társított összes módosítást, például azokat a tranzakciókat, amelyekhez nincs COMMIT vagy ROLLBACK naplórekord van.

Ellenőrzőpont-művelet

Az ellenőrzőpont a következő folyamatokat hajtja végre az adatbázisban:

• Rekordot ír a naplófájlba, megjelölve az ellenőrzőpont kezdetét.

• Az ellenőrzőponthoz rögzített adatokat az ellenőrzőpont-naplórekordok láncában tárolja.

  Az ellenőrzőpontban rögzített információk egyike az első naplórekord naplóütemezési száma (LSN), amely a sikeres adatbázisszintű visszaállításhoz jelen kell lennie. Ezt az LSN-t minimális helyreállítási LSN-nek (MinLSN) nevezzük. A MinLSN az alábbiak közül a legkisebb érték:

  • Az ellenőrzőpont kezdetének LSN-je.
  • A legrégebbi aktív tranzakció kezdetének LSN-je.
  • A legrégebbi replikációs tranzakció elindításának LSN-azonosítója, amely még nem lett kézbesítve a terjesztési adatbázisba.

  Az ellenőrzőpont-rekordok az adatbázist módosító összes aktív tranzakció listáját is tartalmazzák.

• Ha az adatbázis az egyszerű helyreállítási modellt használja, újrafelhasználásra kijelöli a MinLSN előtti területet.

• Az összes piszkos naplót és adatlapot lemezre írja.

• Az ellenőrzőpont végét jelző rekordot ír a naplófájlba.

• A lánc elejének LSN-ét az adatbázis rendszerindító oldalára írja.

Ellenőrzőpontot okozó tevékenységek

Az ellenőrzőpontok a következő helyzetekben fordulnak elő:

• A CHECKPOINT rendszer explicit módon végrehajt egy utasítást. A kapcsolat aktuális adatbázisában ellenőrzőpont jelenik meg.

• A rendszer minimálisan naplózott műveletet hajt végre az adatbázisban; A rendszer például tömeges másolási műveletet hajt végre a Bulk-Logged helyreállítási modellt használó adatbázisban.

• Az adatbázisfájlokat a rendszer hozzáadta vagy eltávolította a következő használatával ALTER DATABASE: .

• Az SQL Server egy példányát egy SHUTDOWN utasítás vagy az SQL Server (MSSQLSERVER) szolgáltatás leállítása állítja le. Bármelyik művelet az SQL Server-példányban lévő adatbázisokban ellenőrzőpontot eredményez.

• Az SQL Server egy példánya rendszeres időközönként automatikus ellenőrzőpontokat hoz létre az egyes adatbázisokban, hogy csökkentse az adatbázis helyreállításához szükséges időt.

• A rendszer biztonsági másolatot készít az adatbázisról.

• Egy adatbázis-leállítást igénylő tevékenység történik. Ez akkor fordulhat elő, ha a AUTO_CLOSE beállítás és ON az adatbázishoz való utolsó felhasználói kapcsolat bezárul. Egy másik példa az adatbázis-beállítás módosítása, amely az adatbázis újraindítását igényli.

Automatikus ellenőrzőpontok

Az SQL Server adatbázismotor automatikus ellenőrzőpontokat hoz létre. Az automatikus ellenőrzőpontok közötti időköz a felhasznált naplóterület és az utolsó ellenőrzőpont óta eltelt idő alapján történik. Az automatikus ellenőrzőpontok közötti időintervallum nagyon változó és hosszú lehet, ha kevés módosítás történik az adatbázisban. Az automatikus ellenőrzőpontok gyakran akkor is előfordulhatnak, ha sok adatot módosítanak.

A helyreállítási időköz kiszolgáló konfigurációs beállításával kiszámíthatja a kiszolgálópéldány összes adatbázisának automatikus ellenőrzőpontjai közötti időközt. Ez a beállítás határozza meg, hogy az adatbázismotor a rendszer újraindítása során mennyi időt használjon az adatbázis helyreállítására. Az adatbázismotor becslést ad arról, hogy hány naplórekordot képes feldolgozni a helyreállítási időközben a helyreállítási művelet során.

Az automatikus ellenőrzőpontok közötti intervallum a helyreállítási modelltől is függ:

• Ha az adatbázis a teljes vagy tömegesen naplózott helyreállítási modellt használja, a rendszer automatikus ellenőrzőpontot hoz létre, amikor a naplórekordok száma eléri azt a számot, amelyet az adatbázismotor a helyreállítási időköz beállításban megadott idő alatt feldolgozhat.

• Ha az adatbázis az egyszerű helyreállítási modellt használja, automatikus ellenőrzőpont jön létre, amikor a naplórekordok száma eléri a két érték közül a kisebbet:

  • A napló 70%-kal megtelik.
  • A naplórekordok száma eléri azt a számot, ahányszor az adatbázismotor becslése szerint feldolgozható a helyreállítási időköz beállításban megadott idő alatt.

A helyreállítási időköz beállításáról további információt a Kiszolgáló konfigurációja: helyreállítási időköz (perc) című témakörben talál.

Tip

Az -k SQL Server speciális beállításával az adatbázis-rendszergazda szabályozhatja az ellenőrzőpontok I/O-viselkedését az I/O-alrendszer bizonyos típusú ellenőrzőpontok átviteli sebessége alapján. A -k beállítás az automatikus ellenőrzőpontokra és az egyébként nem szabályozott ellenőrzőpontokra vonatkozik.

Az automatikus ellenőrzőpontok csonkítják a tranzakciónapló nem használt szakaszát, ha az adatbázis az egyszerű helyreállítási modellt használja. Ha azonban az adatbázis a teljes vagy tömegesen naplózott helyreállítási modelleket használja, a naplót nem csonkolja automatikus ellenőrzőpontok. További információ: A tranzakciónapló.

Az CHECKPOINT utasítás mostantól egy opcionális checkpoint_duration argumentumot ad meg, amely másodpercekben határozza meg a kért időtartamot az ellenőrzőpontok befejezéséhez. További információ: CHECKPOINT.

Aktív napló

A naplófájl MinLSN-ről az utolsó megírt naplórekordra vonatkozó szakaszát a napló aktív részének vagy az aktív naplónak nevezzük. Ez a napló azon szakasza, amely az adatbázis teljes helyreállításához szükséges. Az aktív napló egyik része sem csonkítható. Az összes naplórekordot csonkolni kell a MinLSN előtti naplórészekből.

Az alábbi ábra a tranzakcióvégi napló egyszerűsített verzióját mutatja be két aktív tranzakcióval. Az ellenőrzőpontok rekordjai egyetlen rekordra lettek tömörítve.

Az LSN 148 a tranzakciónapló utolsó rekordja. Az LSN 147-ben rögzített ellenőrzőpont feldolgozásakor a Tran 1 véglegesítése megtörtént, és a Tran 2 volt az egyetlen aktív tranzakció. Ez teszi a Tran 2 első naplórekordját a legrégebbi naplórekorddá egy olyan tranzakció esetén, amely az utolsó ellenőrzőpont idején volt aktív. Ez teszi az LSN 142-et, a Tran 2 tranzakciós rekordját, a MinLSN-t.

Hosszú ideig futó tranzakciók

Az aktív naplónak tartalmaznia kell az összes nem véglegesített tranzakció minden részét. Egy olyan alkalmazás, amely elindít egy tranzakciót, és nem véglegesíti vagy visszaállítja, megakadályozza, hogy az adatbázismotor előrehaladjon a MinLSN-ben. Ez a helyzet kétféle problémát okozhat:

• Ha a rendszer leáll, miután a tranzakció számos nem véglegesített módosítást hajtott végre, a későbbi újraindítás helyreállítási fázisa sokkal tovább tarthat, mint a helyreállítási időköz beállításban megadott idő.
• Előfordulhat, hogy a napló nagyon nagy lesz, mert a napló nem csonkolható a MinLSN-n túl. Ez akkor is előfordul, ha az adatbázis az egyszerű helyreállítási modellt használja, amelyben a tranzakciónaplót minden automatikus ellenőrzőponton csonkolja a rendszer.

A hosszú ideig futó tranzakciók helyreállítása és a cikkben ismertetett problémák elkerülhetők az SQL Server 2019 -től (15.x) és az Azure SQL Database-től kezdve elérhető gyorsított adatbázis-helyreállítással.

Replikációs tranzakciók

A Naplóolvasó ügynök figyeli a tranzakciós replikációhoz konfigurált adatbázisok tranzakciónaplóját, és a tranzakciónaplóból a terjesztési adatbázisba másolja a replikációra megjelölt tranzakciókat. Az aktív naplónak tartalmaznia kell az összes olyan tranzakciót, amely replikációra van megjelölve, de még nem lett kézbesítve a terjesztési adatbázisba. Ha ezeket a tranzakciókat nem replikálják időben, megakadályozhatják a napló csonkolását. További információ: Tranzakciós replikáció.

Kapcsolódó tartalom

• Tranzakció-napló
• A tranzakciós naplófájl méretének kezelése
• tranzakciónapló biztonsági mentései (SQL Server)
• adatbázis-ellenőrzőpontok (SQL Server)
• Kiszolgálókonfiguráció: helyreállítási időköz (perc)
• A gyorsított adatbázis-helyreállítás
• sys.dm_db_log_info (Transact-SQL)
• sys.dm_db_log_space_usage (Transact-SQL)
• Az SQL Server naplózásának és helyreállításának ismertetése