Lap- és mértékarchitektúra ú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

Ez az útmutató a lapok és a terjedelmek szerkezetét, valamint az adatfájlokban lévő oldalak és mértékek rendszerezését ismerteti.

A lap az adatbázismotor adattárolásának alapvető egysége. Az adatbázis adatfájljaihoz (.mdf vagy .ndf) lefoglalt lemezterület logikailag 0 és n közötti számozott oldalakra van osztva. A lemez I/O-műveletei az adatfájlokon az oldal szintjén lesznek végrehajtva. Ez azt jelzi, hogy az adatbázismotor egész adatoldalakat olvas vagy ír.

Az kiterjedés nyolc fizikailag összefüggő oldalból álló gyűjtemény, amely az oldalak hatékony kezelésére szolgál. Minden oldal egy kiterjesztéshez tartozik.

A tranzakciós naplófájlok (.ldf) nem tartalmaznak oldalakat. Olyan naplórekordok sorozatát tartalmazzák, amelyek mérete nem rögzített.

Oldalak

Egy normál könyvben minden tartalom oldalakra van írva. A könyvhöz hasonlóan az adatbázismotor az összes adatsort oldalakra írja. Minden oldal mérete megegyezik: 8 KiB. A könyvben a legtöbb oldal tartalmazza az adatokat vagy a könyv fő tartalmát. Egyes lapok a tartalmat leíró metaadatokat tartalmaznak, például a tartalomjegyzéket és az indexet.

Hasonlóképpen, az adatbázis legtöbb lapja tényleges adatsorokat tartalmaz. Ezeket adatoldalaknak nevezzük. A szöveg-/LOB-lapok szintén tartalmaznak adatokat, de csak nagy objektumtípusú (LOB) adattípusok használják. Az indexlapok olyan indexszerkezeteket tartalmaznak, amelyek segítenek az adatok hatékony megtalálásában. Végül számos rendszeroldal tárolja az adatok szervezetét és tulajdonságait leíró metaadatokat.

Az alábbi táblázat az oldaltípusokat ismerteti.

Oldal típusa	Tárolt adatok típusa
Adat	Adatsorok az összes adattal. A LOB adattípusokat használó oszlopokban lévő adatok részben adatlapokon is tárolhatók.
Szöveg/LOB	A LOB adattípusokat használó oszlopokban lévő adatok, például szöveg, ntext, kép, varchar(max), nvarchar(max), varbinary(max), xml és json. Változó hosszúságú oszlopokban lévő adatok, ha az adatsor meghaladja a 8 KiB-t, az olyan adattípusokat használó oszlopok esetében, mint a varchar, az nvarchar, a varbinary és a sql_variant.
Index	Btree indexstruktúrák.
Globális kiosztási térkép (GAM) Megosztott globális foglalási térkép (SGAM)	Információk a lefoglalt és a nem lefoglalt kiterjedésekről.
Szabad lapterület (PFS)	Információk a lapok lefoglalásáról és a lapokon elérhető szabad területről.
Index Allokációs Térkép (IAM)	Információ a halom vagy index által egy foglalási egységben használt mértékekről.
Tömegesen módosított térkép (BCM)	Információk a tömeges műveletek által az utolsó tranzakciónapló biztonsági mentése óta módosított mértékekről.
Differenciált módosított térkép (DCM)	A legutóbbi teljes adatbázis biztonsági mentése óta megváltozott mértékekre vonatkozó információk.

Minden oldal egy 96 bájtos fejléccel kezdődik, amely a lap rendszerinformációinak tárolására szolgál. Ezek az információk tartalmazzák az oldalszámot, az oldaltípust, és egyéb metaadatokat is tartalmazhatnak, például az objektumazonosítót, valamint a lap tulajdonos objektumának és indexének indexazonosítóját.

A rendszer az oldal végén tárolja a ponttömb nevű struktúrát. A slot tömb minden két bájtos eleme megfelel az oldalon tárolt sornak. Egy slot tömb elem eltárolja a sor bájt eltolását az oldal elejéhez viszonyítva. Az adatbázismotor ezekkel az eltolásokkal keresi meg a sorokat a lapon.

