Arkitekturguide för sidor och omfattningar

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Sidan är den grundläggande datalagringsenheten i SQL Server. En omfattning är en samling med åtta fysiskt sammanhängande sidor. Omfattningar hjälper till att effektivt hantera sidor. Den här guiden beskriver de datastrukturer som används för att hantera sidor och omfattningar i alla versioner av SQL Server. Det är viktigt att förstå arkitekturen för sidor och omfattningar för att utforma och utveckla databaser som presterar effektivt.

Sidor och omfattningar

Den grundläggande datalagringsenheten i SQL Server är sidan. Diskutrymmet som allokeras till en datafil (.mdf eller .ndf) i en databas är logiskt indelat i sidor numrerade sammanhängande från 0 till n. Disk-I/O-åtgärder utförs på sidnivå. Det vill: SQL Server läser eller skriver hela datasidor.

Omfattningar är en samling med åtta fysiskt sammanhängande sidor och används för att effektivt hantera sidorna. Alla sidor är ordnade i omfattningar.

Sidor

I en vanlig bok skrivs allt innehåll på sidor. Precis som i en bok skriver SQL Server alla datarader på sidor och alla datasidor har samma storlek: 8 kB. I en bok innehåller de flesta sidor data – bokens huvudinnehåll – och vissa sidor innehåller metadata om innehållet (till exempel innehållsförteckningen och indexet). Återigen är SQL Server inte annorlunda: de flesta sidor innehåller faktiska rader med data som lagrats av användare; dessa kallas datasidor och text-/bildsidor (för särskilda fall). Indexsidorna innehåller indexreferenser om var data finns. Slutligen finns det systemsidor som lagrar olika metadata om organisationen av data.

Varje sida börjar med en 96-bytesrubrik som används för att lagra systeminformation om sidan. Den här informationen innehåller sidnummer, sidtyp, mängden ledigt utrymme på sidan och allokeringsenhets-ID för objektet som äger sidan.

I följande tabell visas de sidtyper som används i datafilerna i en SQL Server-databas.

Datarader lagras på sidan seriellt, med början direkt efter rubriken. En radförskjutningstabell börjar i slutet av sidan och varje radförskjutningstabell innehåller en post för varje rad på sidan. Varje radförskjutningspost lagrar hur långt den första byte av raden är från början av sidan. Funktionen för radförskjutningstabellen är därför att hjälpa SQL Server att snabbt hitta rader på en sida. Posterna i radförskjutningstabellen är i omvänd ordning från radsekvensen på sidan.

Stöd för stora rader

Rader kan inte sträcka sig över sidor. Delar av raden kan dock flyttas från radens sida, så raden kan vara mycket stor. Den maximala mängden data och omkostnader som finns i en enskild rad på en sida är 8 060 byte. Detta inkluderar inte data som lagras i text-/bildsidans typ.

Den här begränsningen är avslappnad för tabeller som innehåller kolumnerna varchar, nvarchar, varbinary eller sql_variant . När den totala radstorleken för alla fasta kolumner och variabelkolumner i en tabell överskrider begränsningen på 8 060 byte flyttar SQL Server dynamiskt en eller flera kolumner med variabellängd till sidor i ROW_OVERFLOW_DATA allokeringsenhet, med början i kolumnen med den största bredden.

Detta görs när en infognings- eller uppdateringsåtgärd ökar den totala storleken på raden utöver gränsen på 8 060 byte. När en kolumn flyttas till en sida i ROW_OVERFLOW_DATA allokeringsenhet behålls en pekare på 24 byte på den ursprungliga sidan i IN_ROW_DATA allokeringsenhet. Om en efterföljande åtgärd minskar radstorleken flyttar SQL Server kolumnerna dynamiskt tillbaka till den ursprungliga datasidan.

Överväganden för rad-overflow

En rad kan inte finnas på flera sidor och kan spillas över om den kombinerade storleken på datatypen variabel längd överskrider gränsen på 8 060 byte. För att illustrera kan en tabell skapas med två kolumner: ett varchar(7000) och ett annat varchar (2000). Individuellt överskrider ingen kolumn 8 060 byte, men tillsammans kan de göra det om hela bredden för varje kolumn fylls. SQL Server kan dynamiskt flytta variabellängdskolumnen varchar(7000) till sidor i ROW_OVERFLOW_DATA allokeringsenhet. När du kombinerar kolumner av användardefinierad typ av varchar, nvarchar, varbinary eller sql_variant eller CLR som överskrider 8 060 byte per rad bör du tänka på följande:

