De architectuurhandleiding voor pagina's en omvang

Van toepassing op:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform Systeem (PDW)SQL-database in Microsoft Fabric

Deze handleiding beschrijft de structuur van pagina's en gebieden, en de organisatie van pagina's en gebieden binnen gegevensbestanden.

Een pagina is een fundamentele eenheid van gegevensopslag in de database-engine. De schijfruimte die is toegewezen aan een gegevensbestand (.mdf of .ndf) in een database, wordt logisch verdeeld in pagina's die aaneengesloten zijn van 0 tot n. Schijf-I/O-bewerkingen op gegevensbestanden worden uitgevoerd op paginaniveau. Dat wil gezegd, de database-engine leest of schrijft hele gegevenspagina's.

Een extent is een verzameling van acht fysiek aaneengesloten pagina's, waarmee pagina's efficiënt worden beheerd. Elke pagina behoort tot een gedeelte.

Transactielogboekbestanden (.ldf) bevatten geen pagina's. Ze bevatten een reeks logboekrecords die geen vaste grootte hebben.

Pagina's

In een gewoon boek wordt alle inhoud op pagina's geschreven. Net als bij een boek schrijft de database-engine alle gegevensrijen op pagina's. De grootte van elke pagina is hetzelfde: 8 KiB. In een boek bevatten de meeste pagina's de gegevens of de hoofdinhoud van het boek. Sommige pagina's bevatten metagegevens die de inhoud beschrijven, bijvoorbeeld de inhoudsopgave en de index.

Op dezelfde manier bevatten de meeste pagina's in de database werkelijke rijen met gegevens. Deze worden gegevenspagina's genoemd. Tekst-/ LOB-pagina's bevatten ook gegevens, maar worden alleen gebruikt door grote objectgegevenstypen (LOB). Indexpagina's bevatten indexstructuren waarmee gegevens efficiënt kunnen worden gevonden. Ten slotte worden op verschillende systeempagina's de metagegevens opgeslagen die de organisatie en eigenschappen van de gegevens beschrijven.

In de volgende tabel worden paginatypen beschreven.

Elke pagina begint met een header van 96 bytes die wordt gebruikt om systeeminformatie over de pagina op te slaan. Deze informatie omvat het paginanummer, het paginatype en kan andere metagegevens bevatten, zoals de object-id en de index-id van het object en de index die eigenaar zijn van de pagina.

Aan het einde van de pagina wordt een structuur met de naam slotmatrix opgeslagen. Elk 2-byte-element in de sleufmatrix komt overeen met een rij die op de pagina is opgeslagen. In een sleufmatrixelement wordt de byte-verschuiving van de rij opgeslagen ten opzichte van het begin van de pagina. De database-engine gebruikt deze offsets om rijen op een pagina te zoeken.

Wanneer de database-engine een rij toevoegt aan een lege pagina, wordt de rij direct na de koptekst opgeslagen. Het sleufmatrixelement voor de eerste rij wordt aan het einde van de pagina opgeslagen. Naarmate er meer rijen worden toegevoegd, worden ze één na elkaar opgeslagen vanaf het begin tot het einde van de pagina, terwijl de slotmatrix van het einde tot het begin van de pagina groeit, zoals wordt weergegeven in het volgende diagram.

Wanneer rijen op een pagina na verloop van tijd worden verwijderd of bijgewerkt, kan er ruimte worden weergegeven tussen de resterende rijen. Wanneer er een nieuwe rij wordt toegevoegd, kan deze worden opgeslagen in deze vrije ruimte, als de ruimte voldoende is. Dit betekent dat rijen op een pagina mogelijk niet fysiek in een bepaalde volgorde worden opgeslagen. De database engine onderhoudt echter de sleufarrayvermeldingen in een logische volgorde. Als gevolg hiervan worden rijen op een pagina ook geopend in een logische volgorde, bijvoorbeeld de volgorde die is gedefinieerd door de sleutel van de BTree-index die eigenaar is van de pagina.

Ondersteuning voor grote rijen

Als u grote rijen wilt ondersteunen die niet op één pagina passen, kan het deel van de rij dat niet past, worden opgeslagen op andere pagina's. De maximale grootte van gegevens en overhead die in één rij op een pagina kan worden opgenomen, is 8060 bytes.

