Delen via

Tijdelijke tabellen met systeemversies met tabellen die zijn geoptimaliseerd voor geheugen

  • Artikel

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

Tijdelijke tabellen met systeemversies voor tabellen die zijn geoptimaliseerd voor geheugen bieden een rendabele oplossing voor scenario's waarin gegevenscontrole en tijdstipanalyse vereist zijn voor gegevens die worden verzameld met In-Memory OLTP-workloads.

Notitie

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 gedurende een lange periode (meerdere maanden, zelfs jaren) bewaard, ook al wordt er niet regelmatig een query uitgevoerd.

Gegevenscontrole en op tijd gebaseerde analyse kunnen worden aangevraagd in verschillende omgevingen, met name in OLTP-systemen die zeer grote aantallen 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-versioneerde tijdelijke tabellen voor geheugen-geoptimaliseerde tabellen bieden hoge transactionele doorvoer en gelijktijdigheid zonder vergrendeling. Ze bieden u de mogelijkheid om grote hoeveelheden geschiedenisgegevens op te slaan met behulp van in-memory tabellen voor het opslaan van huidige gegevens (de tijdelijke tabel) en schijftabellen voor historische gegevens. 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.

diagram van tijdelijke architectuur in het geheugen.

Implementatiedetails

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

  • Alleen tabellen die zijn geoptimaliseerd voor duurzaam geheugen kunnen systeemversies (DURABILITY = SCHEMA_AND_DATA) zijn.

  • Geschiedenistabel voor door het geheugen geoptimaliseerde systeemversietabel moet schijfgebaseerd zijn, ongeacht of deze is gemaakt door de eindgebruiker of het systeem.

  • Query's die alleen van invloed zijn op de huidige tabel in het geheugen, kunnen worden gebruikt in systeemeigen gecompileerde T-SQL-modules. Tijdelijke query's die gebruikmaken van de FOR SYSTEM TIME-component worden niet ondersteund in systeemeigen gecompileerde modules. De FOR SYSTEM TIME-clausule wordt ondersteund met geheugen-geoptimaliseerde tabellen in ad-hocquery's en niet-inheemse modules.

  • Met SYSTEM_VERSIONING = ONwordt automatisch een interne faseringstabel gemaakt die is geoptimaliseerd voor geheugen om de meest recente wijzigingen in systeemversies te accepteren. Dit zijn de resultaten van update- en verwijderbewerkingen in een huidige tabel die is geoptimaliseerd voor geheugen.

  • Gegevens uit de interne, geheugen-geoptimaliseerde faseringstabel worden regelmatig verplaatst naar de schijfgebaseerde geschiedenistabel door een asynchrone datadoorsturingsopdracht. Met dit mechanisme voor het leegmaken van gegevens blijven de interne geheugenbuffers kleiner dan 10 procent van het geheugenverbruik van hun bovenliggende objecten. U kunt het totale geheugenverbruik van een geheugen-geoptimaliseerde systeem-versiede temporele tabel bijhouden door een query uit te voeren op de sys.dm_db_xtp_memory_consumersen door de gegevens samen te vatten voor de interne geheugen-geoptimaliseerde faseringstabel en de huidige temporele tabel.

  • U kunt een gegevensspoeling handmatig uitvoeren door sp_xtp_flush_temporal_historyuit te voeren.

  • Met SYSTEM_VERSIONING = OFFof wanneer het schema van een systeemversietabel wordt gewijzigd door kolommen toe te voegen, neer te zetten of te wijzigen, wordt de volledige inhoud van de interne faseringsbuffer verplaatst naar de geschiedenistabel op basis van de schijf.

  • 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 gegevens leegmaken, wat de duur van de bewerking 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 wordt gegenereerd in de volgende indeling: Memory_Optimized_History_Table_<object_id> waarbij <object_id> id is van de huidige tijdelijke tabel.

  • De tabel repliceert het schema van de huidige tijdelijke tabel plus één bigint kolom. Deze extra kolom garandeert de uniekheid van de rijen die naar de interne geschiedenisbuffer zijn 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 nieuwe maximum is nu 8052 bytes.

  • De interne faseringstabel die is geoptimaliseerd voor geheugen, wordt niet weergegeven in Objectverkenner van SQL Server Management Studio.

  • Metagegevens over deze tabel en de verbinding met de huidige tijdelijke tabel vindt u in sys.internal_tables.

De taak voor het leegmaken van gegevens

Het leegmaken van gegevens is een regelmatig geactiveerde taak die controleert of een tabel die is geoptimaliseerd voor geheugen voldoet aan een voorwaarde op basis van de geheugengrootte voor gegevensverplaatsing. Gegevensverplaatsing begint wanneer het geheugenverbruik van de interne faseringstabel acht procent van het geheugenverbruik van de huidige tijdelijke tabel bereikt.

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.

Verwante inhoud