Megosztás a következőn keresztül:

Gyorsított adatbázis-helyreállítás

A következőkre vonatkozik: Az SQL Server 2019 (15.x) és újabb verziói az Azure SQL DatabaseAzure SQL Managed InstanceSQL Database-adatbázist a Microsoft Fabricben

A gyorsított adatbázis-helyreállítás (ADR) az adatbázismotor helyreállítási folyamatának újratervezésével javítja az adatbázisok rendelkezésre állását, különösen hosszú ideig futó tranzakciók esetén.

Az ADR az SQL Server 2019-ben (15.x) lett bevezetve, és továbbfejlesztett az SQL Server 2022 (16.x) és az SQL Server 2025 (17.x) rendszerben. Az ADR az Azure SQL Database-ben, az Azure SQL Managed Instance-ben, az Azure Synapse Analyticsben (csak dedikált SQL-készlet) és a Microsoft Fabric SQL Database-ben is elérhető.

Note

Az ADR mindig engedélyezve van az Azure SQL Database-ben, az Azure SQL Managed Instance-ben és az SQL Database-ben a Fabricben.

Ez a cikk áttekintést nyújt az ADR-ről. Az ADR használatához tekintse át Gyorsított adatbázis-helyreállításcímű cikket.

További információ a tranzakciónaplóról és az adatbázis-helyreállításról: SQL Server tranzakciónapló architektúrája és felügyeleti útmutatója és Visszaállítás és helyreállítás áttekintése (SQL Server).

Overview

Az ADR elsődleges előnyei a következők:

  • Gyors és konzisztens adatbázis-helyreállítás

    A hosszú ideig futó tranzakciók nem befolyásolják a teljes helyreállítási időt, így a rendszer aktív tranzakcióinak számától vagy méretétől függetlenül gyors és konzisztens adatbázis-helyreállítást tesz lehetővé.

  • Azonnali tranzakció-visszaállítás

    A tranzakciók visszaállítása azonnal megtörténik, függetlenül attól, hogy a tranzakció aktív volt-e, vagy hány frissítést hajtottak végre.

  • Aggresszív napló csonkolás

    A tranzakciónaplót agresszíven csonkolják, még aktív, hosszú ideig futó tranzakciók esetén is, ami megakadályozza, hogy az ellenőrizetlenül növekedjen.

A hagyományos adatbázis-helyreállítási folyamat

ADR nélkül az adatbázis-helyreállítás az ARIES helyreállítási modellt követi, és három fázisból áll, amelyeket az alábbi diagram részletesebben szemléltet és ismertet:

jelenlegi helyreállítási folyamat ábrája.

  • Elemzési fázis

    Az adatbázismotor előrehaladó beolvasást végez a tranzakciónaplón az utolsó sikeres ellenőrzőponttól (vagy a legrégebbi piszkos oldalnapló sorszámától) az elejétől a végéig, hogy meghatározza az egyes tranzakciók állapotát a motor leállásának időpontjában.

  • Ismétlés fázisa

    Az adatbázismotor a tranzakciónaplót a legrégebbi véglegesítetlen tranzakciótól a végéig továbbítja. Ez a folyamat újra elvégzi az összes lekötött műveletet, hogy visszaállítsa az adatbázis állapotát az összeomlás időpontjában.

  • Visszavonási fázis

    Minden olyan tranzakció esetében, amely az összeomlás időpontjában aktív volt, az adatbázismotor visszafelé halad a naplón, visszavonva a tranzakció által végrehajtott műveleteket.

  • A hagyományos adatbázis-helyreállítási folyamat esetén az összeomlás utáni helyreállítás hosszú időt vehet igénybe, ha egy hosszan futó tranzakció aktív volt.

    Az adatbázismotor váratlan újraindításból való helyreállításának ideje (nagyjából) arányos a rendszer leghosszabb aktív tranzakciójának méretével az összeomlás időpontjában. A helyreállításhoz vissza kell állítani az összes hiányos tranzakciót. A szükséges időtartam arányos a tranzakció által elvégzett munkával és az aktív idővel.

  • A nagy méretű tranzakciók megszakítása vagy visszagördülése hosszú időt vehet igénybe, mivel ugyanazt a visszavonási helyreállítási fázist használja, mint korábban.

  • Az adatbázismotor nem tudja csonkítani a tranzakciónaplót hosszú ideig futó tranzakciók esetén, mert a helyreállítási és visszaállítási folyamatokhoz a megfelelő naplórekordokra van szükség. Ennek eredményeképpen a tranzakciónapló nagyon nagy méretűre nőhet, és sok tárhelyet használhat fel.