Amikor az adatbázismotor egy sort ad hozzá egy üres laphoz, az közvetlenül a fejléc után tárolja a sort. Az első sor ponttömbelemét az oldal végén tárolja a rendszer. A további sorok hozzáadásakor a rendszer egymás után tárolja őket az oldal elejétől a végéig, míg a ponttömb a lap végétől az elejéig nő, ahogy az alábbi ábrán is látható.

A lapok sorainak törlése vagy frissítése során előfordulhat, hogy a fennmaradó sorok között szabad terület jelenik meg. Új sor hozzáadásakor előfordulhat, hogy a sor ebben a szabad térben lesz tárolva, ha elegendő a hely. Ez azt jelenti, hogy előfordulhat, hogy egy oldalon lévő sorok fizikailag nem lesznek tárolva egy adott sorrendben. Az adatbázismotor azonban logikai sorrendben tartja a slot tömb bejegyzéseit. Ennek eredményeképpen a lap sorai is logikai sorrendben érhetők el, például a lapot birtokban lévő BTree-index kulcsa által meghatározott sorrendben.

Nagy sor támogatása

Ha olyan nagy sorokat szeretne támogatni, amelyek nem férnek el egyetlen oldalon, a sor nem illeszkedő része más oldalakon is tárolható. A lap egyetlen sorában tárolható adatok és többletterhelések maximális mérete 8060 bájt.

A 8060 bájtos korlátozás nem vonatkozik a LOB adattípusokat használó oszlopok adataira. Az ilyen oszlopok esetében alapértelmezés szerint az adatok sorba vannak tárolva, ha elegendő hely áll rendelkezésre. Ellenkező esetben a sor egy 16 bájtos mutatót tartalmaz egy külön szövegfára/LOB-lapra, amely a LOB-adatokat egy LOB_DATA foglalási egységben tárolja. Ezt a viselkedést a large value types out of rowtáblabeállítás vezérli.

A 8060 bájtos korlátozást enyhítik azon táblák és indexek esetében, amelyek változó hosszúságú oszlopokat tartalmaznak a varchar, nvarchar, varbinary, sql_variant vagy CLR felhasználó által definiált adattípusokkal. Ha egy halom vagy index összes rögzített és változó hosszúságú oszlopának teljes sormérete meghaladja a 8060 bájtos korlátot, az adatbázismotor dinamikusan áthelyez egy vagy több változó hosszúságú oszlopot egy ROW_OVERFLOW_DATA foglalási egység lapjaira a legszélesebb oszloptól kezdve.

Ez akkor történik, ha egy beszúrási vagy frissítési művelet növeli a sor teljes méretét a 8060 bájtos korlátnál. Ha egy oszlopot áthelyeznek egy foglalási egység egy lapjára ROW_OVERFLOW_DATA, az eredeti oldalon egy 24 bájtos mutatót megtartanak a IN_ROW_DATA foglalási egységben. Ha egy későbbi művelet csökkenti a sorméretet, az adatbázismotor dinamikusan áthelyezi az oszlopokat az eredeti adatlapra.

Egy tábla például két oszlopból áll: egy varchar(7000) és egy másik varchar(2000). Egyenként egyik oszlop sem haladja meg a 8060 bájtot, de együttvéve túllépnék a határt, ha az egyes oszlopok teljes szélessége ki lenne töltve. Ha ez történik, az adatbázismotor dinamikusan áthelyezi a varchar(7000) változóhosszúságú oszlopot az eredeti oldalról egy foglalási egység lapjaira ROW_OVERFLOW_DATA .

Ha egy tábla vagy index varchar, nvarchar, varbinary, sql_variant vagy CLR felhasználó által definiált típusú oszlopokat tartalmaz, amelyek száma meghaladja a 8060 bájtot soronként, vegye figyelembe a következőket:

