Door het geheugen geoptimaliseerde systeemversie van tijdelijke tabelprestaties

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

Dit artikel bespreekt specifieke prestatie-overwegingen wanneer je systeemversiegevende, geheugengeoptimaliseerde temporele tabellen gebruikt.

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

Prestatie-overwegingen

Elke update en verwijdering wordt vastgelegd in een interne geschiedenistabel die is geoptimaliseerd voor geheugen. Je kunt onverwacht geheugenverbruik ervaren als je workload deze twee bewerkingen veel gebruikt. Houd rekening met het volgende:

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

  • Voer geen enorme tabelupdates tegelijk uit, want dan kan het dubbele geheugen gebruiken dat nodig is om een niet-temporele geheugengeoptimaliseerde tabel bij te werken. 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 grootschalige updates in meerdere batches uit te voeren, of wanneer SYSTEM_VERSIONING = OFF, bijvoorbeeld door updates te gebruiken om standaardwaarden in te stellen voor nieuw toegevoegde kolommen.

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 om geclusterde columnstore als opslagoptie te gebruiken voor een schijfgebaseerde geschiedenistabel, vooral als je analytics-queries wilt uitvoeren op historische data die gebruikmaken van aggregate- of windowing-functies. 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 onderwerpen

  • Last updated on