De beperking van 8060 bytes is niet van toepassing op de gegevens in de kolommen met behulp van de LOB-gegevenstypen. Voor dergelijke kolommen worden de gegevens standaard opgeslagen in rij als er voldoende ruimte is. Anders bevat de rij een aanwijzer van 16 bytes naar een afzonderlijke structuur met tekst-/LOB-pagina's waarin de LOB-gegevens in een LOB_DATA toewijzingseenheid worden opgeslagen. Met de large value types out of rowtabeloptie wordt dit gedrag bepaald.

De beperking van 8060 bytes is versoepeld voor tabellen en indexen die kolommen met variabele lengte bevatten met behulp van de door de gebruiker gedefinieerde gegevenstypen varchar, nvarchar, varbinary, sql_variant of CLR. Wanneer de totale rijgrootte van alle kolommen met vaste en variabele lengte in een heap of index de limiet van 8.060 bytes overschrijdt, verplaatst de Database Engine dynamisch een of meer kolommen met variabele lengte naar pagina's in een ROW_OVERFLOW_DATA toewijzingseenheid, te beginnen met de breedste kolom.

Dit wordt gedaan wanneer een invoeg- of bijwerkbewerking de totale grootte van de rij groter maakt dan de limiet van 8.060 bytes. Wanneer een kolom wordt verplaatst naar een pagina in een ROW_OVERFLOW_DATA toewijzingseenheid, wordt een 24-byte-aanwijzer op de oorspronkelijke pagina in een IN_ROW_DATA toewijzingseenheid behouden. Als een volgende bewerking de rijgrootte verkleint, worden de kolommen dynamisch verplaatst naar de oorspronkelijke gegevenspagina.

Een tabel kan bijvoorbeeld worden gemaakt met twee kolommen: één varchar(7000) en een andere varchar(2000). Afzonderlijk overschrijdt geen van beide kolommen 8060 bytes, maar gecombineerd zouden ze dit wel doen als de volledige breedte van elke kolom wordt opgevuld. Als dit gebeurt, verplaatst de database-engine dynamisch de kolom met de lengte van de variabele varchar(7000) van de oorspronkelijke pagina naar de pagina's in een ROW_OVERFLOW_DATA toewijzingseenheid.

Wanneer een tabel of index varchar, nvarchar, varbinary, sql_variant of door de gebruiker gedefinieerde CLR-kolommen bevat die meer dan 8.060 bytes per rij kunnen bevatten, moet u rekening houden met het volgende:

• Het dynamisch verplaatsen van grote rijen naar een andere pagina vindt plaats wanneer rijen worden uitgebreid op basis van updatebewerkingen. Bijwerkbewerkingen die rijen verkorten, kunnen ertoe leiden dat ze terug worden verplaatst naar de oorspronkelijke pagina in een IN_ROW_DATA toewijzingseenheid.

  Deze gegevensverplaatsing resulteert in extra schijf-I/O. Queryverwerkingsbewerkingen, zoals sorteringen of joins op grote records die rij-overloopgegevens bevatten, kunnen trager zijn.

  Wanneer u daarom een tabel ontwerpt met meerdere kolommen met varchar, nvarchar, varbinary, sql_variant of door de gebruiker gedefinieerde CLR-typekolommen, moet u rekening houden met het percentage rijen dat waarschijnlijk overloopt en de frequentie waarmee deze overloopgegevens waarschijnlijk worden opgevraagd. Als u tragere prestaties wilt voorkomen, normaliseert u de tabel om sommige van deze kolommen naar een andere tabel te verplaatsen om de kans op het gebruik van rij-overloopopslag te verminderen of te elimineren.

• De lengte van afzonderlijke kolommen moet nog steeds binnen de limiet van 8.000 bytes vallen voor kolommen met varchar, nvarchar, varbinary, sql_variant en door de gebruiker gedefinieerde CLR-typekolommen. Alleen de gecombineerde lengte kan de rijlimiet van 8.060 bytes van een tabel overschrijden.

• De som van de lengten van andere gegevenstypekolommen, bijvoorbeeld char, nchar en int-gegevens, moet nog steeds binnen de limiet van 8060 bytes per rij vallen. Kolommen die gebruikmaken van de LOB-gegevenstypen, zoals varchar(max), nvarchar(max), en varbinary(max) zijn echter vrijgesteld van de rijlimiet van 8.060 bytes.

