Hållbarhet för minnesoptimerade tabeller

Gäller för:SQL Server

In-Memory OLTP ger fullständig hållbarhet för minnesoptimerade tabeller. När en transaktion som har ändrat en minnesoptimerad tabell committar, garanterar SQL Server (på samma sätt som för diskbaserade tabeller) att ändringarna är permanenta, förutsatt att den underliggande lagringen är tillgänglig, så att de överlever en omstart av databasen. Det finns två viktiga komponenter för hållbarhet: transaktionsloggning och sparande dataändringar i disklagring.

Mer information om eventuella storleksbegränsningar för varaktiga tabeller finns i Beräkna minneskrav för Memory-Optimized tabeller.

Transaktionsloggen

Alla ändringar som görs i diskbaserade tabeller eller varaktiga minnesoptimerade tabeller samlas in i en eller flera transaktionsloggposter. När en transaktion bekräftas skriver SQL Server loggposterna som är associerade med transaktionen till disken innan den kommunicerar med programmet eller användarsessionen att transaktionen har bekräftats. Detta garanterar att ändringar som görs av transaktionen är varaktiga. Transaktionsloggen för minnesoptimerade tabeller är helt integrerad med samma loggström som används av diskbaserade tabeller. Med den här integreringen kan befintliga åtgärder för säkerhetskopiering, återställning och återställning av transaktionsloggar fortsätta att fungera utan att det krävs några extra steg. Men eftersom In-Memory OLTP kan öka transaktionsdataflödet för din arbetsbelastning avsevärt kan logg-I/O bli en flaskhals för prestanda. Se till att logg-I/O-undersystemet kan hantera den ökade belastningen för att upprätthålla det ökade dataflödet.

Data- och deltafiler

Data i minnesoptimerade tabeller lagras som fria datarader i en minnesintern heap-datastruktur och länkas via ett eller flera index i minnet. Det finns inga sidstrukturer för datarader, till exempel de som används för diskbaserade tabeller. För långsiktig beständighet och för att tillåta trunkering av transaktionsloggen sparas åtgärder på minnesoptimerade tabeller i en uppsättning data- och deltafiler. Dessa filer genereras baserat på transaktionsloggen med hjälp av en asynkron bakgrundsprocess. Data- och deltafilerna finns i en eller flera containrar (med samma mekanism som används för FILESTREAM-data). Dessa containrar ingår i en minnesoptimerad filgrupp.

Data skrivs till dessa filer på ett strikt sekventiellt sätt, vilket minimerar diskfördröjningen för snurrande media. Du kan använda flera containrar på olika diskar för att distribuera I/O-aktiviteten. Data- och deltafiler i flera containrar på olika diskar ökar databasens återställnings-/återställningsprestanda när data läss från data- och deltafilerna på disken till minnet.

Användartransaktioner har inte direkt åtkomst till data och deltafiler. Alla dataläsningar och skrivningar använder minnesinterna datastrukturer.

Datafilen

En datafil innehåller rader från en eller flera minnesoptimerade tabeller som infogades av flera transaktioner som en del av INSERT- eller UPDATE-åtgärder. En rad kan till exempel komma från den minnesoptimerade tabellen T1 och nästa rad kan komma från den minnesoptimerade tabellen T2. Raderna läggs till i datafilen i ordningen för transaktioner i transaktionsloggen, vilket gör dataåtkomst sekventiell. Detta möjliggör en tiopotens bättre I/O-genomströmning jämfört med slumpmässig I/O.

När datafilen är full lagras raderna som infogas av nya transaktioner i en annan datafil. Med tiden lagras raderna från varaktiga minnesoptimerade tabeller i en av fler datafiler och varje datafil som innehåller rader utgör ett osammanhängande men sammanhängande transaktionsintervall. Till exempel har en datafil med tidsstämpel för transaktionsincheckning i intervallet (100, 200) alla rader som infogats av transaktioner som har tidsstämpel för incheckning större än 100 och mindre än eller lika med 200. Tidsstämpeln för begåendet är ett ständigt ökande tal som tilldelas en transaktion när den är redo att begås. Varje transaktion har en unik tidsstämpel för commit.

När en rad tas bort eller uppdateras tas inte raden bort eller ändras på plats i datafilen, men de borttagna raderna spåras i en annan typ av fil: deltafilen. Uppdateringsåtgärder bearbetas som en tuppel med borttagnings- och insättningsåtgärder för varje rad. Detta eliminerar slumpmässig I/O på datafilen.

Storlek: Varje datafil är ungefär 128 MB stor för datorer med minne som är större än 16 GB och 16 MB för datorer med mindre än eller lika med 16 GB. I SQL Server 2016 (13.x) kan SQL Server använda stort kontrollpunktsläge om det bedömer att lagringsundersystemet är tillräckligt snabbt. I kontrollpunktsläge i stort format har datafilerna en storlek på 1 GB. Detta ger större effektivitet i undersystemet för lagring för arbetsbelastningar med högt dataflöde.