• Att flytta stora poster till en annan sida sker dynamiskt eftersom poster förlängs baserat på uppdateringsåtgärder. Uppdateringsåtgärder som förkortar poster kan leda till att poster flyttas tillbaka till den ursprungliga sidan i IN_ROW_DATA allokeringsenhet.

  Att köra frågor mot och utföra andra urvalsåtgärder, till exempel sortering eller kopplingar på stora poster som innehåller rad-overflow-data, gör bearbetningstiden långsammare eftersom dessa poster bearbetas synkront i stället för asynkront.

  När du utformar en tabell med flera kolumner av typen varchar, nvarchar, varbinary eller sql_variant eller CLR bör du därför överväga procentandelen rader som sannolikt kommer att flöda över och med vilken frekvens dessa spilldata sannolikt kommer att efterfrågas. Om det sannolikt finns frekventa frågor på många rader med rad-overflow-data bör du överväga att normalisera tabellen så att vissa kolumner flyttas till en annan tabell. Detta kan sedan frågas i en asynkron JOIN åtgärd.

• Längden på enskilda kolumner måste fortfarande ligga inom gränsen på 8 000 byte för kolumner av typen varchar, nvarchar, varbinary eller sql_variant och CLR. Endast deras kombinerade längder kan överskrida radgränsen på 8 060 byte för en tabell.

• Summan av andra datatypskolumner, inklusive tecken - och nchardata , måste ligga inom radgränsen på 8 060 byte. Stora objektdata är också undantagna från radgränsen på 8 060 byte.

• Indexnyckeln för ett grupperat index får inte innehålla varchar-kolumner som har befintliga data i ROW_OVERFLOW_DATA allokeringsenhet. Om ett klustrat index skapas i en varchar-kolumn och befintliga data finns i IN_ROW_DATA allokeringsenhet misslyckas efterföljande infognings- eller uppdateringsåtgärder i kolumnen som skulle skicka data utanför raden. Mer information om allokeringsenheter finns i arkitektur och designguide för SQL Server- och Azure SQL-index.

• Du kan inkludera kolumner som innehåller rad-overflow-data som nyckelkolumner eller icke-nyckelkolumner i ett icke-grupperat index.

• Poststorleksgränsen för tabeller som använder glesa kolumner är 8 018 byte. När konverterade data plus befintliga postdata överskrider 8 018 byte returneras MSSQLSERVER ERROR 576 . När kolumner konverteras mellan glesa och ickesparsa typer behåller databasmotorn en kopia av aktuella postdata. Detta fördubblar tillfälligt den lagring som krävs för posten.

• Om du vill hämta information om tabeller eller index som kan innehålla rad-overflow-data använder du funktionen sys.dm_db_index_physical_stats dynamisk hantering.

Grader

Omfattningar är den grundläggande enhet där utrymme hanteras. En omfattning är åtta fysiskt sammanhängande sidor, eller 64 KB. Det innebär att SQL Server-databaser har 16 omfattningar per megabyte.

SQL Server har två typer av omfattningar:

• Enhetliga omfattningar ägs av ett enskilt objekt. alla åtta sidorna i omfattningen kan endast användas av ägande objektet.
• Blandade omfattningar delas av upp till åtta objekt. Var och en av de åtta sidorna i omfattningen kan ägas av ett annat objekt.

Till och med SQL Server 2014 (12.x) allokerar databasmotorn inte hela omfattningar till tabeller med små mängder data. En ny tabell eller ett nytt index allokerar vanligtvis sidor från blandade omfattningar. När tabellen eller indexet växer till den punkt där det är åtta sidor växlar den sedan till att använda enhetliga omfattningar för efterföljande allokeringar. Om du skapar ett index i en befintlig tabell som har tillräckligt med rader för att generera åtta sidor i indexet är alla allokeringar till indexet i enhetliga omfattningar.