• Az oszlopok másik lapra történő áthelyezése dinamikusan történik, mivel a sorok a frissítési műveletek alapján meghosszabbodnak. Frissítési műveletek, amelyek lerövidítik a sorokat, visszahelyezhetik őket az allokációs IN_ROW_DATA egység eredeti oldalára.

  Ez az adatáthelyezés további lemez I/O-t eredményez. Az olyan lekérdezésfeldolgozási műveletek, mint például a soráttördelési adatokat tartalmazó nagy rekordok rendezései vagy illesztések, lassabbak lehetnek.

  Ezért ha több varchar, nvarchar, varbinary, sql_variant vagy CLR felhasználó által definiált típusú oszlopot tartalmazó táblát tervez, vegye figyelembe a valószínűleg átmenő sorok százalékos arányát és a túlcsordulási adatok lekérésének gyakoriságát. A lassabb teljesítmény elkerülése érdekében normalizálja a táblázatot, hogy az oszlopok egy részét áthelyezhesse egy másik táblába, hogy csökkentse vagy kiküszöbölje a sorszintű túlcsordulásos tárolás használatának valószínűségét.

• Az egyes oszlopok hosszának továbbra is a 8000 bájtos korláton belül kell lennie a varchar, nvarchar, varbinary, sql_variant és CLR felhasználó által definiált típusoszlopok esetében. Csak a kombinált hosszuk haladhatja meg egy tábla 8060 bájtos sorkorlátját.

• Az egyéb adattípusú oszlopok (például char, nchar és int adatok) hosszának továbbra is a 8060 bájtos sorkorláton belül kell lennie. A LOB adattípusokat használó oszlopok, például a varchar(max), az nvarchar(max) és a varbinary(max) azonban mentesülnek a 8060 bájtos sorkorlát alól.

• A fürtözött index indexkulcsa nem tartalmazhat olyan varchar oszlopokat, amelyek egy foglalási ROW_OVERFLOW_DATA egység adataival rendelkeznek. Ha egy varchar oszlopban fürtözött index jön létre, és az összes meglévő adat egy IN_ROW_DATA foglalási egységben található, de egy későbbi INSERT vagy UPDATE utasítás leküldi az adatokat a sorból, az utasítás meghiúsul. További információ: Index architektúra és tervezési útmutató.

• A sor-túllépési adatokat tartalmazó oszlopokat a nem halmozott index kulcs- vagy nem kulcsoszlopként is felveheti.

• A ritka oszlopokat használó táblák sorméretkorlátja 8018 bájt. A ritka és a nem elválasztott oszlopok közötti átalakítás során, ha a konvertált adatok és a meglévő adatok száma meghaladja a 8018 bájtot, az 576-os hiba jelenik meg. Ha az oszlopok ritkák és nem elválasztott típusok között vannak konvertálva, az adatbázismotor megőrzi az aktuális soradatok másolatát. Ez ideiglenesen megduplázza a sorhoz szükséges tárterületet.

• Ha olyan táblákról vagy indexekről szeretne információt szerezni, amelyek sorátfolyási adatokat tartalmazhatnak, használja a sys.dm_db_index_physical_stats dinamikus felügyeleti függvényt. Egy index vagy partíció sorátfolyási adatokat tartalmaz, ha a függvény olyan sorokat ad vissza, ahol az alloc_unit_type_desc oszlop található ROW_OVERFLOW_DATA , az page_count oszlop pedig 0-nál nagyobb.

Kiterjedés

A terjedelem nyolc, fizikailag összefüggő oldalból álló gyűjtemény. Az egyes kiterjedések mérete 64 KiB.

A mértékeknek két típusa van:

• Az egységes mértékek egyetlen objektum, például egyetlen tábla tulajdonában vannak; mind a nyolc oldalt csak a tulajdonos objektum használhatja.
• A vegyes kiterjedéseket legfeljebb nyolc objektum oszthatja meg. A kiterjedés nyolc oldalának mindegyike egy másik objektum tulajdonában lehet.