• De indexsleutel van een geclusterde index kan geen varchar-kolommen bevatten met gegevens in een ROW_OVERFLOW_DATA toewijzingseenheid. Als een geclusterde index wordt gemaakt in een varchar-kolom en alle bestaande gegevens zich in een IN_ROW_DATA toewijzingseenheid bevinden, maar een volgende INSERT of UPDATE instructie de gegevens buiten rij pusht, mislukt de instructie. Zie voor meer informatie de handleiding voor indexarchitectuur en -ontwerp.

• U kunt kolommen opnemen die rij-overloopgegevens bevatten als sleutel- of niet-sleutelkolommen van een niet-geclusterde index.

• De rijgroottelimiet voor tabellen die sparsekolommen gebruiken, is 8018 bytes. Tijdens de conversie tussen sparse- en niet-parseringskolommen wordt fout 576 geretourneerd wanneer de geconverteerde gegevens plus bestaande gegevens groter zijn dan 8018 bytes. Wanneer kolommen worden geconverteerd tussen sparse- en niet-parseringstypen, bewaart de database-engine een kopie van de huidige rijgegevens. Hiermee verdubbelt u tijdelijk de opslag die nodig is voor de rij.

• Gebruik de sys.dm_db_index_physical_stats dynamische beheerfunctie om informatie te verkrijgen over tabellen of indexen die mogelijk rijoverloopgegevens bevatten. Een index of partitie bevat rij-overloopgegevens als de functie rijen retourneert waar de alloc_unit_type_desc kolom zich bevindt ROW_OVERFLOW_DATA en de page_count kolom groter is dan 0.

Mate

Een extent is een verzameling van acht fysiek aaneengesloten pagina's. De grootte van elke extent is 64 KiB.

Er zijn twee soorten extenten:

• Uniforme extents zijn eigendom van één object, bijvoorbeeld een enkele tabel; alle acht pagina's in de extent kunnen alleen worden gebruikt door het object dat eigenaar is.
• Gemengde gebieden worden gedeeld door maximaal acht objecten. Elk van de acht pagina's in de omvang kan eigendom zijn van een ander object.

Tot en met SQL Server 2014 (12.x) wijst de database-engine geen uniforme gebieden toe aan tabellen met kleine hoeveelheden gegevens. Met een nieuwe heap of index worden pagina's uit gemengde extents toegewezen. Wanneer de heap of index zodanig groeit dat er acht pagina's worden gebruikt, schakelt het over naar uniforme extenten voor alle volgende toewijzingen. Als u een index maakt voor een bestaande tabel met voldoende rijen om acht pagina's in de index te genereren, zijn alle toewijzingen aan de index uniform.

Vanaf SQL Server 2016 (13.x) gebruikt de database-engine uniforme gebieden voor toewijzingen in een gebruikersdatabase en in tempdb, met uitzondering van toewijzingen die behoren tot de eerste acht pagina's van een IAM-keten. Toewijzingen in de master, msdben model databases behouden nog steeds het vorige gedrag.

Tot en met SQL Server 2014 (12.x) kunt u traceringsvlag (TF) 1118 gebruiken om de standaardtoewijzing te wijzigen zodat altijd uniforme gebieden worden gebruikt. Zie traceringsvlag 1118 voor meer informatie over deze traceringsvlag.

Vanaf SQL Server 2016 (13.x) heeft TF 1118 geen effect. De eerder door TF 1118 geboden functionaliteit wordt van tevoren automatisch ingeschakeld voor alle gebruikersdatabases en voor tempdb. Voor gebruikersdatabases kan dit gedrag worden beheerd door de MIXED_PAGE_ALLOCATION databaseoptie. De standaardwaarde is OFF, wat betekent dat uniforme gebieden worden gebruikt. Zie OPTIES VOOR ALTER DATABASE SETvoor meer informatie.

Vanaf SQL Server 2012 (11.x) kan de sys.dm_db_database_page_allocations systeemfunctie paginatoewijzingsgegevens rapporteren voor een database, tabel, index en partitie.

Vanaf SQL Server 2019 (15.x) retourneert de sys.dm_db_page_info systeemfunctie informatie over een pagina in een database. De functie retourneert één rij die paginakopgegevens bevat, inclusief de object-id, index-id en partitie-id. In veel gevallen kan deze functie worden gebruikt als een ondersteund alternatief voor de niet-ondersteunde DBCC PAGE opdracht.

Systeempagina’s

