Oldalak és mértékek architektú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

A lap az SQL Server adattárolásának alapvető egysége. A terjedelem nyolc, fizikailag összefüggő oldalból álló gyűjtemény. A mértékek segítenek hatékonyan kezelni az oldalakat. Ez az útmutató azokat az adatstruktúrákat ismerteti, amelyek az SQL Server minden verziójában a lapok és a mértékek kezelésére szolgálnak. A lapok és a mértékek architektúrájának megértése fontos a hatékony teljesítményt nyújtó adatbázisok tervezéséhez és fejlesztéséhez.

Oldalak és mértékek

Az SQL Server alapvető adattárolási egysége a lap. 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 oldal szintjén vannak végrehajtva. Ez azt jelzi, hogy az SQL Server egész adatoldalakat olvas vagy ír.

A terjedelmek nyolc fizikailag összefüggő oldalból álló gyűjtemények, amelyek a lapok hatékony kezelésére szolgálnak. Minden oldal kiterjedés szerint van rendezve.

Oldalak

Egy normál könyvben minden tartalom oldalakra van írva. A könyvhöz hasonlóan az SQL Server az összes adatsort a lapokra írja, és az összes adatlap mérete megegyezik: 8 KB. A könyvben a legtöbb oldal tartalmazza az adatokat – a könyv fő tartalmát –, egyes oldalak pedig metaadatokat tartalmaznak a tartalomról (például a tartalomjegyzékről és az indexről). Az SQL Server ismét nem különbözik: a legtöbb oldal tényleges adatsorokat tartalmaz, amelyeket a felhasználók tároltak; ezeket adatoldalaknak és szöveg-/képoldalaknak nevezzük (speciális esetekben). Az indexlapok indexhivatkozásokat tartalmaznak arról, hogy hol találhatók az adatok. Végül vannak olyan rendszeroldalak , amelyek különböző metaadatokat tárolnak az adatok szervezetéről.

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, a szabad terület mennyiségét és a lap tulajdonos objektumának foglalási egységazonosítóját.

Az alábbi táblázat az SQL Server-adatbázis adatfájljaiban használt laptípusokat mutatja be.

Oldal típusa	Tartalom
Adat	Az összes adatot tartalmazó adatsorok, kivéve a szöveget, az ntextet, a képet, az nvarchar(max), a varchar(max), a varbinary(max) és az xml-adatokat , ha a sor szövegének értéke ON.
Index	Indexbejegyzések.
Szöveg/kép	Nagyméretű objektum adattípusok: szöveg, ntext, kép, nvarchar(max), varchar(max), varbinary(max) és xml-adatok . Változó hosszúságú oszlopok, ha az adatsor meghaladja a 8 KB-ot: varchar, nvarchar, varbinary és sql_variant.
Globális foglalási térkép (GAM) Megosztott globális foglalási térkép (SGAM)	Információ arról, hogy a mértékek ki vannak-e foglalva.
Szabad lapterület (PFS)	Információk a lapok lefoglalásáról és a lapokon elérhető szabad területről.
Indexfoglalási térkép (IAM)	Információk a táblák vagy indexek által a foglalási egységenként használt mértékekről.
Tömegesen módosított térkép (BCM)	Információk a tömeges műveletek által a foglalási egységenkénti utolsó BACKUP LOG utasítás óta módosított mértékekről.
Differenciált módosított térkép (DCM)	Információ azokról a mértékekről, amelyek a foglalási egységenkénti utolsó BACKUP DATABASE utasítás óta megváltoztak.

Megjegyzés:

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

Az adatsorok sorosan vannak tárolva az oldalon, közvetlenül a fejléc után. A soreltolás táblázata a lap végén kezdődik, és minden soreltolási táblázat egy bejegyzést tartalmaz az oldal minden sorához. Minden soreltolás bejegyzés tárolja, hogy a sor első bájtja milyen messze van az oldal elejétől. Így a soreltolás tábla funkciója az, hogy segítsen az SQL Servernek a sorok gyors megkeresésében az oldalon. A soreltolás táblázat bejegyzései fordított sorrendben vannak a lap sorainak sorrendjéből.

Nagy sor támogatása

A sorok nem terjedhetnek át az oldalakra; a sor egyes részei azonban áthelyezhetők a sor oldaláról, így a sor nagyon nagy lehet. A lap egyetlen sorában található maximális adat- és többletterhelés 8060 bájt. Ez nem tartalmazza a szöveg/kép oldaltípusában tárolt adatokat.