Az SQL Server 2014 -ig (12.x) az adatbázismotor nem oszt ki egységes mértékeket a kis mennyiségű adatot tartalmazó táblákhoz. Az új halom vagy index a vegyes kiterjedésű oldalakat foglalja le. Amikor a kupac vagy az index arra a pontra nő, hogy nyolc oldalt használ, akkor egységes kiterjedésekre vált az összes további foglaláshoz. Ha olyan indexet hoz létre egy meglévő táblában, amely elegendő sorokkal rendelkezik ahhoz, hogy nyolc oldalt hozzon létre az indexben, az indexhez rendelt összes foglalás egységes mértékben jelenik meg.

Az SQL Server 2016-tól (13.x) kezdődően az adatbázismotor egységes mértékeket használ a felhasználói adatbázisokban és az tempdbIAM-lánc első nyolc oldalához tartozó foglalások kivételével. A master, msdb és model adatbázisok foglalásai továbbra is megtartják az előző viselkedést.

SQL Server 2014-ig (12.x) a nyomkövetési jelző (TF) 1118 segítségével módosíthatja az alapértelmezett lefoglalást, hogy mindig egységes kiterjedéseket használjon. Erről a nyomkövetési jelzőről további információt az 1118-as nyomkövetési jelzőben talál.

Az SQL Server 2016-tól kezdve (13.x) a TF 1118-nak nincs hatása. A TF 1118 által biztosított funkciók automatikusan engedélyezettek minden felhasználói adatbázis és a tempdb számára. A felhasználói adatbázisok esetében ez a viselkedés az MIXED_PAGE_ALLOCATION adatbázis-beállítással szabályozható. Az alapértelmezett érték az OFF, ami azt jelenti, hogy a rendszer egységes mértékeket használ. További információkért lásd ALTER DATABASE SET a beállításokat.

Az SQL Server 2012 -től kezdve (11.x) a sys.dm_db_database_page_allocations rendszerfüggvény képes jelentéskészítést az adatbázis, tábla, index és partíció lapfoglalási adatairól.

Fontos

A sys.dm_db_database_page_allocations rendszerfüggvény nem támogatott, és változhat. A kompatibilitás nem garantált.

Az SQL Server 2019 -től kezdve (15.x) a sys.dm_db_page_info rendszerfüggvény adatokat ad vissza egy adatbázis lapjáról. A függvény egy sort ad vissza, amely oldalfejlécadatokat tartalmaz, beleértve az objektumazonosítót, az indexazonosítót és a partícióazonosítót. Ez a függvény sok esetben a nem támogatott DBCC PAGE parancsok támogatott alternatívaként is használható.

Rendszeroldalak

Minden adatfájl tartalmaz néhány speciális rendszerlapot, amelyek nyomon követik a mértékeket és oldalakat leíró metaadatokat. A rendszerlapok például nyomon követik, hogy az adatfájl mely kiterjesztései vannak lefoglalva, és mennyi szabad hellyel rendelkeznek az oldalak. Ez a szakasz ezeket a rendszerlapokat ismerteti.

GAM- és SGAM-lapok

Az adatbázismotor kétféle foglalási térképet használ a mértékkiosztás rögzítéséhez:

• Globális foglalási térkép (GAM)

  A GAM-lapok rögzítik az allokált kiterjedéseket. Minden GAM-oldal körülbelül 64 000 kiterjedésű vagy körülbelül 4 gigabájtos (GiB) adatintervallumot, úgynevezett GAM-intervallumot fed le. A GAM-oldal minden mértékhez 1 bitet tartalmaz az általa lefedett intervallumban. Ha a bit 1, a kiterjedés szabad; ha a bit 0, a kiterjedés lefoglalt.

• Megosztott globális foglalási térkép (SGAM)

  Az SGAM-lapok rögzítik, hogy jelenleg mely mértékeket használják vegyes terjedelemként, és legalább egy fel nem használt oldallal is rendelkeznek. Minden SGAM-oldal körülbelül 64 000 kiterjedésű vagy körülbelül 4 GiB adatintervallumot is lefed. Az SGAM minden mértékhez 1 bitet tartalmaz a lefedett intervallumban. Ha a bit az 1, akkor a mértéket vegyes mértékként használják, és ingyenes oldallal rendelkezik. Ha a bit az 0, akkor a mértéket nem vegyes mértékként, vagy vegyes mértékben használja a rendszer az összes oldalt.