Az adatbázis gyorsított helyreállítási folyamata

Az ADR a hagyományos helyreállítási modell korábbi problémáival foglalkozik az adatbázismotor helyreállítási folyamatának teljes újratervezésével a következőre:

  • Állítsa állandóvá a helyreállítási időt, mivel már nincs szükség a tranzakciónapló vizsgálatára a legrégebbi aktív tranzakció elejétől kezdve. Az ADR használatával a tranzakciónaplót csak az utolsó sikeres ellenőrzőponttól (vagy a legrégebbi piszkos lap LSN-jétől) dolgozzák fel. Ennek eredményeképpen a helyreállítási időt nem befolyásolják a hosszú ideig futó tranzakciók, és általában azonnaliak.

  • Csökkentse a szükséges tranzakciónapló-területet, mivel már nincs szükség a teljes tranzakció naplójának megőrzésére. Ennek eredményeképpen a tranzakciónapló agresszívan csonkítható az ellenőrzőpontok és biztonsági mentések során.

Átfogó szinten az ADR gyors adatbázis-helyreállítást ér el minden fizikai adatbázis-módosítás verziózása révén, és csupán a nem verziózott műveletek visszavonása által, amelyek korlátozott számúak, és majdnem azonnal visszavonhatók. Az összeomláskor aktív tranzakciók megszakítottként vannak megjelölve, ezért a tranzakciók által létrehozott összes verziót figyelmen kívül hagyhatják az egyidejű felhasználói lekérdezések.

Az ADR helyreállítási folyamat három fázisból áll, mint a hagyományos helyreállítási folyamat. A fázisok ADR-vel való működését az alábbi ábra szemlélteti:

ADR helyreállítási folyamatának diagramja.

  • Elemzési fázis

    A folyamat ugyanaz marad, mint a hagyományos helyreállítási modellnél, kiegészítve a másodlagos naplóstream (SLOG) rekonstruálásával és a nem verziózott műveletek naplórekordjainak másolásával.

  • Ismétlés fázisa

    Két alfázisra bontva

    • Alfázis 1

      Ismétlés az SLOG-ból (a legrégebbi nem véglegesített tranzakció egészen az utolsó ellenőrzőpontig). Az ismétlés gyors művelet, mivel előfordulhat, hogy csak néhány rekordot kell feldolgoznia az SLOG-ból.

    • 2. részfázis

      A tranzakciónaplóból való újrakezdés a legutóbbi sikeres ellenőrzőponttól indul (a legrégebbi nem véglegesített tranzakció helyett).

  • Visszavonási fázis

    Az ADR visszavonási szakasza szinte azonnal befejeződik az SLOG használatával a nem verziózott műveletek visszavonására, és az állandó verziótár (PVS) logikai visszaállításával hajtja végre a sor szintű verzióalapú visszavonást.

A gyorsított adatbázis-helyreállítás magyarázatáért tekintse meg ezt a nyolcperces videót:

ADR helyreállítási összetevők

