Duurzaamheid voor tabellen die zijn geoptimaliseerd voor geheugen

Van toepassing op:SQL Server

In-Memory OLTP biedt volledige duurzaamheid voor tabellen die zijn geoptimaliseerd voor geheugen. Wanneer een transactie die een door geheugen geoptimaliseerde tabel heeft gewijzigd, wordt gecommitteerd, zorgt SQL Server (net als bij op schijf gebaseerde tabellen) ervoor dat de wijzigingen permanent zijn (ze een herstart van de database overleven), tenzij de onderliggende opslag beschikbaar is. Er zijn twee belangrijke onderdelen van duurzaamheid: transactielogboekregistratie en persistente gegevenswijzigingen in opslag op schijf.

Zie Schatting van geheugenvereisten voor geheugen-geoptimaliseerde tabellen voor meer informatie over de groottebeperkingen voor duurzame tabellen.

Transactielogboek

Alle wijzigingen die zijn aangebracht in tabellen op schijf of duurzame tabellen die zijn geoptimaliseerd voor geheugen, worden vastgelegd in een of meer transactielogboekrecords. Wanneer een transactie doorvoert, schrijft SQL Server de logboekrecords die zijn gekoppeld aan de transactie naar de schijf voordat deze communiceert met de toepassing of gebruikerssessie die de transactie heeft doorgevoerd. Dit garandeert dat wijzigingen die door de transactie zijn aangebracht, duurzaam zijn. Het transactielogboek voor tabellen die zijn geoptimaliseerd voor geheugen is volledig geïntegreerd met dezelfde logboekstroom die wordt gebruikt door tabellen op basis van schijven. Met deze integratie kunnen bestaande transactielogboekback-upbewerkingen, herstelbewerkingen en herstelbewerkingen blijven werken zonder dat er extra stappen nodig zijn. Omdat In-Memory OLTP echter de transactiedoorvoer van uw workload aanzienlijk kan verhogen, kan logboek-IO een knelpunt voor prestaties worden. Om deze verhoogde doorvoer te ondersteunen, moet u ervoor zorgen dat het IO-subsysteem voor logboeken de verhoogde belasting kan verwerken.

Gegevens- en deltabestanden

De gegevens in tabellen die zijn geoptimaliseerd voor geheugen, worden opgeslagen als vrije gegevensrijen in een heap-gegevensstructuur in het geheugen en worden gekoppeld via een of meer indexen in het geheugen. Er zijn geen paginastructuren voor gegevensrijen, zoals de rijen die worden gebruikt voor tabellen op basis van schijven. Voor persistentie op lange termijn en om afkapping van het transactielogboek mogelijk te maken, worden bewerkingen op tabellen die zijn geoptimaliseerd voor geheugen, bewaard in een set gegevens- en deltabestanden. Deze bestanden worden gegenereerd op basis van het transactielogboek, met behulp van een asynchroon achtergrondproces. De gegevens- en deltabestanden bevinden zich in een of meer containers (met hetzelfde mechanisme dat wordt gebruikt voor FILESTREAM-gegevens). Deze containers maken deel uit van een voor geheugen geoptimaliseerde bestandsgroep.

Gegevens worden op een strikt sequentiële manier naar deze bestanden geschreven, waardoor de schijflatentie voor draaiende media wordt geminimaliseerd. U kunt meerdere containers op verschillende schijven gebruiken om de I/O-activiteit te distribueren. Gegevens- en deltabestanden in meerdere containers op verschillende schijven verhogen de prestaties van databaseherstel/herstel wanneer gegevens worden gelezen uit de gegevens- en deltabestanden op schijf, in het geheugen.

Gebruikerstransacties hebben niet rechtstreeks toegang tot gegevens en deltabestanden. Alle gegevens lezen en schrijven maken gebruik van in-memory gegevensstructuren.

Het gegevensbestand

Een gegevensbestand bevat rijen uit een of meer tabellen die zijn geoptimaliseerd voor geheugen die door meerdere transacties zijn ingevoegd als onderdeel van INSERT- of UPDATE-bewerkingen. Eén rij kan bijvoorbeeld afkomstig zijn van tabel T1 die is geoptimaliseerd voor geheugen en de volgende rij kan afkomstig zijn van tabel T2 die is geoptimaliseerd voor geheugen. De rijen worden toegevoegd aan het gegevensbestand in de volgorde van transacties in het transactielogboek, waardoor gegevenstoegang sequentieel wordt. Dit maakt een hogere I/O-doorvoer in vergelijking met willekeurige I/O mogelijk.