Összefoglalva, az egyes mértékek a következő bitmintákat állítják be a GAM és az SGAM oldalakon az aktuális használat alapján.

A mérték aktuális használata	GAM-bitbeállítás	SGAM-bitbeállítás
Ingyenes, nincs használatban	1	0
Egységes vagy teljes vegyes kiterjedés	0	0
Vegyes terjedelem ingyenes oldalakkal	0	1

A mértékek kezeléséhez az adatbázismotor a következő fogalmi algoritmusokat használja:

• Az egységes mérték lefoglalásához az adatbázismotor megkeresi a 1 bitet a GAM-oldalon, és beállítja 0-re.
• Ha vegyesen szeretne keresni az ingyenes oldalakkal, az adatbázismotor egy 1 kicsit keres az SGAM-oldalon.
• Vegyes kiterjedés lefoglalásához az adatbázismotor megkeres egy 1 bitet a GAM-oldalon, beállítja azt 0, majd az SGAM-oldalon a megfelelő bitet is beállítja 1.
• A kiterjesztés felszabadításához az adatbázismotor gondoskodik arról, hogy a GAM-lapon a bit értéke 1, az SGAM-lapon pedig a bit értéke 0 legyen.

Kitöltés arányos elosztása

Az adatbázismotor az arányos kitöltési kiosztási algoritmus használatával foglalja le a fájlcsoportban elérhető kiterjedéseket. Ha például egy két fájlból álló fájlcsoportban az egyik fájl a másik szabad területének kétszeresét tartalmazza, a rendszer két lapot foglal le a fájlból a másik fájlból lefoglalt minden egyes oldalhoz. Ez azt jelenti, hogy ha a lefoglalások folytatódnak, a fájlcsoport összes fájlja a felhasznált terület hasonló százalékával végződik.

További információ: Fájl- és fájlcsoportkitöltési stratégia.

PFS-lapok

A lap szabad terület (PFS) oldalai rögzítik az egyes lapok foglalási állapotát és az egyes lapok szabad területének mennyiségét. A PFS-lapok mindegyik nyomon követhető oldalához 1 bájt tartozik. A bájt rögzíti, hogy a lap ki van-e foglalva, és ha igen, akkor hogy üres-e, 1–50 százalékban, 51–80 százalékban, 81–95 százalékban, vagy 96–100 százalékban van megtelve.

Miután kiosztott egy mértéket egy objektumhoz, az adatbázismotor PFS-lapokkal követi nyomon, hogy mely oldalak rendelkeznek adatokkal, vagy melyek ingyenesek. Ezt az információt akkor használja a rendszer, ha az adatbázismotor új lapot foglal le. A lap szabad területe csak halom- és szöveg-/LOB-oldalak esetén marad fenn. Ezt az információt akkor használja a rendszer, ha az adatbázismotornak olyan lapot kell találnia, amelyen elegendő szabad hely áll rendelkezésre az újonnan beszúrt sor tárolásához.

A BTree-indexek nem igényelnek szabad területkövetést, mert az új sor beszúrási pontját mindig az indexkulcs értékei határozzák meg. Ha egy BTree-index egyik lapja nem rendelkezik elegendő szabad területtel, a rendszer új lapot ad hozzá, és az eredeti oldaladatok körülbelül fele átkerül az új lapra.

GAM- és PFS-intervallumok

Az adatfájl egy új PFS-, GAM- vagy SGAM-lapot ad hozzá minden olyan további tartományhoz, amelyet nyomon követ.

Az első PFS-oldal után 8088 oldallal van egy új PFS-oldal, majd további PFS-oldalak következnek 8088 oldalas intervallumokban. Egy adatfájlban az 1. oldalazonosító egy PFS-lap, a 8088-os lap egy PFS-lap, az 16176-os lap pfs-lap stb.