Ez a korlátozás a varchar, nvarchar, varbinary vagy sql_variant oszlopokat tartalmazó táblák esetében enyhül. Ha egy táblázat összes rögzített és változó oszlopának teljes sormérete meghaladja a 8060 bájtos korlátot, az SQL Server dinamikusan áthelyez egy vagy több változó hosszúságú oszlopot a ROW_OVERFLOW_DATA foglalási egység lapjaira, kezdve a legnagyobb szélességű oszlopmal.

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 a ROW_OVERFLOW_DATA foglalási egység egyik lapjára helyez át, a IN_ROW_DATA foglalási egység eredeti lapján egy 24 bájtos mutató lesz megtartva. Ha egy későbbi művelet csökkenti a sorméretet, az SQL Server dinamikusan áthelyezi az oszlopokat az eredeti adatlapra.

Sortúllépési szempontok

A sorok nem lehetnek több oldalon, és túlcsordulhatnak, ha a változó hosszúságú adattípusú mezők együttes mérete meghaladja a 8060 bájtos korlátot. A szemléltetés érdekében egy táblázat két oszlopból áll: egy varchar(7000) és egy másik varchar (2000). Egyesével egyik oszlop sem haladja meg a 8060 bájtot, de kombinálva ezt megteheti, ha az egyes oszlopok teljes szélessége ki van töltve. Az SQL Server dinamikusan áthelyezheti a varchar(7000) változóhosszúságú oszlopot a ROW_OVERFLOW_DATA foglalási egység lapjaira. Ha a varchar, nvarchar, varbinary vagy sql_variant, illetve a 8060 bájtot meghaladó, felhasználó által definiált CLR típusú oszlopokat egyesít, vegye figyelembe a következőket:

• A nagyméretű rekordok másik lapra történő áthelyezése dinamikusan történik, mivel a rekordok a frissítési műveletek alapján meghosszabbodnak. A rekordokat lerövidítő frissítési műveletek miatt a rekordok visszakerülhetnek az IN_ROW_DATA foglalási egység eredeti lapjára.

  A sorok túlcsordulását tartalmazó nagy rekordok lekérdezése és végrehajtása lelassítja a feldolgozási időt, mivel ezeket a rekordokat aszinkron módon, szinkron módon dolgozzák fel.

  Ezért ha több varchar, nvarchar, varbinary vagy 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. Ha valószínűleg gyakori lekérdezések jelennek meg a sorátfolyási adatok számos sorában, fontolja meg a táblázat normalizálását, hogy egyes oszlopok átkerüljenek egy másik táblába. Ez ezután lekérdezhető egy aszinkron JOIN műveletben.

• Az egyes oszlopok hosszának továbbra is a 8000 bájtos korláton belül kell lennie a varchar, nvarchar, varbinary vagy sql_variant és a 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 összegének, beleértve a karakter- és nchar-adatokat is, a 8060 bájtos sorkorláton belül kell lennie. A nagyméretű objektumadatok szintén mentesülnek a 8060 bájtos sorkorlát alól.

• A fürtözött index indexkulcsa nem tartalmazhat olyan varchar oszlopokat, amelyek a ROW_OVERFLOW_DATA foglalási egységben meglévő adatokkal rendelkeznek. Ha egy varchar oszlopban fürtözött index jön létre, és a meglévő adatok a IN_ROW_DATA foglalási egységben találhatók, a soron kívüli adatokat letöltő oszlop későbbi beszúrási vagy frissítési műveletei sikertelenek lesznek. A foglalási egységekről további információt az SQL Server és az Azure SQL index architektúrájában és tervezési útmutatójában talál.

• A sortúllépési adatokat tartalmazó oszlopokat a nemclustered index kulcs- vagy nem kulcsoszlopaként is felveheti.

• A ritka oszlopokat használó táblák rekordméretkorlátja 8018 bájt. Ha a konvertált adatok és a meglévő rekordadatok száma meghaladja a 8018 bájtot, az MSSQLSERVER 576-os HIBA jelenik meg. Ha az oszlopok ritka és nem elemi típusok között vannak konvertálva, az adatbázismotor megőrzi az aktuális rekordadatok másolatát. Ez ideiglenesen megduplázza a rekordhoz 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.

Mértékben

A mértékek a tér kezelésének alapegységei. A terjedelem nyolc fizikailag összefüggő oldal, azaz 64 KB. Ez azt jelenti, hogy az SQL Server-adatbázisok megabájtonként 16 mértékkel rendelkeznek.