Zodra het gegevensbestand vol is, worden de rijen die door nieuwe transacties worden ingevoegd, opgeslagen in een ander gegevensbestand. In de loop van de tijd worden de rijen uit duurzaam geoptimaliseerde tabellen opgeslagen in een van meer gegevensbestanden en elk gegevensbestand met rijen vormen een niet-aaneengesloten maar aaneengesloten reeks transacties. Een gegevensbestand met een tijdstempel voor transactiedoorvoer in het bereik van (100, 200) bevat bijvoorbeeld alle rijen die zijn ingevoegd door transacties met een doorvoertijdstempel van meer dan 100 en kleiner dan of gelijk aan 200. De tijdstempel voor doorvoeren is een monotonisch toenemend getal dat aan een transactie is toegewezen wanneer deze klaar is om door te voeren. Elke transactie heeft een unieke tijdstempel voor doorvoeren.

Wanneer een rij wordt verwijderd of bijgewerkt, wordt de rij niet verwijderd of gewijzigd in het gegevensbestand, maar worden de verwijderde rijen bijgehouden in een ander type bestand: het Delta-bestand. Updatebewerkingen worden verwerkt als een tupel van verwijder- en invoegbewerkingen voor elke rij. Dit elimineert willekeurige IO in het gegevensbestand.

Grootte: Elk gegevensbestand is ongeveer 128 MB groot voor computers met geheugen groter dan 16 GB en 16 MB voor computers met minder dan of gelijk aan 16 GB. In SQL Server 2016 (13.x) kan SQL Server grote controlepuntmodus gebruiken als het opslagsubsysteem snel genoeg is. In de grote controlepuntmodus hebben gegevensbestanden een grootte van 1 GB. Dit maakt een grotere efficiëntie mogelijk in het opslagsubsysteem voor workloads met hoge doorvoer.

Het deltabestand

Elk gegevensbestand wordt gekoppeld aan een deltabestand met hetzelfde transactiebereik en houdt de verwijderde rijen bij die zijn ingevoegd door transacties in het transactiebereik. Dit gegevens- en deltabestand wordt aangeduid als een Controlepuntbestandspaar (GVB) en het is de toewijzings- en deallocatie-eenheid, evenals de eenheid voor samenvoegbewerkingen. Een deltabestand dat overeenkomt met het transactiebereik (100, 200) slaat bijvoorbeeld verwijderde rijen op die zijn ingevoegd door transacties in het bereik (100, 200). Net als bij gegevensbestanden wordt het deltabestand opeenvolgend geopend.

Wanneer een rij wordt verwijderd, wordt de rij niet verwijderd uit het gegevensbestand, maar wordt een verwijzing naar de rij toegevoegd aan het deltabestand dat is gekoppeld aan het transactiebereik waarin deze gegevensrij is ingevoegd. Omdat de rij die moet worden verwijderd al bestaat in het gegevensbestand, slaat het Delta-bestand alleen de referentiegegevens {inserting_tx_id, row_id, deleting_tx_id} op en volgt deze de transactionele logboekvolgorde van de oorspronkelijke verwijderings- of updatebewerkingen.

Grootte: Elk deltabestand is ongeveer 16 MB groot voor computers met geheugen groter dan 16 GB en 1 MB voor computers met minder dan of gelijk aan 16 GB. Vanaf SQL Server 2016 (13.x) kan SQL Server grote controlepuntmodus gebruiken als het opslagsubsysteem snel genoeg is. In de grote controlepuntmodus hebben deltabestanden een grootte van 128 MB.

Gegevens- en deltabestanden vullen

Gegevens- en deltabestanden worden ingevuld op basis van de transactielogboekrecords die worden gegenereerd door vastgelegde transacties in tabellen die zijn geoptimaliseerd voor geheugen en voegt informatie over de ingevoegde en verwijderde rijen toe aan de juiste gegevens- en deltabestanden. In tegenstelling tot schijftabellen waarbij gegevens-/indexpagina's worden leeggemaakt met willekeurige I/O wanneer het controlepunt wordt uitgevoerd, is de persistentie van voor geheugen geoptimaliseerde tabel continue achtergrondbewerking. Er worden meerdere deltabestanden geopend omdat een transactie elke rij kan verwijderen of bijwerken die is ingevoegd door een eerdere transactie. Verwijderingsgegevens worden altijd aan het einde van het deltabestand toegevoegd. Met een transactie met een tijdstempel voor doorvoeren van 600 wordt bijvoorbeeld één nieuwe rij ingevoegd en worden rijen verwijderd die zijn ingevoegd door transacties met een tijdstempel voor doorvoeren van 150, 250 en 450, zoals wordt weergegeven in de volgende afbeelding. Alle vier de I/O-bewerkingen (drie voor verwijderde rijen en 1 voor de nieuw ingevoegde rijen) zijn bewerkingen die alleen worden toegevoegd aan de bijbehorende delta- en gegevensbestanden.