Hasonlóképpen, a 2. és 3. oldaltól kezdve van egy pár GAM- és SGAM-oldal, amelyek minden egyes 64 000 kiterjedésű vagy 4 GiB-os GAM-intervallum esetén ismétlődnek.

Az alábbi ábra a PFS-, GAM- és SGAM-lapok első előfordulását mutatja be egy adatfájl elején, a fájlfejlécet követve. A fájl növekedésével az új PFS-, GAM- és SGAM-lapok a megfelelő időközönként jelennek meg.

IAM-lapok

Az indexlefoglalási térkép (IAM) oldal leképozza a kiosztási egység által használt mértékeket egy GAM-intervallumban. A foglalási egység egy halom vagy index partíciójával van társítva, és a három típus egyike lehet:

• IN_ROW_DATA

  Nem LOB adatoldalakat vagy sorba illeszthető LOB-adatok részeit tárolja.

• LOB_DATA

  LOB adatoldalakat tartalmaz, amelyeket olyan adattípusok használnak, mint a varchar(max), nvarchar(max), varbinary(max), xml és json.

• ROW_OVERFLOW_DATA

  A változó hosszúságú adattípusok( például varchar, nvarchar, varbinary vagy sql_variant ) által használt LOB adatlapokat tartalmazza, ha az adatok túllépik a 8060 bájtos sorméretkorlátot.

Egy halom vagy index minden partíciója mindig tartalmaz legalább egy IN_ROW_DATA foglalási egységet. A partícióban található adattípusoktól és sormérettől függően tartalmazhat LOB_DATA és ROW_OVERFLOW_DATA oszthat ki egységeket is.

A GAM- vagy SGAM-lapokhoz hasonlóan az IAM-lapok egy fájl 4 GiB-intervallumát fedik le. Ha a foglalási egység több fájlból, vagy egy fájl egynél több 4 GiB-intervallumból tartalmaz kiterjedéseket, akkor a rendszer több IAM-lapot csatol egy IAM-láncban. Ezért minden foglalási egység legalább egy IAM oldallal rendelkezik minden olyan fájl esetében, amelynek kiterjedése van. Egy fájlban több IAM-oldal is lehet, ha a fájlban lévő foglalási egységhez lefoglalt mértékek tartománya meghaladja az egyetlen IAM-lap által rögzíthető tartományt. A fájl IAM-oldalai nyomon követhetik az adott fájlban és az adatbázis bármely más fájljában található mértékeket.

A rögzített időközönként ismétlődő PFS-, GAM- és SGAM-oldalaktól eltérően az IAM-oldalakat az egyes foglalási egységekhez szükséges módon kell lefoglalni. A sys.system_internals_allocation_units rendszernézet a foglalási egység első IAM-oldalára mutat. A foglalási egységhez tartozó összes IAM-lap egy IAM-láncban van összekapcsolva.

Fontos

A sys.system_internals_allocation_units rendszernézet nem támogatott, és változhat. A kompatibilitás nem garantált. Ez a nézet nem érhető el az Azure SQL Database-ben.

Az IAM-lapok fejléce az adott oldal által leképezett terjedelemtartomány kezdő mértékét jelzi. Az IAM-lapoknak van egy bitképe is, amelyben minden bit egy-egy mértéket jelöl. A térkép első bitje a tartomány első mértékét, a második bit pedig a második mértéket, és így tovább. Ha egy bit az 0, az általa képviselt tartomány nincs lefoglalva az IAM-oldalt tartalmazó foglalási egység számára. Ha a bit az 1, az általa képviselt mérték az IAM-oldalt birtokoló foglalási egységhez lesz lefoglalva.

Ha az adatbázismotornak új sort kell beszúrnia, és az aktuális lapon nincs szabad terület, IAM- és PFS-oldalakat használ a sor lefoglalásához. Halom- vagy szöveg-/LOB-oldalak esetén az IAM- és PFS-oldalakat hasonlóan használják annak érdekében, hogy megtalálják azt az oldalt, amelynek elegendő helye van a sor tárolására. Az adatbázismotor IAM-oldalakat használ az allokációs egységhez rendelt kiterjedések megkereséséhez. Az egyes mértékek esetében a PFS-oldalakon keres, hogy van-e használható lap.