Från och med SQL Server 2016 (13.x) är standardvärdet för de flesta allokeringar i en användardatabas och tempdb att använda enhetliga omfattningar, förutom allokeringar som hör till de första åtta sidorna i en IAM-kedja. Allokeringar för master, msdboch model databaser behåller fortfarande det tidigare beteendet.

Från och med SQL Server 2012 (11.x) sys.dm_db_database_page_allocations kan systemfunktionen rapportera sidallokeringsinformation för en databas, tabell, index och partition.

Från och med SQL Server 2019 (15.x) är den sys.dm_db_page_info systemfunktionen tillgänglig och returnerar information om en sida i en databas. Funktionen returnerar en rad som innehåller rubrikinformationen från sidan, inklusive object_id, index_idoch partition_id. Den här funktionen ersätter behovet av att använda DBCC PAGE i de flesta fall.

Hantera omfattningsallokeringar och ledigt utrymme

SQL Server-datastrukturerna som hanterar omfattningsallokeringar och spårar ledigt utrymme har en relativt enkel struktur. Detta har följande fördelar:

• Informationen om ledigt utrymme är tätt packad, så relativt få sidor innehåller den här informationen.

  Detta ökar hastigheten genom att minska antalet diskläsningar som krävs för att hämta allokeringsinformation. Detta ökar också risken för att allokeringssidorna förblir i minnet och inte kräver fler läsningar.

• Merparten av allokeringsinformationen är inte sammanlänkad. Detta förenklar underhållet av allokeringsinformationen.

  Varje sidallokering eller frigöring kan utföras snabbt. Detta minskar konkurrensen mellan samtidiga uppgifter som måste allokera eller frigöra sidor.

Hantera omfattningsallokeringar

SQL Server använder två typer av allokeringskartor för att registrera allokering av omfattningar:

• Global allokeringskarta (GAM)

  GAM-sidor registrerar vilka omfattningar som har allokerats. Varje GAM täcker 64 000 omfattningar eller nästan 4 GB data. GAM har 1 bit för varje utsträckning i intervallet som den täcker. Om biten är 1är omfattningen kostnadsfri. Om biten är 0allokeras omfattningen.

• Delad global allokeringskarta (SGAM)

  SGAM-sidor registrerar vilka omfattningar som för närvarande används som blandade omfattningar och har också minst en oanvänd sida. Varje SGAM täcker 64 000 omfattningar eller nästan 4 GB data. SGAM har 1 bit för varje utsträckning i det intervall som den täcker. Om biten är 1används omfattningen som en blandad omfattning och har en kostnadsfri sida. Om biten är 0används inte omfattningen som en blandad omfattning, eller så är det en blandad omfattning och alla dess sidor används.

Varje utsträckning har följande bitmönster inställda i GAM och SGAM, baserat på dess aktuella användning.

Detta orsakar enkla algoritmer för hantering av omfattning.

• För att allokera en enhetlig omfattning söker databasmotorn i GAM efter en 1 bit och anger den till 0.
• För att hitta en blandad omfattning med kostnadsfria sidor söker databasmotorn i SGAM efter lite 1 .
• För att allokera en blandad omfattning söker databasmotorn i GAM efter en 1 bit, anger den till 0och anger sedan motsvarande bit i SGAM till 1.
• För att frigöra en omfattning ser databasmotorn till att GAM-biten är inställd på 1och att SGAM-biten är inställd på 0.

De algoritmer som används internt av databasmotorn är mer avancerade än vad som beskrivs i den här artikeln, eftersom databasmotorn distribuerar data jämnt i en databas. Men även de verkliga algoritmerna förenklas genom att man inte behöver hantera kedjor med information om omfattningsallokering.

Spåra ledigt utrymme

Pfs-sidor (Sidfritt utrymme) registrerar allokeringsstatusen för varje sida, om en enskild sida har allokerats och mängden ledigt utrymme på varje sida. PFS har 1 byte för varje sida, som registrerar om sidan är allokerad, och i så fall om den är tom, 1 till 50 procent full, 51 till 80 procent full, 81 till 95 procent full eller 96 till 100 procent full.