Toegang tot gegevens- en deltabestanden

Gegevens- en deltabestandparen worden geopend wanneer de volgende gebeurtenissen plaatsvinden.

Offline controlepuntmedewerkers

Met deze thread worden invoegingen en verwijderingen uitgevoerd op geheugen-geoptimaliseerde gegevensrijen, aan de overeenkomende gegevens- en deltadateiparen. SQL Server 2014 (12.x) heeft één offline controlepuntwerker. SQL Server 2016 (13.x) en latere versies hebben meerdere controlepuntwerkrollen.

Samenvoegbewerking

Met de bewerking worden een of meer gegevens- en deltabestandsparen samengevoegd en wordt een nieuw gegevens- en deltabestandspaar gemaakt.

Tijdens crashherstel

Wanneer SQL Server opnieuw wordt opgestart of de database weer online wordt gebracht, worden de voor het geheugen geoptimaliseerde gegevens gevuld met behulp van de gegevens- en deltabestandsparen. Het deltabestand fungeert als een filter voor de verwijderde rijen bij het lezen van de rijen uit het bijbehorende gegevensbestand. Omdat elk gegevens- en deltabestandspaar onafhankelijk is, worden deze bestanden parallel geladen om de tijd te verkorten die nodig is om gegevens in het geheugen in te vullen. Zodra de gegevens in het geheugen zijn geladen, past de In-Memory OLTP-engine de actieve transactielogboekrecords toe die nog niet worden gedekt door de controlepuntbestanden, zodat de voor geheugen geoptimaliseerde gegevens zijn voltooid.

Tijdens de herstelbewerking

De In-Memory OLTP-controlepuntbestanden worden gemaakt op basis van de databaseback-up en vervolgens worden een of meer back-ups van transactielogboeken toegepast. Net als bij crashherstel laadt de In-Memory OLTP-engine gegevens parallel in het geheugen om het effect op de hersteltijd te minimaliseren.

Gegevens en deltabestanden samenvoegen

De gegevens voor tabellen die zijn geoptimaliseerd voor geheugen worden opgeslagen in een of meer gegevens- en deltabestandsparen (ook wel een controlepuntbestandpaar of GVB genoemd). Gegevensbestanden slaan ingevoegde rijen en deltabestanden verwijzen naar verwijderde rijen. Tijdens de uitvoering van een OLTP-workload worden, wanneer de DML-bewerkingen rijen bijwerken, invoegen en verwijderen, nieuwe CFP's gemaakt om de nieuwe rijen te behouden. De verwijzing naar de verwijderde rijen wordt toegevoegd aan delta files.

In de loop van de tijd, met DML-bewerkingen, wordt het aantal gegevens- en deltabestanden groter, waardoor het schijfruimtegebruik toeneemt en de hersteltijd is toegenomen.

Om deze inefficiënties te voorkomen, worden de oudere gesloten gegevens- en deltabestanden samengevoegd op basis van een samenvoegbeleid dat verderop in dit artikel wordt beschreven, zodat de opslagmatrix wordt gecomprimeerd om dezelfde set gegevens weer te geven, met een verminderd aantal bestanden.

