Dela via


Minnesoptimerad systemversionsbaserad temporal tabellprestanda

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

Den här artikeln beskriver några specifika prestandaöverväganden när du använder systemversionsbaserade minnesoptimerade tidstabeller.

När du lägger till systemversioner i en befintlig icke-temporal tabell kan du förvänta dig en prestandapåverkan på uppdaterings- och borttagningsåtgärder eftersom historiktabellen uppdateras automatiskt.

Prestandaöverväganden

Varje uppdatering och borttagning registreras i en intern minnesoptimerad historiktabell. Du kan uppleva oväntad minnesförbrukning om arbetsbelastningen använder dessa två åtgärder massivt. Därför rekommenderar vi följande överväganden:

  • Utför inte massiva borttagningar från den aktuella tabellen i ett steg. Överväg att ta bort data i flera batchar, och manuellt spola data mellan dessa, med sp_xtp_flush_temporal_history, eller medan SYSTEM_VERSIONING = OFF.

  • Utför inte massiva tabelluppdateringar samtidigt, eftersom det kan resultera i minnesförbrukning som är dubbelt så mycket minne som krävs för att uppdatera en icke-temporal minnesoptimerad tabell. Den här dubbla minnesförbrukningen är tillfällig eftersom dataspolningsaktiviteten fungerar regelbundet för att hålla minnesförbrukningen för interna mellanlagringstabeller inom beräknade gränser i stabilt tillstånd. Gränsen är 10 procent av minnesförbrukningen i den aktuella tidstabellen. Överväg att göra massiva uppdateringar i flera batchar, eller när du SYSTEM_VERSIONING = OFF, till exempel genom att använda uppdateringar för att ange standardvärden för nyligen tillagda kolumner.

Aktiveringsperioden för dataspolningsaktiviteten kan inte konfigureras, men du kan köra sp_xtp_flush_temporal_history manuellt efter behov.

Överväg att använda klustrade columnstore som lagringsalternativ för en diskbaserad historiktabell, särskilt om du planerar att köra analysfrågor på historiska data som använder aggregerade funktioner eller fönsterfunktioner. I så fall är ett grupperat kolumnlagringsindex ett optimalt val för din historiktabell. Grupperade kolumnlagringsindex ger bra datakomprimering och fungerar på ett infogningsvänligt sätt, i linje med hur historikdata genereras.