Az SQL Server kétféle terjedelmével rendelkezik:

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

Az SQL Server 2014 -ig (12.x) az adatbázismotor nem foglal le teljes mértékeket kis mennyiségű adatot tartalmazó táblákhoz. Az új táblázat vagy index általában vegyes mértékben foglalja le az oldalakat. Amikor a táblázat vagy az index a nyolcoldalasra nő, akkor a későbbi foglalásokhoz egységes mértékeket használ. 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 kezdve (13.x) a felhasználói adatbázis legtöbb foglalásának alapértelmezett értéke, és tempdb egységes mértékeket használ, kivéve az IAM-lánc első nyolc oldalához tartozó foglalásokat. A , masterés msdb az adatbázisok foglalásai modeltovábbra is megőrzik az előző viselkedést.

Megjegyzés:

Az SQL Serverben, az SQL Server 2014-et (12.x) is beleértve, az 1118-as nyomkövetési jelző (TF) használatával módosíthatja az alapértelmezett kiosztást, hogy mindig egységes mértékeket 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 (13.x) kezdve a TF 1118 által biztosított funkciók automatikusan engedélyezve lesznek az összes felhasználói adatbázishoz tempdb . A felhasználói adatbázisok esetében ezt a viselkedést az SET MIXED_PAGE_ALLOCATION alapértelmezett érték ALTER DATABASEbeállításával OFFszabályozhatja, a TF 1118-nak pedig nincs hatása. További információ: ALTER DATABASE SET beállításai.

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 nincs dokumentálva, és változhat. A kompatibilitás nem garantált.

Az SQL Server 2019 -től (15.x) kezdődően a sys.dm_db_page_info rendszerfüggvény elérhető, és adatokat ad vissza egy adatbázis lapjáról. A függvény egy sort ad vissza, amely tartalmazza a lap fejlécadatait, beleértve a , object_idés index_id.partition_id Ez a függvény a legtöbb esetben felülírja a használat DBCC PAGE szükségességét.

A mértékkiosztások és a szabad terület kezelése

A mértékkiosztásokat és a szabad terület nyomon követését kezelő SQL Server-adatstruktúrák viszonylag egyszerű struktúrával rendelkeznek. Ennek a következő előnyei vannak:

• A szabad hely információi sűrűn vannak tele, ezért viszonylag kevés oldal tartalmazza ezeket az információkat.

  Ez növeli a sebességet a foglalási információk lekéréséhez szükséges lemezolvasások számának csökkentésével. Ez növeli annak az esélyét is, hogy a foglalási lapok a memóriában maradnak, és nem igényelnek további olvasást.

• A foglalási információk többsége nincs összekapcsolva. Ez leegyszerűsíti a foglalási információk karbantartását.

  Az egyes lapok lefoglalása vagy felszabadítása gyorsan elvégezhető. Ez csökkenti a lapok lefoglalására vagy felszabadítására vonatkozó egyidejű tevékenységek közötti versengést.

A mértékkiosztások kezelése

Az SQL Server kétféle foglalási térképet használ a mértékek lefoglalásának rögzítéséhez:

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

  A GAM-lapok rögzítik, hogy milyen mértékben lettek lefoglalva. Minden GAM 64 000 kiterjedésű vagy majdnem 4 gigabájtnyi adatot (GB) fed le. A GAM minden mértékhez 1 bitet tartalmaz a lefedett intervallumban. Ha a bit az 1, a mérték szabad; ha a bit, 0akkor a mértéket a rendszer lefoglalja.

• 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 64 000 kiterjedésű vagy majdnem 4 GB adatra terjed ki. 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ékként használja a rendszer, és az összes lapja használatban van.

Minden mértékhez a következő bitminták vannak beállítva a GAM-ben és az SGAM-ben 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

Ez egyszerű mértékkezelési algoritmusokat okoz.

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

Az adatbázismotor által belsőleg használt algoritmusok kifinomultabbak a cikkben ismertetettnél, mivel az adatbázismotor egyenletesen osztja el az adatokat egy adatbázisban. Azonban még a valódi algoritmusok is egyszerűbbek azáltal, hogy nem kell kezelni a mértékkiosztási információk láncait.

Szabad terület nyomon követése