Elk gegevensbestand bevat een klein aantal speciale systeempagina's waarmee de metagegevens worden bijgehouden die gebieden en pagina's beschrijven. Systeempagina's houden bijvoorbeeld bij welke gebieden in een gegevensbestand worden toegewezen en hoeveel vrije ruimte pagina's hebben. In deze sectie worden deze systeempagina's beschreven.

GAM- en SGAM-pagina's

De databasemachine maakt gebruik van twee typen toewijzingskaarten voor extenttoewijzing:

• Global Allocation Map (GAM)

  GAM-pagina's registreren de gebieden die zijn toegewezen. Elke GAM-pagina bevat een interval van ongeveer 64.000 gebieden, of ongeveer 4 gigabyte (GiB) aan gegevens, een GAM-interval genoemd. De GAM-pagina heeft 1 bits voor elk gebied in het interval dat wordt behandeld. Als de bit is 1, is de omvang vrij; als de bit is 0, wordt de omvang toegewezen.

• Shared Global Allocation Map (SGAM)

  SGAM-pagina's registreren welke gebieden momenteel worden gebruikt als gemengde gebieden en hebben ook ten minste één ongebruikte pagina. Elke SGAM-pagina bevat ook een interval van ongeveer 64.000 gebieden, of ongeveer 4 GiB aan gegevens. De SGAM heeft 1 bits voor elke mate in het interval dat wordt behandeld. Als de bit is 1, wordt de omvang gebruikt als een gemengde omvang en heeft een gratis pagina. Als de bit 0 is, wordt de extent niet gebruikt als een gemengde extent, of is het een gemengde extent waarin alle pagina's worden gebruikt.

Om samen te vatten, heeft elke extent de volgende bitpatronen ingesteld op de GAM- en SGAM-pagina's, op basis van huidig gebruik.

Voor het beheren van gebieden gebruikt de database-engine de volgende conceptuele algoritmen:

• Als u een uniforme omvang wilt toewijzen, zoekt de database-engine op de GAM-pagina naar een 1 bit en stelt het in op 0.
• Om een gemengde extent met vrije pagina's te vinden, zoekt de Database Engine op de SGAM-pagina naar een 1-bit.
• Om een gemengde omvang toe te wijzen, doorzoekt de database-engine de GAM-pagina naar een 1 bit, stelt het in op 0, en stelt vervolgens ook het bijbehorende bit op de SGAM-pagina in op 1.
• Om een extent vrij te geven, zorgt de database-engine ervoor dat de bit op de GAM-pagina is ingesteld op 1 en de bit op de SGAM-pagina is ingesteld op 0.

Proportionele opvullingstoewijzing

De database-engine wijst gebieden toe van de gebieden die beschikbaar zijn in de bestandsgroep met behulp van een proportioneel vultoewijzingsalgoritme. Als in een bestandsgroep met twee bestanden bijvoorbeeld het dubbele vrije ruimte van het andere bestand is, worden twee pagina's uit dat bestand toegewezen voor elke pagina die uit het andere bestand is toegewezen. Dit betekent dat als toewijzingen doorgaan, alle bestanden in een bestandsgroep eindigen met een vergelijkbaar percentage gebruikte ruimte.

Zie de opvulstrategie voor bestanden en bestandsgroepen voor meer informatie.

PFS-pagina's

Pagina's met vrije ruimte (PFS) registreren de toewijzingsstatus van elke pagina en de hoeveelheid vrije ruimte op elke pagina. Een PFS-pagina heeft 1 byte voor elke pagina die wordt bijgehouden. De byte registreert of de pagina wordt toegewezen, en zo ja, of deze leeg is, 1 tot 50 procent vol, 51 tot 80 procent vol, 81 tot 95 procent vol, of 96 tot 100 procent vol.

Nadat een extent is toegewezen aan een object, gebruikt de database-engine PFS-pagina's om bij te houden welke pagina's in het extent gegevens bevatten of vrij zijn. Deze informatie wordt gebruikt wanneer de database-engine een nieuwe pagina toewijst. De hoeveelheid vrije ruimte op een pagina blijft alleen behouden voor heap- en tekst-/LOB-pagina's. Deze informatie wordt gebruikt wanneer de database-engine een pagina moet vinden met voldoende vrije ruimte die beschikbaar is voor het opslaan van een nieuw ingevoegde rij.

