Dela via

Systemversionsbaserade temporala tabeller med minnesoptimerade tabeller

  • Artikel

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

Systemversionsbaserade temporala tabeller för minnesoptimerade tabeller tillhandahåller en kostnadseffektiv lösning för scenarier där datagranskning och tidpunktsanalys krävs utöver data som har samlats in med In-Memory OLTP-arbetsbelastningar.

Notera

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.

Överblick

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 behålls datahistoriken under en lång tidsperiod (flera månader, till och med år), även om den inte efterfrågas regelbundet.

Datagranskning och tidsbaserad analys kan efterfrågas i olika miljöer, särskilt i OLTP-system som bearbetar extremt många begäranden 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.

Systemversionsbaserade temporala tabeller för minnesoptimerade tabeller ger högt transaktionsdataflöde och låsfri samtidighet. De ger dig möjlighet att lagra stora mängder historikdata med hjälp av minnesinterna tabeller för lagring av aktuella data (den tidsmässiga tabellen) och diskbaserade tabeller för historiska 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.

Implementeringsinformation

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 den minnesoptimerade systemversionstabellen måste vara diskbaserad, oavsett om den skapades av slutanvändaren eller systemet.

  • Frågor som endast påverkar den aktuella minnesinterna tabellen kan användas i internt kompilerade T-SQL-moduler. Temporala frågor som använder FOR SYSTEM TIME-satsen stöds inte i inbyggda kompilerade moduler. Satsen FOR SYSTEM TIME stöds med minnesoptimerade tabeller i ad hoc-frågor och icke-inbyggda moduler.

  • Med SYSTEM_VERSIONING = ONskapas automatiskt en intern minnesoptimerad mellanlagringstabell för att acceptera de senaste systemversionsändringarna, vilket är resultatet av uppdaterings- och borttagningsåtgärder i en aktuell minnesoptimerad tabell.

  • Data från den interna minnesoptimerade mellanlagringstabellen flyttas regelbundet till den diskbaserade historiktabellen av en asynkron datarensningsuppgift. 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 minnesförbrukningen för den minnesoptimerade systemversionstabellen genom att fråga sys.dm_db_xtp_memory_consumersoch sammanfatta data för den interna minnesoptimerade mellanlagringstabellen och den aktuella tidstabellen.

  • Du kan köra en dataspolning manuellt genom att köra sp_xtp_flush_temporal_history.

  • Med SYSTEM_VERSIONING = OFF, eller när schemat för en systemversionstabell ändras genom att lägga till, släppa eller ändra kolumner flyttas hela innehållet i den interna mellanlagringsbufferten 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 åtgärder som ändrar tabellschemat internt måste utföra en dataspolning, vilket kan förlänga åtgärdens varaktighet.

Den interna minnesoptimerade tabellen för mellanlagring

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

  • Tabellnamnet genereras i följande format: Memory_Optimized_History_Table_<object_id> där <object_id> är identifierare för den aktuella tidstabellen.

  • Tabellen replikerar schemat för aktuell temporär tabell plus en bigint kolumn. Den här extra kolumnen garanterar att raderna 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. Det nya maxvärdet är nu 8 052 byte.

  • Den interna minnesoptimerade mellanlagringstabellen visas inte i Object Explorer i SQL Server Management Studio.

  • Metadata om den här tabellen och dess anslutning till den aktuella temporala tabellen finns i sys.internal_tables.

Dataspolningsaktiviteten

Dataspolning är en regelbundet aktiverad uppgift som kontrollerar om någon minnesoptimerad tabell uppfyller ett minnesstorleksbaserat villkor för dataflytt. Dataförflyttningen startar när minnesförbrukningen i den interna mellanlagringstabellen 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