BTree-indexek esetén az új sor beszúrási pontját az indexkulcs határozza meg, de ha új lapra van szükség, a korábban leírt folyamat következik be.

Az Adatbázis-motor egy új allokációs egységet rendel hozzá egy foglalási egységhez, amikor nem talál gyorsan egy lapot egy meglévő allokációs egységben, amely elegendő helyet tartalmazna a beszúrandó sor számára.

DCM- és BCM-oldalak

Az adatbázismotor kétféle rendszeroldalt használ a legutóbbi teljes biztonsági mentés óta módosított mértékek nyomon követésére, valamint a tömeges másolási műveletek által módosított mértékek nyomon követésére.

A differenciál változási térkép (DCM) lapok felgyorsítják a differenciális biztonsági mentéseket. A tömegesen módosított térkép (BCM) felgyorsítja a tömeges másolási műveleteket, ha egy adatbázis a tömegesen naplózott helyreállítási modellt használja. A GAM- és SGAM-lapokhoz hasonlóan ezek a struktúrák olyan bitképek, amelyekben minden bit egyetlen mértéket jelöl.

• DCM-lapok

  Ezek a lapok nyomon követik a legutóbbi teljes adatbázis biztonsági mentése óta megváltozott kiterjedéseket. Ha egy kiterjesztés bitje 1, akkor a kiterjesztés módosult. Ha a bit az 0, a mértéket nem módosították.

  A különbségi mentések a DCM-oldalakat olvasva megállapítják, hogy mely kiterjedések módosultak. Ez csökkenti azoknak a lapoknak a számát, amelyeket a különbségi biztonsági másolatnak olvasnia és írnia kell. A különbségi biztonsági mentés időtartama arányos a legutóbbi teljes adatbázis biztonsági mentése óta módosított mértékek számával, és nem az adatbázis teljes méretével.

• BCM-oldalak

  Ezek a lapok nyomon követik a tömegesen naplózott műveletek által a legutóbbi tranzakciónapló biztonsági mentése óta módosított mértékeket. Ha egy kiterjesztés bitje 1, akkor a kiterjesztés módosult. Ha a bit az 0, a mértéket nem módosították.

  Bár a BCM-lapok minden adatbázisban megjelennek, csak akkor relevánsak, ha az adatbázis a tömegesen naplózott helyreállítási modellt használja. Ebben a helyreállítási modellben, amikor tranzakciós napló biztonsági mentésére kerül sor, a biztonsági mentési folyamat során megvizsgálja a BCM oldalakat a módosított kiterjesztések tekintetében. Ez magában foglalja a napló biztonsági mentésének azon részeit, amelyek lehetővé teszik a helyreállítást, ha az adatbázist egy adatbázis biztonsági mentéséből és a tranzakciónapló biztonsági mentéseinek sorozatából állítja vissza.

  A BCM-oldalak nem relevánsak az egyszerű helyreállítási modellt használó adatbázisokban, mert a rendszer nem naplózza teljes mértékben a tömeges naplózott műveleteket. A teljes helyreállítási modellt használó adatbázisokban sem relevánsak, mivel a helyreállítási modell a tömegesen naplózott műveleteket teljes naplózott műveletként kezeli.

A DCM- és BCM-oldalak a GAM- és SGAM-oldalakéval megegyező, körülbelül 4 GiB-intervallumban vannak tárolva. A DCM- és BCM-lapok a fizikai fájl GAM- és SGAM-lapjait az alábbiak szerint követik:

Kapcsolódó tartalom

• Az SQL Server I/O alapjai
• sys.allocation_units (Transact-SQL)
• Halomok (fürtözött indexek nélküli táblák)
• sys.dm_db_page_info (Transact-SQL)
• Adatlapok olvasása az adatbázismotorban
• Lapok írása az adatbázismotorban