De merge-operatie neemt als invoer een of meer aangrenzende gesloten controlepuntbestandparen (CFP's), die paren van gegevens- en deltabestanden (samenvoegbron genoemd) zijn, gebaseerd op een intern gedefinieerd samenvoegbeleid, en produceert één resulterend CFP, het zogenaamde samenvoegdoel. De vermeldingen in elk deltabestand van de bron-CFP's worden gebruikt om rijen uit het bijbehorende gegevensbestand te filteren om de gegevensrijen te verwijderen die niet nodig zijn. De resterende rijen in de bron-CFP's worden samengevoegd tot één doel-CFP. Nadat de samenvoeging is voltooid, vervangt de resulterende doel-CFP na samenvoeging de bron-CFP's (samenvoegbronnen). De CFP's van de samenvoegbron doorlopen een overgangsfase voordat ze uit de opslag worden verwijderd.

In het volgende voorbeeld bevat de tabelbestandsgroep die is geoptimaliseerd voor geheugen vier gegevens- en deltabestandparen bij tijdstempel 500 met gegevens uit eerdere transacties. De rijen in het eerste gegevensbestand komen bijvoorbeeld overeen met transacties met een tijdstempel groter dan 100 en kleiner dan of gelijk aan 200; alternatief weergegeven als (100, 200]. Uit berekeningen waarbij rekening wordt gehouden met de als verwijderd gemarkeerde rijen, blijken het tweede en derde gegevensbestand voor minder dan 50 procent gevuld te zijn. De samenvoegbewerking combineert deze twee CFP's en maakt een nieuwe CFP met transacties met een tijdstempel groter dan 200 en kleiner dan of gelijk aan 400, wat het gecombineerde bereik is van deze twee CFP's. U ziet een andere CFP met bereik (500, 600] en een niet-leeg deltabestand voor transactiebereik (200, 400]. Dit laat zien dat de samenvoegbewerking gelijktijdig kan worden uitgevoerd met transactionele activiteiten, waaronder het verwijderen van meer rijen uit de bron-CFP's.

Een achtergrondthread evalueert alle gesloten CFP's met behulp van een samenvoegbeleid en initieert vervolgens een of meer samenvoegaanvragen voor de in aanmerking komende CFP's. Deze samenvoegaanvragen worden verwerkt door de offline controlepuntthread. De evaluatie van het samenvoegbeleid wordt periodiek uitgevoerd en ook wanneer een controlepunt wordt gesloten.

Sql Server-samenvoegbeleid

SQL Server implementeert het volgende samenvoegbeleid:

• Een samenvoeging wordt gepland als twee of meer opeenvolgende CFP's kunnen worden geconsolideerd, rekening houdend met verwijderde rijen, zodat de resulterende rijen in één CFP van doelgrootte kunnen passen. De doelgrootte van gegevens- en deltabestanden komt overeen met de oorspronkelijke grootte, zoals eerder beschreven.

• Een CFP kan zelf worden samengevoegd als het gegevensbestand groter is dan het dubbele van de doelgrootte en meer dan de helft van de rijen wordt verwijderd. Een gegevensbestand kan groter worden dan de doelgrootte als bijvoorbeeld één transactie of meerdere gelijktijdige transacties een grote hoeveelheid gegevens invoegt of bijwerkt, waardoor het gegevensbestand groter wordt dan de doelgrootte, omdat een transactie niet meerdere CFP's kan omvatten.

Hier volgen enkele voorbeelden van de CFP's die moeten worden samengevoegd onder het samenvoegbeleid:

Niet alle CFP's met beschikbare ruimte komen in aanmerking voor samenvoeging. Als twee aangrenzende CFP's bijvoorbeeld 60% vol zijn, komen ze niet in aanmerking voor samenvoeging en hebben elk van deze CFP's 40% ongebruikte opslag. In het ergste geval zijn alle CFP's 50% vol, een opslaggebruik van slechts 50%. Hoewel de verwijderde rijen mogelijk in de opslag aanwezig zijn omdat de CFP's niet in aanmerking komen voor samenvoeging, zijn de verwijderde rijen mogelijk al door in-memory garbage-collection uit het geheugen verwijderd. Het beheer van opslag en van het geheugen is onafhankelijk van vuilnisophaling. Opslag die wordt gebruikt door actieve CFP's (niet alle CFP's worden bijgewerkt) kan maximaal twee keer groter zijn dan de grootte van duurzame tabellen in het geheugen.

Levenscyclus van een GVB

CFPs transitioneren naar verschillende staten voordat ze kunnen worden gedelokaliseerd. Databasecontrolepunten en logboekback-ups moeten plaatsvinden om de bestanden door de fasen te verplaatsen en uiteindelijk bestanden op te schonen die niet meer nodig zijn. Zie sys.dm_db_xtp_checkpoint_files voor een beschrijving van deze fasen.

U kunt handmatig een controlepunt forceren, gevolgd door een logback-up, om het garbagecollectieproces te versnellen. In productiescenario's zorgen de automatische controlepunten en logback-ups, die als onderdeel van de back-upstrategie worden genomen, voor een naadloze overgang door deze fasen zonder dat er handmatige tussenkomst nodig is. Het effect van het garbage-collectionproces is dat databases met geheugen-geoptimaliseerde tabellen mogelijk een grotere opslagcapaciteit hebben vergeleken met hun grootte in het geheugen. Als er geen controlepunt- en logboekback-ups worden uitgevoerd, blijft de footprint van controlepuntbestanden op de schijf groeien.

Verwante inhoud

• Opslag maken en beheren voor objecten die zijn geoptimaliseerd voor geheugen