Voor BTree-indexen is geen tracering van vrije ruimte voor pagina's vereist, omdat het punt waarop een nieuwe rij moet worden ingevoegd altijd wordt bepaald door de indexsleutelwaarden. Als een pagina in een BTree-index niet voldoende vrije ruimte heeft, wordt er een nieuwe pagina toegevoegd en wordt ongeveer de helft van de oorspronkelijke paginagegevens naar de nieuwe pagina verplaatst.

Intervallen voor GAM en PFS

Er wordt een nieuwe PFS-, GAM- of SGAM-pagina toegevoegd aan het gegevensbestand voor elk extra bereik dat wordt bijgehouden.

Er is een nieuwe PFS-pagina 8088 pagina's na de eerste PFS-pagina en extra PFS-pagina's in volgende intervallen van 8.088 pagina's. In een gegevensbestand is pagina-id 1 een PFS-pagina, pagina-id 8088 een PFS-pagina, pagina-id 16176 is een PFS-pagina, enzovoort.

Op dezelfde manier zijn er een paar GAM- en SGAM-pagina's, beginnend vanaf respectievelijk pagina's 2 en 3, en herhaalt zich voor elk GAM-interval van ongeveer 64.000 extents of 4 GiB.

Het volgende diagram toont het eerste voorkomen van PFS-, GAM- en SGAM-pagina's aan het begin van een gegevensbestand, na de pagina met de bestandskoptekst. Naarmate het bestand groeit, worden nieuwe PFS-, GAM- en SGAM-pagina's weergegeven met hun respectieve intervallen.

IAM-pagina's

Een IAM-pagina (Index Allocation Map) wijst de gebieden toe die worden gebruikt door een toewijzingseenheid in een GAM-interval. Een toewijzingseenheid is gekoppeld aan een partitie van een heap of index en kan een van de volgende drie typen zijn:

• IN_ROW_DATA

  Bevat niet-LOB-gegevenspagina's of delen van LOB-gegevens die mogelijk in rij passen.

• LOB_DATA

  Bevat LOB-gegevenspagina's, gebruikt door gegevenstypen zoals varchar(max), nvarchar(max), varbinary(max), xml en json.

• ROW_OVERFLOW_DATA

  Bevat LOB-gegevenspagina's die worden gebruikt door gegevenstypen met variabele lengte, zoals varchar, nvarchar, varbinary of sql_variant wanneer de gegevens de limiet voor rijgrootte van 8.060 bytes overschrijden.

Elke partitie van een heap of index bevat altijd ten minste één IN_ROW_DATA toewijzingseenheid. Het kan ook LOB_DATA en ROW_OVERFLOW_DATA toewijzingsunits bevatten, afhankelijk van de gegevenstypen en de rijgroottes die zich in de partitie bevinden.

Net als bij een GAM- of SGAM-pagina heeft een IAM-pagina een interval van 4 GiB in een bestand. Als de toewijzingseenheid gebieden van meer dan één bestand of meer dan één 4 GiB-interval van een bestand bevat, worden meerdere IAM-pagina's gekoppeld in een IAM-keten. Daarom heeft elke toewijzingseenheid ten minste één IAM-pagina voor elke file waarin het extents heeft. Er kunnen ook meer dan één IAM-pagina in een bestand zijn, als het bereik van de gebieden die zijn toegewezen aan de toewijzingseenheid in het bestand het bereik overschrijdt dat één IAM-pagina kan opnemen. Een IAM-pagina in een bestand kan gebieden in dat bestand bijhouden en in elk ander bestand van dezelfde database.

In tegenstelling tot PFS-, GAM- en SGAM-pagina's die met vaste intervallen worden herhaald, worden IAM-pagina's toegewezen zoals vereist voor elke toewijzingseenheid. De sys.system_internals_allocation_units systeemweergave verwijst naar de eerste IAM-pagina voor een toewijzingseenheid. Alle IAM-pagina's voor die toewijzingseenheid zijn gekoppeld in een IAM-keten.

Een IAM-pagina heeft een koptekst die de beginbereiken aangeeft van het bereik van gebieden die door die pagina zijn toegewezen. Een IAM-pagina heeft ook een bitmap waarin elke bit één mate vertegenwoordigt. De eerste bit in de kaart vertegenwoordigt de eerste mate in het bereik, de tweede bit vertegenwoordigt de tweede mate, enzovoort. Als een bit 0 is, wordt het gedeelte dat het vertegenwoordigt niet toegewezen aan de toewijzingseenheid van de IAM-pagina. Als de bit is 1, wordt de omvang ervan toegewezen aan de toewijzingseenheid die eigenaar is van de IAM-pagina.