Delta-filen

Varje datafil paras ihop med en deltafil som har samma transaktionsintervall och spårar de borttagna raderna som infogas av transaktioner i transaktionsintervallet. Den här data- och deltafilen kallas för ett kontrollpunktsfilpar (CFP) och är en enhet för både allokering och frigöring samt för sammanslagningsåtgärder. En deltafil som motsvarar transaktionsintervallet (100, 200) lagrar till exempel borttagna rader som infogats av transaktioner i intervallet (100, 200). Precis som datafiler används deltafilen sekventiellt.

När en rad tas bort tas inte raden bort från datafilen, men en referens till raden läggs till i deltafilen som är associerad med transaktionsintervallet där den här dataraden infogades. Eftersom raden som ska tas bort redan finns i datafilen lagrar deltafilen endast referensinformationen {inserting_tx_id, row_id, deleting_tx_id} och den följer transaktionsloggordningen för de ursprungliga borttagnings- eller uppdateringsåtgärderna.

Storlek: Varje deltafil är ungefär till 16 MB för datorer med minne större än 16 GB och 1 MB för datorer med mindre än eller lika med 16 GB. Från och med SQL Server 2016 (13.x) kan SQL Server använda stort kontrollpunktsläge om det bedömer att lagringsundersystemet är tillräckligt snabbt. I stort kontrollpunktsläge är deltafilerna 128 MB stora.

Fylla i data- och deltafiler

Data och deltafil fylls i baserat på de transaktionsloggposter som genereras av bekräftade transaktioner i minnesoptimerade tabeller och lägger till information om infogade och borttagna rader i lämpliga data- och deltafiler. Till skillnad från diskbaserade tabeller där data-/indexsidor töms med slumpmässig I/O när kontrollpunkten är klar är beständigheten i minnesoptimerad tabell kontinuerlig bakgrundsåtgärd. Flera deltafiler nås eftersom en transaktion kan ta bort eller uppdatera vilken rad som helst som infogats av en tidigare transaktion. Borttagningsinformation läggs alltid till i slutet av deltafilen. En transaktion med en incheckningstidsstämpel på 600 infogar till exempel en ny rad och tar bort rader som infogats av transaktioner med en incheckningstidsstämpel på 150, 250 och 450 enligt följande bild. Alla fyra I/O-filoperationer (tre för borttagna rader och en för nyligen infogade rader) utförs som tillägg till de motsvarande delta- och datafilerna.

Komma åt data och deltafiler

Data- och deltafilpar nås när följande händelser inträffar.

Offlinekontrollpunktsarbetare

Den här tråden lägger till in och tar bort till minnesoptimerade datarader, till motsvarande data- och deltafilpar. SQL Server 2014 (12.x) har en offlinekontrollpunktsarbetare. SQL Server 2016 (13.x) och senare versioner har flera kontrollpunktsarbetare.

Sammanslagningsåtgärd

Åtgärden sammanfogar ett eller flera data- och deltafilpar och skapar ett nytt data- och deltafilpar.

Under kraschåterställning

När SQL Server startas om eller databasen är online igen fylls minnesoptimerade data i med hjälp av data- och deltafilparen. Delta-filen fungerar som ett filter för de borttagna raderna när du läser raderna från motsvarande datafil. Eftersom varje data- och deltafilpar är oberoende läses dessa filer in parallellt för att minska den tid det tar att fylla i data i minnet. När data har lästs in i minnet tillämpar In-Memory OLTP-motorn de aktiva transaktionsloggposter som ännu inte omfattas av kontrollpunktsfilerna så att minnesoptimerade data är klara.

Under återställningsåtgärden

De In-Memory OLTP-kontrollpunktsfilerna skapas från databassäkerhetskopian och sedan tillämpas en eller flera säkerhetskopior av transaktionsloggar. Precis som vid kraschåterställning läser In-Memory OLTP-motorn in data i minnet parallellt för att minimera effekten på återställningstiden.

Sammanfoga data och deltafiler

Data för minnesoptimerade tabeller lagras i ett eller flera data- och deltafilpar (kallas även ett kontrollpunktsfilpar eller CFP). Datafiler lagrar infogade rader och deltafiler refererar till borttagna rader. Under körningen av en OLTP-arbetsbelastning, när DML-åtgärderna uppdaterar, infogar och tar bort rader, skapas nya CFP:er för att bevara de nya raderna, och referensen till de borttagna raderna läggs till i deltafiler.

Med hjälp av DML-åtgärder växer antalet data och deltafiler, vilket orsakar ökad diskutrymmesanvändning och ökad återställningstid.

För att förhindra dessa ineffektiviteter sammanfogas de äldre stängda data- och deltafilerna, baserat på en sammanslagningsprincip som beskrivs senare i den här artikeln, så att lagringsmatrisen komprimeras för att representera samma uppsättning data, med ett minskat antal filer.

