Tijdelijke tabellen met systeemversies met tabellen die zijn geoptimaliseerd voor geheugen

Van toepassing op: SQL Server 2016 (13.x) en latere versies van Azure SQL Managed Instance

Systeemversiebeheerde temporele tabellen voor geheugengeoptimaliseerde tabellen bieden een kosteneffectieve oplossing voor scenario's waarin data-audit en analyse op een bepaald tijdstip vereist zijn voor gegevens die met in-memory OLTP-workloads zijn verzameld.

Note

Tijdelijke tabellen die zijn geoptimaliseerd voor geheugen, zijn alleen beschikbaar in SQL Server en Azure SQL Managed Instance. Tabellen en tijdelijke tabellen die zijn geoptimaliseerd voor geheugen, zijn onafhankelijk beschikbaar in Azure SQL Database.

Overzicht

Systeemversies tijdtabellen houden automatisch een volledige geschiedenis van gegevenswijzigingen bij en maken handige Transact-SQL-uitbreidingen beschikbaar voor momentopnamen analyse. In een typisch scenario wordt de gegevensgeschiedenis lange tijd bewaard (meerdere maanden, zelfs jaren), ook al wordt deze niet regelmatig opgevraagd.

Data-audit en tijdgebaseerde analyse kunnen in verschillende omgevingen vereist zijn, vooral in OLTP-systemen die extreem grote aanvragen verwerken en waar in-memory OLTP-technologie wordt gebruikt. Het is echter lastig om tabellen te gebruiken die zijn geoptimaliseerd voor geheugen in tijdelijke scenario's, omdat een enorme hoeveelheid gegenereerde historische gegevens de limiet van het beschikbare RAM-geheugen overschrijdt. Tegelijkertijd is het gebruik van RAM voor het opslaan van alleen-lezen historische gegevens die minder vaak worden geopend als deze ouder worden, geen optimale oplossing.

Systeem-versiebeheerde temporale tabellen voor geheugen-geoptimaliseerde tabellen bieden een hoge transactionele verwerkingssnelheid en gelijktijdige uitvoering zonder vergrendeling. Je kunt een grote hoeveelheid geschiedenisgegevens opslaan door in-memory tabellen te gebruiken voor het opslaan van actuele data (de temporele tabel), en schijfgebaseerde tabellen voor historische data. Het effect op DML-bewerkingen wordt verminderd met behulp van een interne, automatisch gegenereerde faseringstabel die recente geschiedenis opslaat en waarmee DML's kunnen worden uitgevoerd vanuit systeemeigen gecompileerde code.

In het volgende diagram ziet u deze architectuur.

Implementatiedetails

Wanneer u een systeem-geversioneerde, geheugen-geoptimaliseerde tabel maakt, moet u rekening houden met de volgende overwegingen. Zie voor syntaxisopties en voor een voorbeeld CREATE TABLE.