När en omfattning har allokerats till ett objekt använder databasmotorn PFS-sidorna för att registrera vilka sidor i omfattningen som är allokerade eller kostnadsfria. Den här informationen används när databasmotorn måste allokera en ny sida. Mängden ledigt utrymme på en sida behålls endast för heap- och text-/bildsidor. Den används när databasmotorn måste hitta en sida med ledigt utrymme för att lagra en rad som nyligen infogats. Index kräver inte att sidutrymmet spåras eftersom den punkt där en ny rad ska infogas anges av indexnyckelvärdena.

En ny PFS-, GAM- eller SGAM-sida läggs till i datafilen för varje ytterligare intervall som den håller reda på. Det finns alltså en ny PFS-sida på 8 088 sidor efter den första PFS-sidan och ytterligare PFS-sidor i efterföljande 8 088 sidintervall. För att illustrera är sid-ID 1 en PFS-sida, sid-ID 8088 är en PFS-sida, sid-ID 16176 är en PFS-sida och så vidare.

Det finns en ny GAM-sida med 64 000 omfattningar efter den första GAM-sidan och den håller reda på de 64 000 omfattningar som följer den. sekvensen fortsätter med 64 000 intervall. På samma sätt finns det en ny SGAM-sida 64 000 omfattningar efter den första SGAM-sidan och ytterligare SGAM-sidor i efterföljande 64 000 utsträckningsintervall.

Följande bild visar sekvensen med sidor som används av databasmotorn för att allokera och hantera omfattningar.

Hantera utrymme som används av objekt

En IAM-sida (Index Allocation Map) mappar omfattningen i en 4 GB del av en databasfil som används av en allokeringsenhet. En allokeringsenhet är en av tre typer:

• IN_ROW_DATA

  Innehåller en partition av en heap eller ett index.

• LOB_DATA

  Innehåller datatyper för stora objekt (LOB), till exempel xml, varbinary(max)och varchar(max).)

• ROW_OVERFLOW_DATA

  Innehåller variabellängdsdata som lagras i kolumnerna varchar, nvarchar, varbinary eller sql_variant som överskrider radstorleksgränsen på 8 060 byte.

Varje partition av en heap eller ett index innehåller minst en IN_ROW_DATA allokeringsenhet. Den kan också innehålla en LOB_DATA eller ROW_OVERFLOW_DATA allokeringsenhet, beroende på heap- eller indexschemat.

En IAM-sida täcker ett intervall på 4 GB i en fil och har samma täckning som en GAM- eller SGAM-sida. Om allokeringsenheten innehåller omfattningar från mer än en fil, eller mer än ett 4 GB intervall av en fil, kommer det att finnas flera IAM-sidor länkade i en IAM-kedja. Därför har varje allokeringsenhet minst en IAM-sida för varje fil där den har omfattningar. Det kan också finnas mer än en IAM-sida i en fil, om omfattningen på filen som allokerats till allokeringsenheten överskrider det intervall som en enda IAM-sida kan registrera.

IAM-sidor allokeras efter behov för varje allokeringsenhet och finns slumpmässigt i filen. Systemvyn sys.system_internals_allocation_units pekar på den första IAM-sidan för en allokeringsenhet. Alla IAM-sidor för allokeringsenheten är länkade i en IAM-kedja.

En IAM-sida har en rubrik som anger startomfånget för det intervall av omfattningar som mappas av IAM-sidan. IAM-sidan har också en stor bitmapp där varje bit representerar en omfattning. Den första biten på kartan representerar den första omfattningen i intervallet, den andra biten representerar den andra omfattningen och så vidare. Om en bit är 0allokeras inte omfattningen som den representerar till allokeringsenheten som äger IAM. Om biten är 1allokeras den omfattning den representerar till allokeringsenheten som äger IAM-sidan.

