Dela via

Hantera historiska data med kvarhållningsprincip

  • Artikel

Viktigt!

Azure SQL Edge dras tillbaka den 30 september 2025. Mer information och migreringsalternativ finns i meddelandet Om pensionering.

Kommentar

Azure SQL Edge stöder inte längre ARM64-plattformen.

När datakvarhållningsprincipen har definierats för en databas och den underliggande tabellen körs en tidsinställd bakgrundsaktivitet för att ta bort föråldrade poster från tabellen som är aktiverad för datakvarhållning. Identifiering av matchande rader och borttagningen av dem från tabellen sker transparent i den bakgrundsaktivitet som schemaläggs och körs av systemet. Åldersvillkoret för tabellraderna kontrolleras baserat på den filter_column kolumn som anges i tabelldefinitionen. Om kvarhållningsperioden är inställd på en vecka uppfyller t.ex. tabellrader som är berättigade till rensning något av följande villkor:

  • Om filterkolumnen använder datatypen DATETIMEOFFSET är villkoret filter_column < DATEADD(WEEK, -1, SYSUTCDATETIME())
  • Annars är villkoret filter_column < DATEADD(WEEK, -1, SYSDATETIME())

Rensningsfaser för datakvarhållning

Rensningen av datakvarhållning består av två faser:

  1. Identifiering: I den här fasen identifierar rensningsåtgärden alla tabeller i användardatabaserna för att skapa en lista för rensning. Identifieringen körs en gång om dagen.
  2. Rensning: I den här fasen körs rensningen mot alla tabeller med begränsad datakvarhållning som identifieras i identifieringsfasen. Om rensningsåtgärden inte kan utföras i en tabell hoppas tabellen över i den aktuella körningen och kommer att utföras igen i nästa iteration. Följande principer används vid rensning:
    • Om en föråldrad rad låses av en annan transaktion hoppas den raden över.
    • Rensningen körs med en standardtidsgräns på 5 sekunder. Om låsen inte kan hämtas i tabellerna i tidsgränsfönstret hoppas tabellen över i den aktuella körningen och görs ett nytt försök i nästa iteration.
    • Om det uppstår ett fel under rensningen av en tabell hoppas tabellen över och hämtas i nästa iteration.

Manuell rensning

Beroende på inställningarna för datakvarhållning i en tabell och arbetsbelastningens natur i databasen är det möjligt att den automatiska rensningstråden kanske inte helt tar bort alla föråldrade rader under körningen. För att användarna ska kunna ta bort föråldrade rader manuellt har den sys.sp_cleanup_data_retention lagrade proceduren introducerats i Azure SQL Edge.

Den här lagrade proceduren tar tre parametrar:

  • @schema_name: Namnet på ägandeschemat för tabellen. Obligatoriskt.
  • @table_name: Namnet på tabellen som manuell rensning körs för. Obligatoriskt.
  • @rowcount: Utdatavariabel. Returnerar antalet rader som rensats av den manuella rensnings-sp. Valfritt.

Mer information finns i sys.sp_cleanup_data_retention (Transact-SQL).

I följande exempel visas körningen av den manuella rensnings-SP:en för tabellen dbo.data_retention_table.

DECLARE @rowcnt BIGINT;
EXEC sys.sp_cleanup_data_retention 'dbo', 'data_retention_table', @rowcnt OUTPUT;
SELECT @rowcnt;

Hur föråldrade rader tas bort

Rensningsprocessen beror på tabellens indexlayout. En bakgrundsaktivitet skapas för att utföra föråldrad datarensning för alla tabeller med begränsad kvarhållningsperiod. Rensa logiken för radlagringsindexet (heap eller B-träd) tar bort föråldrade rader i mindre segment (upp till 10 000), vilket minimerar trycket på databasloggen och I/O-undersystemet. Även om rensningslogik använder det obligatoriska B-trädindexet kan ordningen på borttagningar för rader som är äldre än kvarhållningsperioden inte garanteras. Ta med andra ord inte något beroende av rensningsordningen i dina program.

Varning

När det gäller heaps- och B-trädindex kör datakvarhållning en borttagningsfråga i de underliggande tabellerna, vilket kan vara i konflikt med borttagningsutlösare i tabellerna. Du bör antingen ta bort borttagningsutlösare från tabellerna eller undvika att använda datakvarhållning i tabeller som har DML-utlösare som tas bort.

Rensningsaktiviteten för grupperade kolumnlagringsindex tar bort hela radgrupper samtidigt (innehåller vanligtvis 1 miljon rader vardera), vilket är effektivt, särskilt när data genereras och åldras i hög takt.

Diagram över rensning av datakvarhållning.

Utmärkt datakomprimering och effektiv rensning av kvarhållning gör grupperade kolumnlagringsindex till ett perfekt val för scenarier när din arbetsbelastning snabbt genererar en stor mängd data.

Övervaka rensning av datakvarhållning

Rensningsåtgärder för datakvarhållningsprinciper kan övervakas med hjälp av utökade händelser i Azure SQL Edge. Mer information om utökade händelser finns i Översikt över utökade händelser.

Följande utökade händelser hjälper dig att spåra tillståndet för rensningsåtgärderna.

Name beskrivning
data_retention_task_started Inträffar när bakgrundsaktiviteten för rensning av tabeller med en kvarhållningsprincip startar.
data_retention_task_completed Inträffar när bakgrundsaktiviteten för rensning av tabeller med en kvarhållningsprincip upphör.
data_retention_task_exception Inträffar när bakgrundsaktiviteten för rensning av tabeller med en kvarhållningsprincip misslyckas, utanför kvarhållningsrensningsprocessen som är specifik för dessa tabeller.
data_retention_cleanup_started Inträffar när rensningsprocessen för en tabell med en datakvarhållningsprincip startar.
data_retention_cleanup_exception Inträffar när rensningsprocessen för en tabell med kvarhållningsprincip misslyckas.
data_retention_cleanup_completed Inträffar när rensningsprocessen för en tabell med datakvarhållningsprincipen upphör.

Dessutom har en ny ringbufferttyp med namnet RING_BUFFER_DATA_RETENTION_CLEANUP lagts till i den sys.dm_os_ring_buffers dynamiska hanteringsvyn. Den här vyn kan användas för att övervaka rensningsåtgärder för datakvarhållning.

Relaterat innehåll