Sammanslagningsåtgärden tar som indata ett eller flera intilliggande stängda kontrollpunktsfilpar (CFP: er), som är par med data och deltafiler (kallas sammanslagningskälla) baserat på en internt definierad sammanslagningsprincip och ger en resulterande CFP, som kallas sammanslagningsmål. Posterna i varje deltafil i käll-CFP:erna används för att filtrera rader från motsvarande datafil för att ta bort de datarader som inte behövs. De återstående raderna i käll-CFP konsolideras till en mål-CFP. När sammanfogningen är klar ersätter den resulterande CFP:n för sammanslagningsmålet käll-CFP:erna (sammanslagningskällor). CFP:erna från sammanslagningskällan genomgår en övergångsfas innan de tas bort från lagringsenheten.

I följande exempel har den minnesoptimerade tabellfilgruppen fyra data- och deltafilpar vid tidsstämpel 500 som innehåller data från tidigare transaktioner. Till exempel motsvarar raderna i den första datafilen transaktioner med tidsstämpeln större än 100 och mindre än eller lika med 200. alternativt representerad som (100, 200]. De andra och tredje datafilerna visas vara mindre än 50 procent fulla efter att ha redovisat raderna som markerats som borttagna. Sammanslagningsåtgärden kombinerar dessa två CFP:er och skapar en ny cfp som innehåller transaktioner med tidsstämpel som är större än 200 och mindre än eller lika med 400, vilket är det kombinerade intervallet för dessa två CFP:er. Du ser en annan CFP med intervall för (500, 600] och en icke-tom deltafil för transaktionsintervall (200, 400], vilket innebär att sammanslagningsåtgärden kan utföras samtidig med transaktionsaktivitet, inklusive att ta bort fler rader från källans CFP:er.

En bakgrundstråd utvärderar alla stängda CFP:er med hjälp av en sammanslagningsprincip och initierar sedan en eller flera sammanslagningsbegäranden för de kvalificerade CFP:erna. Dessa sammanslagningsbegäranden bearbetas av offline-kontrollpunktstråden. Utvärderingen av sammanslagningsprincipen görs regelbundet och även när en kontrollpunkt stängs.

SQL Server-sammanslagningsprincip

SQL Server implementerar följande sammanslagningsprincip:

• En sammanslagning schemaläggs om två eller flera på varandra följande CFP:er kan konsolideras, efter redovisning av borttagna rader, så att de resulterande raderna får plats i en CFP med målstorlek. Målstorleken för data- och deltafiler motsvarar den ursprungliga storleksändringen enligt beskrivningen tidigare.

• En enskild CFP kan självslås samman om datafilen överskrider dubbla målstorleken och mer än hälften av raderna tas bort. En datafil kan bli större än målstorleken om till exempel en enskild transaktion eller flera samtidiga transaktioner infogar eller uppdaterar en stor mängd data, vilket tvingar datafilen att växa utöver målstorleken, eftersom en transaktion inte kan sträcka sig över flera CFP:er.

Här är några exempel som visar de CFP:er som ska sammanfogas under sammanslagningsprincipen:

Alla CFP:er med tillgängligt utrymme är inte kvalificerade för sammanslagning. Om två angränsande CFP:er till exempel är 60% fulla, kvalificerar de sig inte för sammanslagning och var och en av dessa CFP:er har 40% lagringsutrymme som inte används. I värsta fall är alla CFP:er 50% fulla, en lagringsanvändning på endast 50%. Även om de borttagna raderna kan finnas i lagringen eftersom CFP:erna inte är kvalificerade för sammanslagning, kan de borttagna raderna redan ha tagits bort från minnet av skräpinsamling i minnet. Hanteringen av lagring och minnet är oberoende av skräpinsamling. Lagring som tas av aktiva CFP:er (alla CFP:er uppdateras inte) kan vara upp till två gånger större än storleken på varaktiga tabeller i minnet.

Livscykel för en cfp

CFP:er övergår genom flera stater innan de kan frigöras. Databaskontrollpunkter och loggsäkerhetskopieringar måste ske för att överföra filerna genom faserna och slutligen rensa filer som inte längre behövs. En beskrivning av dessa faser finns i sys.dm_db_xtp_checkpoint_files.

Du kan framtvinga en kontrollpunkt manuellt följt av en loggbackup för att påskynda skräpsamlingen. I produktionsscenarier överför de automatiska kontrollpunkter och loggsäkerhetskopior som ingår i säkerhetskopieringsstrategin sömlöst CFP:er genom dessa faser utan manuella åtgärder. Effekten av skräpinsamlingsprocessen är att databaser med minnesoptimerade tabeller kan ha en större lagringsstorlek jämfört med dess storlek i minnet. Om kontrollpunkts- och loggsäkerhetskopior inte sker fortsätter fotavtrycket på disken för kontrollpunktsfiler att växa.

Relaterat innehåll

• Skapa och hantera lagring för minnesoptimerade objekt