Systemversionsbaserade temporala tabeller med minnesoptimerade tabeller

Gäller för: SQL Server 2016 (13.x) och senare versioner Azure SQL Managed Instance

Systemversionerade temporala tabeller för minnesoptimerade tabeller erbjuder en kostnadseffektiv lösning för scenarier där datagranskning och punkt-i-tid-analys krävs ovanpå data insamlade med minnesbaserade OLTP-arbetsbelastningar.

Note

Minnesoptimerade temporala tabeller är endast tillgängliga i SQL Server och Azure SQL Managed Instance. Minnesoptimerade tabeller och temporala tabeller är oberoende tillgängliga i Azure SQL Database.

Overview

Systemversionsbaserade temporala tabeller behåller automatiskt en fullständig historik över dataändringar och exponerar praktiska Transact-SQL tillägg för analys av tidpunkter. I ett typiskt scenario lagras datahistoriken under lång tid (flera månader, till och med år), även om den inte regelbundet förfrågas.

Datagranskning och tidsbaserad analys kan krävas i olika miljöer, särskilt i OLTP-system som hanterar extremt stora mängder förfrågningar och där in-memory OLTP-teknik används. Det är dock svårt att använda minnesoptimerade tabeller i tidsscenarier eftersom en enorm mängd genererade historiska data ofta överskrider gränsen för tillgängligt RAM-minne. Att använda RAM för att lagra skrivskyddade historiska data som används mindre ofta när de blir äldre är samtidigt inte en optimal lösning.

Systemversionerade temporala tabeller för minnesoptimerade tabeller ger hög transaktionell genomströmning och låsfri samtidighet. Du kan lagra en stor mängd historikdata genom att använda minnestabeller för att lagra aktuell data (den temporala tabellen) och diskbaserade tabeller för historisk data. Effekten på DML-åtgärder minskas med hjälp av en intern, automatiskt genererad minnesoptimerad mellanlagringstabell som lagrar den senaste historiken och gör att DML:er kan köras från intern kompilerad kod.

Följande diagram illustrerar den här arkitekturen.

Diagram över tidsmässig minnesintern arkitektur.

Implementeringsdetaljer

När du skapar en systemversionsbaserad minnesoptimerad tabell bör du vara medveten om följande överväganden. Syntaxalternativ och ett exempel finns i CREATE TABLE.

  • Endast hållbara minnesoptimerade tabeller kan systemversioneras (DURABILITY = SCHEMA_AND_DATA).

  • Historiktabellen för en minnesoptimerad systemversionerad tabell måste vara diskbaserad, oavsett om du skapar den eller systemet skapar den.

  • Du kan använda frågor som endast påverkar den aktuella minnestabellen i nativt kompilerade T-SQL-moduler. Nativt kompilerade moduler stöder inte klausulen FOR SYSTEM TIME , men ad hoc-frågor och icke-inhemska moduler kan använda klausulen mot minnesoptimerade tabeller.

  • Med SYSTEM_VERSIONING = ON, skapar systemet automatiskt en intern minnesoptimerad stagingtabell för att acceptera de senaste systemversionerade ändringarna, vilka uppstår från uppdaterings- och borttagningsoperationer på en aktuell minnesoptimerad tabell.

  • En asynkron dataflush-uppgift flyttar regelbundet data från den interna minnesoptimerade staging-tabellen till den diskbaserade historiktabellen. Den här dataspolningsmekanismen håller de interna minnesbuffertarna på mindre än 10 procent av minnesförbrukningen för sina överordnade objekt. Du kan spåra den totala minnesanvändningen för en minnesoptimerad systemversionerad temporal tabell genom att fråga sys.dm_db_xtp_memory_consumers och sammanfatta data för den interna minnesoptimerade staging-tabellen och den aktuella temporala tabellen.

  • För att manuellt genomföra en tömning av data, kör sp_xtp_flush_temporal_history.

  • Med SYSTEM_VERSIONING = OFF, eller när du ändrar schemat för en systemversionerad tabell genom att lägga till eller ta bort kolumner, flyttas hela innehållet i den interna stagingbufferten till den diskbaserade historiktabellen.

  • Frågor av historiska data sker effektivt under ögonblicksisoleringsnivån och returnerar alltid en union mellan intern mellanlagringsbuffert och diskbaserad tabell utan dubbletter.

  • ALTER TABLE operationer som internt ändrar tabellschemat måste utföra en datarensning, vilket kan förlänga operationen.

Den interna minnesoptimerade tabellen för mellanlagring

Systemet skapar en intern minnesoptimerad mellanlagringstabell för att optimera DML-åtgärder.

  • Tabellnamnet använder följande format: Memory_Optimized_History_Table_<object_id> där <object_id> är identifieraren för den aktuella temporala tabellen.

  • Tabellen replikerar schemat för den aktuella tidstabellen plus en bigintkolumn . Den här extra kolumnen garanterar att de rader som flyttas till den interna historikbufferten är unika.

  • Den extra kolumnen har följande namnformat: Change_ID[<suffix>], där <suffix> kan läggas till om tabellen redan har en Change_ID kolumn.

  • Den maximala radstorleken för en systemversionsbaserad minnesoptimerad tabell minskas med 8 byte på grund av den extra bigint-kolumnen i mellanlagringstabellen. Maximum är nu 8 052 byte.

  • Den interna minnesoptimerade staging-tabellen visas inte i Object Explorer i SQL Server Management Studio.

  • Du kan hitta metadata om denna tabell, och dess koppling till den aktuella temporala tabellen, i sys.internal_tables.

Dataspolningsaktiviteten

Datarensningsuppgiften körs regelbundet och kontrollerar om någon minnesoptimerad tabell uppfyller ett minnesstorleksbaserat villkor för datarörelse. Datarörelsen börjar när minnesförbrukningen i den interna stagingtabellen når åtta procent av minnesförbrukningen i den aktuella temporala tabellen.

Dataspolningsaktiviteten aktiveras regelbundet med ett schema som varierar beroende på den befintliga arbetsbelastningen. Med en tung arbetsbelastning körs aktiviteten så ofta som var 5:e sekund. Med en lätt arbetsbelastning ökar frekvensen till varje minut. En tråd skapas för varje intern minnesoptimerad mellanlagringstabell som behöver rensas.

Datarensning tar bort alla poster från den minnesinterna interna bufferten som är äldre än den äldsta transaktion som för närvarande körs för att flytta dessa poster till den diskbaserade historiktabellen.

Du kan köra en dataspolning genom att köra sp_xtp_flush_temporal_history och ange schema- och tabellnamnet:

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

Samma dataförflyttningsprocess anropas som när systemet kör datarensningsaktiviteten enligt det interna schemat.

Relaterat innehåll

  • Last updated on