Az ADR négy fő összetevője a következő:

  • állandó verziótár (PVS)

    Az állandó verziótároló (PVS) egy adatbázismotor-mechanizmus, a tempdb adatbázis hagyományos verziótárolója helyett magában az adatbázisban tárolja a sorverziókat. A PVS lehetővé teszi az erőforrások elkülönítését, és javítja az olvasható másodtárak rendelkezésre állását.

    A PVS a sorverziókat közvetlenül a módosított adatlapokon vagy egy külön rendszertáblában tárolja. További információ: Állandó verziótár (PVS)által használt terület.

  • Logikai visszaállítás

    A logikai visszaállítás a sorszintű verzióalapú visszavonás végrehajtásáért felelős aszinkron folyamat, amely azonnali tranzakció-visszaállítást és visszavonást biztosít az összes verziójú művelethez.

    • Nyomon követi az összes megszakított tranzakciót
    • A PVS használatával visszaállítást végez az összes felhasználói tranzakcióhoz.
    • A tranzakció megszakítása után azonnal feloldja az összes zárolást

  • SLOG

    Az SLOG egy másodlagos memóriabeli naplóstream, amely naplórekordokat tárol a nem verziózott műveletekhez (például metaadat-gyorsítótár érvénytelenítése, zárolás megszerzése stb.). Az SLOG a következő:

    • Alacsony hangerő és memóriahasználat
    • Az ellenőrzőpont-folyamat során a lemezen megmarad
    • Rendszeresen csonkolásra kerül, amikor a tranzakciók véglegesülnek
    • Felgyorsítja az ismétlést és a visszavonást azáltal, hogy csak a nem verziózott műveleteket dolgozza fel.
    • Engedélyezi az agresszív tranzakciónapló-csonkolást, ha csak a szükséges naplórekordokat őrzi meg

  • Cleaner

    A tisztító az aszinkron folyamat, amely rendszeresen aktiválódik, és megtisztítja az elavult sorverziókat a PVS-ből.

Az ADR előnyeit élvező számítási feladatok

Az ADR az adatbázisok rendelkezésre állásának javításával a legtöbb számítási feladatot kihasználja, és különösen hasznos azoknak a számítási feladatoknak, amelyek a következőkkel rendelkeznek:

  • Hosszú ideig futó tranzakciók.
  • Aktív tranzakciók, amelyek miatt a tranzakciónapló jelentősen növekedni fog.
  • Az adatbázis hosszú ideig nem érhető el a hosszú ideig futó helyreállítás miatt (például a szolgáltatás váratlan újraindítása vagy manuális tranzakció-visszaállítás miatt).

Az ADR előnyeihez verziótárolásra és extra feldolgozásra van szükség, ami bizonyos számítási feladatok teljesítménybeli többletterhelését eredményezheti. Ha például az írásigényes számítási feladatok számos sorverziót hoznak létre, előfordulhat, hogy az adatoldalak gyakrabban lesznek felosztva a soron belüli verziók elhelyezésére. Mivel minden sorverzió naplózva van, a létrehozott tranzakciónapló mennyisége is növekedhet.

A legtöbb számítási feladat esetében az ADR teljesítményterhelése a nem észlelhetőtől a kisebbig terjed. Az optimális adatbázis-kezelési stratégiában kiegyensúlyozza az ADR bizonyos előnyeit a lehetséges teljesítményterheléssel szemben.

Az ADR nem támogatott azokban az adatbázisokban, amelyek adatbázistükrözést alkalmaznak, ami egy régebbi és elavult magas rendelkezésre állású funkció.