A lap szabad terület (PFS) oldalai rögzítik az egyes lapok foglalási állapotát, az egyes lapok lefoglalását és az egyes lapok szabad területének mennyiségét. A PFS minden oldalhoz 1 bájttal rendelkezik, rögzítve, hogy a lap ki van-e foglalva, és ha igen, akkor az üres, 1–50 százalékos, 51–80 százalékos, 81–95 százalékos, illetve 96–100 százalékos megtelt.

Miután kiosztott egy mértéket egy objektumhoz, az adatbázismotor a PFS-lapokkal rögzíti, hogy mely oldalak legyenek lefoglalva vagy ingyenesek. Ezt az információt akkor használja a rendszer, ha az adatbázismotornak új lapot kell lefoglalnia. A lap szabad területe csak halom- és szöveg-/képoldalak esetén marad fenn. Akkor használatos, ha az adatbázismotornak olyan lapot kell találnia, amelyen szabad terület áll rendelkezésre egy újonnan beszúrt sor tárolásához. Az indexekhez nincs szükség az oldal szabad területének nyomon követésére, mert az új sor beszúrásának pontját az indexkulcs értékei határozzák meg.

Az adatfájl egy új PFS-, GAM- vagy SGAM-lapot ad hozzá minden olyan további tartományhoz, amelyet nyomon követ. Így az első PFS-oldal után egy új PFS-oldal 8088 oldal, további PFS-oldalak pedig további 8088 oldalintervallumban. Az 1. oldalazonosító egy PFS-lap, a 8088-as lap PFS-lap, az 16176-os lap pedig EGY PFS-lap stb.

Az első GAM-oldal után egy új, 64 000 kiterjedésű GAM-oldal található, amely nyomon követi az azt követő 64 000 terjedelmet; a sorozat 64 000 terjedelemben folytatódik. Hasonlóképpen, az első SGAM-oldal után egy új SGAM-oldal 64 000, további SGAM-oldalak pedig további 64 000 terjedelemben.

Az alábbi ábrán az adatbázismotor által a mértékek lefoglalására és kezelésére használt lapok sorozata látható.

Objektumok által használt terület kezelése

Az indexfoglalási térkép (IAM) oldal leképozza a kiosztási egység által használt adatbázisfájl 4 GB-os részének terjedelmét. A foglalási egység három típus egyike:

• IN_ROW_DATA

  Egy halom vagy index partícióját tárolja.

• LOB_DATA

  Nagy objektum (LOB) adattípusokat tartalmaz, például xml, varbinary(max), varchar(max).

• ROW_OVERFLOW_DATA

  A varchar, nvarchar, varbinary vagy sql_variant oszlopban tárolt változó hosszúságú adatokat tárolja, amelyek túllépik a 8060 bájtos sorméretkorlátot.

Egy halom vagy index minden partíciója legalább egy IN_ROW_DATA foglalási egységet tartalmaz. A halom vagy az index sémájától függően LOB_DATA vagy ROW_OVERFLOW_DATA foglalási egységet is tartalmazhat.

Az IAM-lapok egy fájl 4 GB-os tartományát fedik le, és megegyeznek a GAM- vagy SGAM-oldaléval. Ha a foglalási egység egynél több fájlból vagy egy 4 GB-nál több fájltartományból tartalmaz kiterjedéseket, akkor egy IAM-láncban több IAM-lap lesz összekapcsolva. Ezért minden foglalási egységnek legalább egy IAM-oldala van minden olyan fájlhoz, amelyen kiterjed. A fájlon egynél több IAM-oldal is lehet, ha a kiosztási egységnek lefoglalt fájl kiterjedése meghaladja azt a tartományt, amelyet egy IAM-oldal rögzíthet.

Az IAM-lapok szükség szerint vannak lefoglalva az egyes foglalási egységekhez, és véletlenszerűen találhatók a fájlban. A sys.system_internals_allocation_units rendszernézet a foglalási egység első IAM-oldalára mutat. A foglalási egység összes IAM-lapja egy IAM-láncban van összekapcsolva.

Fontos