Alleen tabellen die zijn geoptimaliseerd voor duurzaam geheugen kunnen systeemversies (DURABILITY = SCHEMA_AND_DATA) zijn.
De geschiedenistabel voor een geheugengeoptimaliseerde systeemversie-tabel moet schijfgebaseerd zijn, of je deze nu aanmaakt of het systeem hem aanmaakt.
Je kunt queries gebruiken die alleen de huidige in-memory tabel beïnvloeden in native gecompileerde T-SQL-modules. Native gecompileerde modules ondersteunen de FOR SYSTEM TIME clausule niet, maar ad hoc queries en niet-native modules kunnen de clausule gebruiken tegen geheugengeoptimaliseerde tabellen.
Met SYSTEM_VERSIONING = ON, creëert het systeem automatisch een interne geheugengeoptimaliseerde stagingtabel om de meest recente systeemversiegevoerde wijzigingen te accepteren, die voortkomen uit update- en verwijderingsoperaties op een huidige geheugengeoptimaliseerde tabel.
Een asynchrone data flush-taak verplaatst regelmatig gegevens van de interne geheugen-geoptimaliseerde stagingtabel naar de schijfgebaseerde geschiedenistabel. Met dit mechanisme voor het leegmaken van gegevens blijven de interne geheugenbuffers kleiner dan 10 procent van het geheugenverbruik van hun bovenliggende objecten. Je kunt het totale geheugenverbruik van een geheugengeoptimaliseerde, systeemversiebeheerde temporele tabel bijhouden door sys.dm_db_xtp_memory_consumers op te vragen en de gegevens samen te vatten voor de interne geheugengeoptimaliseerde staging-tabel en de huidige temporele tabel.
Om handmatig een dataflush uit te voeren, voer sp_xtp_flush_temporal_history uit.
Met SYSTEM_VERSIONING = OFF, of als je het schema van een tabel met systeemversies wijzigt door kolommen toe te voegen, te verwijderen of te wijzigen, wordt de volledige inhoud van de interne tussenbuffer verplaatst naar de schijfgebaseerde historietabel.
Het uitvoeren van query's op historische gegevens valt effectief onder het isolatieniveau van de momentopname en retourneert altijd een samenvoeging tussen faseringsbuffer in het geheugen en een tabel op basis van schijven zonder duplicaten.
ALTER TABLE bewerkingen die het tabelschema intern wijzigen, moeten een dataflush uitvoeren, wat de operatie kan verlengen.

De interne faseringstabel die is geoptimaliseerd voor geheugen

Het systeem maakt een interne faseringstabel die is geoptimaliseerd voor geheugen om DML-bewerkingen te optimaliseren.

De tabelnaam gebruikt het volgende formaat: Memory_Optimized_History_Table_<object_id> waarbij <object_id> de identificatie is van de huidige temporele tabel.
De tabel repliceert het schema van de huidige temporele tabel plus één bigintkolom . Deze extra kolom garandeert de uniciteit van de rijen die naar de interne geschiedenisbuffer worden verplaatst.
De extra kolom heeft de volgende naamnotatie: Change_ID[<suffix>], waarbij <suffix> optioneel wordt toegevoegd in het geval dat de tabel al een Change_ID kolom heeft.
De maximale rijgrootte voor een tabel met systeemversies die is geoptimaliseerd voor geheugen, wordt met 8 bytes verminderd vanwege de extra bigint kolom in de faseringstabel. Het maximum is nu 8.052 bytes.
De interne geheugen-geoptimaliseerde stagingtabel verschijnt niet in Objectverkenner van SQL Server Management Studio.
Je kunt metadata vinden over deze tabel, en de verbinding met de huidige temporele tabel, in sys.internal_tables.

De taak voor het leegmaken van gegevens

De data flush-taak draait regelmatig en controleert of een geheugengeoptimaliseerde tabel voldoet aan een op geheugengrootte gebaseerde voorwaarde voor databeweging. De gegevensbeweging begint wanneer het geheugenverbruik van de interne stagingtabel acht procent bereikt van het geheugenverbruik van de huidige temporele tabel.

De taak voor het leegmaken van gegevens wordt regelmatig geactiveerd met een schema dat varieert op basis van de bestaande workload. Met een zware werkbelasting wordt de taak zo vaak uitgevoerd als elke 5 seconden. Met een lichte werkbelasting neemt de frequentie elke minuut toe. Er wordt een thread aangemaakt voor elke intern geheugen-geoptimaliseerde faseringstabel die opgeschoond moet worden.

Het gegevens flushen verwijdert alle records uit de interne buffer in het geheugen die ouder zijn dan de oudste momenteel lopende transactie om deze records naar een op de schijf gebaseerde geschiedenistabel te verplaatsen.

U kunt een data flush uitvoeren door sp_xtp_flush_temporal_history uit te voeren en de schema- en tabelnaam op te geven.

EXEC sys.sp_xtp_flush_temporal_history <schema_name>, <object_name>;

Hetzelfde proces voor gegevensverplaatsing wordt aangeroepen als wanneer het systeem de taak voor het leegmaken van gegevens uitvoert volgens de interne planning.

Feedback

Is deze pagina nuttig?

Last updated on 2026-08-18