Ajánlott eljárások az ADR-hez

  • Kerülje a szükségtelenül hosszú ideig futó tranzakciókat. Bár az ADR felgyorsítja az adatbázisok helyreállítását még a hosszú ideig futó tranzakciók esetén is, az ilyen tranzakciók késleltethetik a verziókarbantartást, és növelhetik a PVS méretét.

  • Kerülje a DDL-műveleteket tartalmazó nagy tranzakciókat. Az ADR a másodlagos naplóstream (SLOG) mechanizmussal követi nyomon a helyreállítás során használt DDL-műveleteket. Az SLOG csak akkor használatos, ha a tranzakció aktív. Az SLOG ellenőrzőponttal van rögzítve, így a nagy tranzakciók elkerülése, amelyek az SLOG-t használják, segíthet az általános teljesítményben. Ezek a forgatókönyvek több helyet foglalnak el az SLOG-nak:

    • A rendszer sok DLL-t hajt végre egy tranzakcióban. Például egy tranzakcióban gyorsan létrehozhat és elvethet ideiglenes táblákat.
    • Egy tábla nagyon sok módosított partíciót/indexet tartalmaz. Az ilyen táblák DROP TABLE művelete például nagy mennyiségű SLOG-memóriát igényelne, ami késleltetné a tranzakciónapló csonkolását, és késleltetné a visszavonási/újraműveleti műveleteket. Áthidaló megoldásként egyenként és fokozatosan ejtse le az indexeket, majd vesse el a táblát.

    További információ az SLOG-ról: ADR helyreállítási összetevők.

  • A szükségtelen megszakított tranzakciók megakadályozása vagy csökkentése. A magas tranzakció-megszakítási arány nyomást gyakorol a PVS-cleanerre, és csökkenti az ADR teljesítményét. A megszakítások a holtpontok magas arányából, a duplikált kulcsokból, a kényszerek megsértéséből, a lekérdezési időtúllépésekből, vagy egyéb kivételekből származhatnak. A sys.dm_tran_aborted_transactions DMV az adatbázismotor példányának összes megszakított tranzakcióját listázza. A nested_abort oszlop azt jelzi, hogy a tranzakció véglegesítve van, de vannak olyan részek, amelyek megszakadtak (mentési pontok vagy beágyazott tranzakciók), amelyek szintén késleltethetik a PVS-törlési folyamatot.

  • Győződjön meg arról, hogy az adatbázisban elegendő hely áll rendelkezésre a PVS-használat figyelembe vételéhez. Ha az adatbázis nem rendelkezik elegendő hely a PVS növekedéséhez, előfordulhat, hogy az ADR nem tud verziókat létrehozni, ami a DML-utasítások sikertelenségéhez vezet.

  • Ha az ADR írásigényes számítási feladatokkal van engedélyezve, a tranzakciónapló-létrehozási arány jelentősen megnőhet, mert a PVS-be írt sorverziók naplózása történik. Ez növelheti a tranzakciónapló biztonsági mentéseinek méretét.

  • Ha tranzakciós replikációt, pillanatkép-replikációtvagy módosítási adatgyűjtést (CDC)használ, az ADR agresszív napló csonkítási viselkedése le van tiltva, hogy a naplóolvasó a tranzakciónapló módosításait gyűjtse össze. Győződjön meg arról, hogy a tranzakciónapló megfelelően nagy méretű.

    Ha az CDC vagy változáscsatornát használja az Azure SQL Database-ben, előfordulhat, hogy növelnie kell a szolgáltatási szintet vagy a számítási méretet annak érdekében, hogy elegendő tranzakciónapló tárhely álljon rendelkezésre az összes számítási feladat igényeinek kielégítésére. Hasonlóképpen előfordulhat, hogy a felügyelt Azure SQL-példányban növelnie kell a példány maximális tárterület-méretét.

  • SQL Server esetén, ha a rétegzett teljesítménytároló elérhető, érdemes lehet a PVS-fájlcsoportot magasabb szintű tárolóba helyezni. További információ: A PVS-fájlcsoport módosítása.

  • Az SQL Server 2022-től kezdve (16.x) érdemes engedélyezni a többszálas PVS-tisztítást, ha az egyszálas tisztítás teljesítménye nem elegendő. További információkért lásd: kiszolgálókonfiguráció: ADR Tisztább szálak száma.

  • Az SQL Server 2025 -től (17.x) kezdődően, ha engedélyezi az ADR-t tempdb, előfordulhat, hogy további helyet kell lefoglalnia a PVS-adatok számára az tempdb adatfájlokban. A PVS tempdb mérete ugyanúgy figyelhető, mint egy felhasználói adatbázisban.

  • Ha olyan problémákat észlel, mint a PVS által használt magas adatbázisterület vagy a lassú PVS-törlés, tekintse meg Monitorozás és a gyorsított adatbázis-helyreállításcímű témakört.