A sys.system_internals_allocation_units rendszernézet csak belső használatra készült, é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 IAM-oldal által leképezett terjedelemtartomány kezdő mértékét jelzi. Az IAM-oldal nagy bitképet is rendelkezik, 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, akkor az általa képviselt mérték nem lesz lefoglalva az IAM-et birtokoló foglalási egységhez. 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 nincs szabad terület az aktuális lapon, az IAM- és PFS-lapokat használva megkeresi a lefoglalni kívánt lapot, illetve halom vagy szöveg/kép lap esetén egy olyan lapot, amely elegendő helyet biztosít a sor tárolásához. Az adatbázismotor az IAM-oldalakat használja a foglalási egységhez lefoglalt mértékek megkereséséhez. Az adatbázismotor minden esetben megkeresi a PFS-oldalakat, hogy lássa, van-e használható lap. Minden IAM- és PFS-oldal sok adatoldalt fed le, ezért kevés IAM- és PFS-lap található az adatbázisban. Ez azt jelenti, hogy az IAM- és PFS-lapok általában a memóriában találhatók az SQL Server pufferkészletében, így gyorsan kereshetők. Indexek esetén az új sor beszúrási pontját az indexkulcs állítja be, de ha új lapra van szükség, a korábban leírt folyamat következik be.

Az adatbázismotor csak akkor foglal le új mértéket egy foglalási egységhez, ha nem talál olyan lapot egy meglévő mértékben, amely elegendő helyet biztosít a beszúrt sor tárolásához.

Arányos kitöltési kiosztás

Az adatbázismotor arányos kiosztási algoritmussal lefoglalja a fájlcsoportban elérhető mértékeket. Ugyanabban a két fájlból álló fájlcsoportban, ha az egyik fájl a másikhoz hasonló szabad területtel rendelkezik, két lap lesz lefoglalva a fájlból a másik fájlból lefoglalt minden egyes oldal számára rendelkezésre álló területtel. Ez azt jelenti, hogy egy fájlcsoport minden fájljának a felhasznált területnek hasonló százalékban kell lennie.

Módosított mértékek nyomon követése

Az SQL Server két belső adatstruktúrát használ a tömeges másolási műveletek által módosított mértékek nyomon követésére, valamint a legutóbbi teljes biztonsági mentés óta módosított mértékek nyomon követésére. Ezek az adatstruktúrák jelentősen felgyorsítják a különbségi biztonsági mentéseket. Emellett felgyorsítják a tömeges másolási műveletek naplózását is, amikor 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.

• Differenciált módosított térkép (DCM)

  Ez nyomon követi azokat a mértékeket, amelyek az utolsó BACKUP DATABASE utasítás óta megváltoztak. Ha a mérték bitje az 1, akkor a mérték az utolsó BACKUP DATABASE utasítás óta módosult. Ha a bit az 0, a mértéket nem módosították.

  A különbségi biztonsági másolatok csak a DCM-oldalakat olvassák, hogy megállapítsák, mely mértékek lettek módosítva. Ez jelentősen csökkenti azoknak a lapoknak a számát, amelyeket a különbözeti biztonsági mentésnek be kell vizsgálnia. A különbségi biztonsági mentés futásának időtartama arányos az utolsó BACKUP DATABASE utasítás óta módosított mértékek számával, és nem az adatbázis teljes méretével.

• Tömegesen módosított térkép (BCM)

  Ez nyomon követi azokat a mértékeket, amelyeket a tömegesen naplózott műveletek módosítottak az utolsó BACKUP LOG utasítás óta. Ha egy mérték bitje az 1, a mértéket egy tömegesen naplózott művelet módosította az utolsó BACKUP LOG utasítás után. Ha a bit az 0, akkor a mértéket nem módosították a tömegesen naplózott műveletek.

  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 a BACKUP LOG biztonsági mentési folyamat a módosított mértékben ellenőrzi a BCM-eket. Ezután ezeket a mértékeket is tartalmazza a napló biztonsági mentésében. Ez helyreállítja a tömegesen naplózott műveleteket, ha az adatbázist egy adatbázis biztonsági mentéséből és a tranzakciónaplók biztonsági mentéseinek sorozatából állítja vissza. A BCM-lapok nem relevánsak az egyszerű helyreállítási modellt használó adatbázisokban, mivel a rendszer nem naplózza a tömegesen naplózott műveleteket. Nem relevánsak a teljes helyreállítási modellt használó adatbázisokban, mert a helyreállítási modell a tömegesen naplózott műveleteket teljes naplózott műveletként kezeli.

A DCM-lapok és a BCM-lapok közötti intervallum megegyezik a GAM és az SGAM-oldal közötti intervallummal, 64 000 terjedelemben. A DCM- és BCM-lapok a GAM- és SGAM-lapok mögött találhatók egy fizikai fájlban az alábbiak szerint:

Kapcsolódó tartalom

• Az SQL Server I/O alapjai
• sys.allocation_units (Transact-SQL)
• Halom (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