Delen via

Door het geheugen geoptimaliseerde systeemversie van tijdelijke tabelprestaties

  • Artikel

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

In dit artikel worden enkele specifieke prestatieoverwegingen besproken bij het gebruik van tijdelijke tabellen met systeemversies die zijn geoptimaliseerd voor geheugen.

Wanneer u systeemversiebeheer toevoegt aan een bestaande niet-tijdelijke tabel, verwacht u een prestatieimpact op update- en verwijderbewerkingen, omdat de geschiedenistabel automatisch wordt bijgewerkt.

Prestatieoverwegingen

Elke update en verwijdering wordt vastgelegd in een interne geschiedenistabel die is geoptimaliseerd voor geheugen. Mogelijk ondervindt u onverwacht geheugenverbruik als uw workload deze twee bewerkingen enorm gebruikt. Daarom adviseren wij u de volgende overwegingen:

  • Voer in één stap geen enorme verwijderingen uit de huidige tabel uit. Overweeg om gegevens in meerdere batches te verwijderen, met een handmatig gestart gegevensflush daartussen, met sp_xtp_flush_temporal_history, of terwijl SYSTEM_VERSIONING = OFF.

  • Voer geen enorme tabelupdates tegelijk uit, omdat dit kan leiden tot geheugenverbruik dat twee keer zo groot is als de hoeveelheid geheugen die nodig is voor het bijwerken van een niet-tijdelijke tabel die is geoptimaliseerd voor geheugen. Dit verdubbelde geheugenverbruik is tijdelijk, omdat de dataflush-taak regelmatig werkt om het geheugenverbruik van interne faseringstabellen binnen de verwachte grenzen in de stabiele toestand te behouden. De grens is 10 procent van het geheugenverbruik van de huidige tijdelijke tabel. Overweeg om enorme updates in meerdere batches uit te voeren, of terwijl SYSTEM_VERSIONING = OFF, zoals het gebruik van updates om de standaardwaarden voor nieuw toegevoegde kolommen in te stellen.

De activeringsperiode voor de taak voor het leegmaken van gegevens kan niet worden geconfigureerd, maar u kunt sp_xtp_flush_temporal_history indien nodig handmatig uitvoeren.

Overweeg het gebruik van geclusterde columnstore als opslagoptie voor een geschiedenistabel op basis van schijven, met name als u van plan bent analysequery's uit te voeren op historische gegevens die gebruikmaken van statistische functies of vensterfuncties. In dat geval is een geclusterde columnstore-index een optimale keuze voor uw geschiedenistabel. Geclusterde columnstore-indexen bieden goede gegevenscompressie en gedragen zich op een invoegvriendelijke manier, afgestemd op de manier waarop geschiedenisgegevens worden gegenereerd.

Verwante inhoud