Wanneer de database-engine een nieuwe rij moet invoegen en er geen ruimte beschikbaar is op de huidige pagina, worden IAM- en PFS-pagina's gebruikt om een pagina te vinden om de rij toe te wijzen. Voor heap of tekst/LOB-pagina's worden ook IAM- en PFS-pagina's gebruikt om een pagina te vinden met voldoende ruimte om de rij op te slaan. De database-engine gebruikt IAM-pagina's om de gebieden te vinden die zijn toegewezen aan de toewijzingseenheid. Voor elk extent wordt in de PFS-pagina's gezocht om te bepalen of er een pagina is die kan worden gebruikt.

Voor BTree-indexen wordt de invoegpositie van een nieuwe rij bepaald door de indexsleutel, maar wanneer een nieuwe pagina nodig is, vindt het eerder beschreven proces plaats.

De database-engine wijst een nieuwe extensie toe aan een toewijzingseenheid wanneer er niet snel een pagina in een bestaande extensie kan worden gevonden met voldoende ruimte om de in te voegen rij te bevatten.

DCM- en BCM-pagina's

De database-engine maakt gebruik van twee typen systeempagina's om gebieden bij te houden die zijn gewijzigd sinds de laatste volledige back-up en gebieden die zijn gewijzigd door bulksgewijze kopieerbewerkingen.

Differential Changed Map (DCM) pagina's versnellen de uitvoering van differentiële back-ups. Bulksgewijs gewijzigde toewijzingen (BCM) versnellen bulkkopiebewerkingen wanneer een database gebruikmaakt van het bulksgewijs vastgelegde herstelmodel. Net als de GAM- en SGAM-pagina's zijn deze structuren bitmaps waarin elke bit één mate vertegenwoordigt.

• DCM-pagina's

  Op deze pagina's worden de gebieden bijgehouden die zijn gewijzigd sinds de laatste volledige databaseback-up. Als de bit van een extent 1 is, is de extent gewijzigd. Als de bit is 0, is de omvang niet gewijzigd.

  Differentiële back-ups lezen de DCM-pagina's om te bepalen welke mate is gewijzigd. Dit vermindert het aantal pagina's dat een differentiële back-up moet lezen en schrijven. De tijd die een differentiële back-up neemt, is evenredig met het aantal gewijzigde gebieden sinds de laatste volledige databaseback-up en niet de totale grootte van de database.

• BCM-pagina's

  Op deze pagina's worden de gebieden bijgehouden die zijn gewijzigd door bulksgewijs vastgelegde bewerkingen sinds de laatste back-up van het transactielogboek. Als de bit van een extent 1 is, is de extent gewijzigd. Als de bit is 0, is de omvang niet gewijzigd.

  Hoewel BCM-pagina's in alle databases worden weergegeven, zijn ze alleen relevant wanneer de database gebruikmaakt van het bulksgewijs vastgelegde herstelmodel. Wanneer in dit herstelmodel een back-up van een transactielogboek wordt uitgevoerd, scant het back-upproces BCM-pagina's op gebieden die zijn gewijzigd. Het omvat deze gebieden in de logboekback-up om herstel mogelijk te maken als de database wordt hersteld vanuit een databaseback-up en een reeks back-ups van transactielogboeken.

  BCM-pagina's zijn niet relevant in een database die gebruikmaakt van het eenvoudige herstelmodel, omdat er geen bulksgewijs vastgelegde bewerkingen volledig zijn vastgelegd. Ze zijn ook niet relevant in een database die gebruikmaakt van het volledige herstelmodel, omdat dat herstelmodel bulksgewijs vastgelegde bewerkingen behandelt als volledig vastgelegde bewerkingen.

De DCM- en BCM-pagina's worden opgeslagen met dezelfde GAM-intervallen van ongeveer 4 GiB als de GAM- en SGAM-pagina's. De DCM- en BCM-pagina's volgen de GAM- en SGAM-pagina's als volgt in een fysiek bestand:

Verwante inhoud

• Basisprincipes van SQL Server I/O
• sys.allocation_units (Transact-SQL)
• Heaps (tabellen zonder geclusterde indexen)
• sys.dm_db_page_info (Transact-SQL)
• Gegevenspagina's lezen in de database-engine
• Pagina's schrijven in de database-engine