När databasmotorn måste infoga en ny rad och inget utrymme är tillgängligt på den aktuella sidan, använder den IAM- och PFS-sidorna för att hitta en sida att allokera, eller, för en heap eller en text-/bildsida, en sida med tillräckligt med utrymme för att hålla raden. Databasmotorn använder IAM-sidorna för att hitta de omfattningar som allokerats till allokeringsenheten. För varje utsträckning söker databasmotorn på PFS-sidorna för att se om det finns en sida som kan användas. Varje IAM- och PFS-sida omfattar många datasidor, så det finns få IAM- och PFS-sidor i en databas. Det innebär att IAM- och PFS-sidorna vanligtvis finns i minnet i SQL Server-buffertpoolen, så att de kan sökas snabbt. För index anges insättningspunkten för en ny rad av indexnyckeln, men när en ny sida behövs sker den tidigare beskrivna processen.

Databasmotorn allokerar en ny omfattning till en allokeringsenhet endast när den inte snabbt kan hitta en sida i befintlig utsträckning med tillräckligt med utrymme för att hålla raden infogad.

Proportionell fyllningsallokering

Databasmotorn allokerar omfattningar från de som är tillgängliga i filgruppen med hjälp av en proportionell fyllningsallokeringsalgoritm . Om den ena filen har dubbelt så ledigt utrymme som den andra i samma filgrupp med två filer allokeras två sidor från filen med det tillgängliga utrymmet för varje sida som allokeras från den andra filen. Det innebär att varje fil i en filgrupp bör ha en liknande procentandel utrymme som används.

Spåra ändrade omfattningar

SQL Server använder två interna datastrukturer för att spåra omfattningar som ändrats av masskopieringsåtgärder och omfattningar som ändrats sedan den senaste fullständiga säkerhetskopieringen. Dessa datastrukturer påskyndar kraftigt differentiella säkerhetskopieringar. De påskyndar också loggningen av masskopieringsåtgärder när en databas använder den massloggade återställningsmodellen. Precis som GAM- och SGAM-sidorna är dessa strukturer bitmappar där varje bit representerar en enda omfattning.

• Differentiell ändrad karta (DCM)

  Detta spårar de omfattningar som har ändrats sedan den senaste BACKUP DATABASE instruktionen. Om biten för en omfattning är 1har omfattningen ändrats sedan den senaste BACKUP DATABASE instruktionen. Om biten är 0har omfattningen inte ändrats.

  Differentiella säkerhetskopior läser bara DCM-sidorna för att avgöra vilka omfattningar som har ändrats. Detta minskar avsevärt antalet sidor som en differentiell säkerhetskopia måste genomsöka. Hur lång tid en differentiell säkerhetskopiering körs är proportionell mot det antal omfattningar som ändrats sedan den senaste BACKUP DATABASE instruktionen och inte databasens totala storlek.

• Mass ändrad karta (BCM)

  Detta spårar de omfattningar som har ändrats av massloggade åtgärder sedan den senaste BACKUP LOG instruktionen. Om biten för en omfattning är 1har omfattningen ändrats av en massloggad åtgärd efter den senaste BACKUP LOG instruktionen. Om biten är 0har omfattningen inte ändrats av massloggade åtgärder.

  Även om BCM-sidor visas i alla databaser är de bara relevanta när databasen använder den massloggade återställningsmodellen. I den här återställningsmodellen, när en BACKUP LOG utförs, genomsöker säkerhetskopieringsprocessen BCM:erna efter omfattningar som har ändrats. Den innehåller sedan dessa omfattningar i loggsäkerhetskopian. Detta återställer de massloggade åtgärderna om databasen återställs från en databassäkerhetskopia och en sekvens av säkerhetskopior av transaktionsloggar. BCM-sidor är inte relevanta i en databas som använder den enkla återställningsmodellen eftersom inga massloggade åtgärder loggas. De är inte relevanta i en databas som använder den fullständiga återställningsmodellen, eftersom den återställningsmodellen behandlar massloggade åtgärder som fullständigt loggade åtgärder.

Intervallet mellan DCM-sidor och BCM-sidor är detsamma som intervallet mellan GAM- och SGAM-sidan, 64 000 omfattningar. DCM- och BCM-sidorna finns bakom GAM- och SGAM-sidorna i en fysisk fil enligt följande:

Relaterat innehåll

• Grunderna i SQL Server I/O
• sys.allocation_units (Transact-SQL)
• Heaps (tabeller utan klustrade index)
• sys.dm_db_page_info (Transact-SQL)
• Läsa datasidor i databasmotorn
• Skriva sidor i databasmotorn