Az ADR fejlesztései az SQL Server 2025-ben

  • ADR a tempdb-ben

    Az SQL Server 2025 -től kezdve (17.x) az ADR engedélyezhető a tempdb-adatbázisban.

    Az ADR nélkül és a minimális naplózás használata tempdbesetén is a hosszú visszaállítás és a nagy tranzakciónapló-használat hatással lehet az olyan tranzakciókra, amelyek objektumokat, például ideiglenes táblákat, táblaváltozókat vagy nem ideiglenes táblákat foglalnak magukban tempdb . A tranzakciónapló-terület elfogyása tempdb jelentős fennakadásokat és az alkalmazások leállását okozhatja.

    Az SQL Server 2025 (17.x) lehetővé teszi az ADR azonnali tranzakció-visszaállítási és agresszív naplócsondolási előnyeit a tranzakciókat tempdbhasználó számítási feladatok számára.

    Az ADR engedélyezéséről tempdbaz ADR engedélyezése című témakörben olvashat.

Az ADR fejlesztései az SQL Server 2022-ben

Az állandó verziótár (PVS) tárolásának kezelése és az általános méretezhetőség javítása számos fejlesztést tartalmaz. További információ az SQL Server 2022 (16.x) új funkcióiról: Az SQL Server 2022újdonságai.

Ugyanezek a fejlesztések az Azure SQL Database-ben, a felügyelt Azure SQL-példányban, az Azure Synapse Analyticsben (csak dedikált SQL-készlet) és a Microsoft Fabric SQL Database-ben is elérhetők.

  • felhasználói tranzakciók törlési

    Olyan oldalak tisztítsd meg, amelyeket a normál folyamat zárolás megszerzésének hibája miatt nem tud megtisztítani.

    Ez a funkció lehetővé teszi, hogy a felhasználói tranzakciók a táblaszintű zárolási ütközések miatt a normál törlési folyamat által nem kezelt oldalakon futtassanak törlést. Ez a fejlesztés segít biztosítani, hogy az ADR-törlési folyamat ne hiúsuljon meg határozatlan ideig, mert a felhasználói számítási feladatok nem tudják megszerezni a táblaszintű zárolásokat.

  • A memóriaigény csökkentése a PVS lapkövetőnél

    Ez a fejlesztés a PVS-oldalakat a terjedelem szintjén követi nyomon, hogy csökkentse a verziószámozott lapok karbantartásához szükséges memóriaigényt.

  • PVS tisztító fejlesztései

    A PVS-tisztító javította a tisztítási hatékonyságot, hogy az adatbázismotor hatékonyabban kövesse nyomon és rögzítse a megszakított tranzakciók sorverzióit. Ez a memória- és tárhasználat javulásához vezet.

  • Tranzakciószintű állandó verziótár (PVS)

    Ez a fejlesztés lehetővé teszi, hogy az ADR megtisztítsa a véglegesített tranzakciókhoz tartozó verziókat attól függetlenül, hogy vannak-e megszakított tranzakciók a rendszerben. Ezzel a fejlesztéssel a PVS-oldalak felszabadíthatók. Ez akkor is lehetséges, ha az átvizsgálás nem tud sikeres befejezést elérni a megszakított tranzakciótérkép csökkentésében.

    Ennek a javulásnak az eredménye a PVS növekedésének csökkentése akkor is, ha a PVS-törlés lassú vagy sikertelen.

  • Többszálas verziótisztítás

    Az SQL Server 2019 -ben (15.x) a törlési folyamat egyetlen szálból áll egy adatbázismotor-példányon belül.

    Az SQL Server 2022 -től (16.x) kezdődően a többszálas verziókarbantartás támogatott. Ez lehetővé teszi, hogy ugyanazon az adatbázismotor-példányon egyszerre több adatbázist is megtisztítsa, vagy egy adatbázist gyorsabban lehessen megtisztítani. További információkért lásd: kiszolgálókonfiguráció: ADR Tisztább szálak száma.

    Az ADR PVS többszálas verziótisztító monitorozásához egy új kiterjesztett esemény ,tx_mtvc2_sweep_statslett hozzáadva.

Kapcsolódó tartalom

  • Last updated on