Administrera och övervaka insamling av ändringsdata

Artikel
2025-03-05

gäller för:SQL Server Azure SQL Managed Instance

Det här avsnittet beskriver hur du administrerar och övervakar insamling av ändringsdata för SQL Server och Azure SQL Managed Instance.

För Azure SQL Database, som använder en annan jobbmekanism, se CDC med Azure SQL Database.

Avbildningsjobb

Avbildningsjobbet initieras genom att köra den parameterlösa lagrade proceduren sp_MScdc_capture_job. Den här lagrade proceduren börjar med att extrahera de konfigurerade värdena för maxtrans, maxscans, continuousoch pollinginterval för avbildningsjobbet från msdb.dbo.cdc_jobs. Dessa konfigurerade värden skickas sedan som parametrar till den lagrade proceduren sp_cdc_scan. Detta används för att anropa sp_replcmds för att utföra logggenomsökningen.

Avbilda jobbparametrar

För att förstå beteendet för avbildningsjobb måste du förstå hur de konfigurerbara parametrarna används av sp_cdc_scan.

Parameter `maxtrans`

Parametern maxtrans anger det maximala antalet transaktioner som kan bearbetas i en enda genomsökningscykel i loggen. Om antalet transaktioner som ska bearbetas når den här gränsen under genomsökningen inkluderas inga ytterligare transaktioner i den aktuella genomsökningen. När en genomsökningscykel är klar är antalet transaktioner som har bearbetats alltid mindre än eller lika med maxtrans.

`maxscans`-parameter

Parametern maxscans anger det maximala antalet genomsökningscykler som försöker tömma loggen innan den antingen returnerar (kontinuerlig = 0) eller kör en waitfor (kontinuerlig = 1).

`continuous` parameter

Parametern continuous styr om sp_cdc_scan avstår från kontrollen efter att antingen ha rensat loggen eller kört det maximala antalet genomsökningscykler (enstegsläge). Den styr också om sp_cdc_scan fortsätter att köras tills den uttryckligen stoppas (kontinuerligt läge).

Enbildsläge

I ensatsläge begär sp_cdc_scan att avbildningsjobbet ska utföra upp till maxtrans genomsökningar för att försöka rensa loggen och avsluta. Alla transaktioner utöver maxtrans som finns i loggen bearbetas i senare genomsökningar.

One-shot-läge används i kontrollerade tester, där volymen av transaktioner som ska bearbetas är känd, och det finns fördelar med att jobbet stängs automatiskt när det är klart. Enkelfotograferingsläge rekommenderas inte för användning i produktion. Det beror på att det förlitar sig på jobbschemat för att hantera hur ofta genomsökningscykeln körs.

När du kör i enskottsläge kan du beräkna ett övre gränsvärde för förväntat dataflöde för avbildningsjobbet, uttryckt i transaktioner per sekund med hjälp av följande beräkning:

(maxtrans * maxscans) / number of seconds between scans

Även om den tid som krävs för att skanna loggen och fylla i ändringstabellerna inte skiljer sig avsevärt från 0, kunde det genomsnittliga dataflödet för jobbet inte överskrida det värde som erhålls genom att dividera det maximala tillåtna transaktionerna för en enda genomsökning multiplicerat med det maximala tillåtna genomsökningarna med antalet sekunder som avgränsar loggbearbetningen.

Om enstaka körläge skulle användas för att styra genomsökning av loggar, måste tidsintervallet i sekunder mellan loggbearbetningarna regleras av jobbschemat. När den här typen av beteende önskas är det bättre att köra capture-jobbet i kontinuerligt läge för att schemalägga om logggenomsökningen.

Kontinuerligt läge och avsökningsintervall

I kontinuerligt läge begär avbildningsjobbet att sp_cdc_scan körs kontinuerligt. På så sätt kan den lagrade proceduren hantera sin egen vänteloop genom att inte bara ange maxtrans och maxscans utan även ett värde för antalet sekunder mellan loggbearbetningen (avsökningsintervallet). I kontinuerligt läge förblir avbildningsjobbet aktivt och kör en WAITFOR mellan logggenomsökningen.

Anteckning

När värdet för avsökningsintervallet är större än 0 gäller samma övre gräns för genomströmning för det återkommande en-gångs-jobbet även för kontinuerlig jobbåtgärd. Det vill säga, (maxtrans * maxscans) dividerat med ett pollingintervall som inte är noll sätter en övre gräns för det genomsnittliga antalet transaktioner som kan bearbetas av infångningsjobbet.

Anpassning av avbildningsjobb

För avbildningsjobbet kan du använda ytterligare logik för att avgöra om en ny genomsökning börjar omedelbart eller om en fördröjning införs innan den startar en ny genomsökning, i stället för att förlita sig på ett fast pollningsintervall. Valet kan bara baseras på tid på dagen, kanske framtvinga mycket långa sömn under tider med hög aktivitet, och till och med flytta till ett avsökningsintervall på 0 vid slutet av dagen när det är viktigt att slutföra dagarnas bearbetning och förbereda sig för nattliga körningar. Infångningsprocessens förlopp kunde också övervakas för att avgöra när alla transaktioner som bokförts före midnatt hade skannats in och lagts till i ändringstabeller. På så sätt kan inspelningsjobbet avslutas och startas om vid en daglig schemalagd omstart. Om du vill anpassa beteendet kan du ersätta jobbsteget som anropar sp_cdc_scan med ett anrop till ett användarskrivet skript för sp_cdc_scan.

Rensningsjobb

Det här avsnittet innehåller information om hur rensningsjobbet för ändringsdatainsamling fungerar.

Struktur för rensningsjobbet

Ändringsregistrering använder en kvarhållningsbaserad rensningsstrategi för att hantera ändringstabellernas storlek. I SQL Server och Azure SQL Managed Instance består rensningsmekanismen av en SQL Server-agent Transact-SQL jobb som skapas när den första databastabellen är aktiverad. Ett enda rensningsjobb hanterar alla tabeller med databasändringar och tillämpar samma kvarhållningsvärde på alla definierade insamlingsexemplar.

Rensningsjobbet initieras genom att köra den parameterlösa lagrade proceduren sp_MScdc_cleanup_job. Den här lagrade proceduren börjar med att extrahera de konfigurerade kvarhållnings- och tröskelvärdena för rensningsjobbet från msdb.dbo.cdc_jobs. Kvarhållningsvärdet används för att beräkna en ny lågvattenstämpel för ändringstabellerna. Det angivna antalet minuter subtraheras från det maximala tran_end_time värdet från tabellen cdc.lsn_time_mapping för att få det nya lågvattenmärket uttryckt som ett datetime-värde. Tabellen CDC.lsn_time_mapping används sedan för att konvertera det här datetime-värdet till ett motsvarande lsn värde. Om flera poster i tabellen delar samma incheckningstid väljs den lsn som motsvarar den post med den minsta lsn som den nya lågvattenmärket. Det här lsn värdet skickas till sp_cdc_cleanup_change_tables för att ta bort ändringstabellposter från databasändringstabellerna.

Obs

Fördelen med att använda committiden för den senaste transaktionen som bas för att beräkna den nya lågvattenmärket är att ändringarna kan kvarstå i ändringstabellerna under den angivna tiden. Detta händer även när fångstprocessen ligger efter. Alla poster som har samma committid som det aktuella lägsta vattenmärket fortsätter att representeras i ändringstabellerna genom att välja den minsta lsn som har den delade committiden för det faktiska lägsta vattenmärket.

När en rensning utförs uppdateras det lägsta vattenmärket för alla avbildningsinstanser inom en och samma transaktion. Den försöker sedan ta bort föråldrade poster från ändringstabellerna och tabellen cdc.lsn_time_mapping. Det konfigurerbara tröskelvärdet begränsar hur många poster som tas bort i en enda instruktion. Om du inte utför borttagningen i en enskild tabell hindras inte åtgärden från att försöka utföras i de återstående tabellerna.

Anpassning av rensningsjobb

För rensningsjobbet finns möjligheten till anpassning i den strategi som används för att avgöra vilka ändringstabellposter som ska ignoreras. Den enda strategi som stöds i det levererade rensningsjobbet är en tidsbaserad strategi. I den situationen beräknas den nya lågvattenstämpeln genom att subtrahera den tillåtna kvarhållningsperioden från kommittiden för den senaste bearbetade transaktionen. Eftersom de underliggande rensningsprocedurerna baseras på lsn i stället för tid kan valfritt antal strategier användas för att fastställa den minsta lsn att behålla i ändringstabellerna. Endast vissa av dessa är strikt tidsbaserade. Kunskap om klienterna skulle kunna användas för att tillhandahålla en säkerhetsåtgärd, ifall efterföljande processer som kräver åtkomst till ändringstabellerna inte kan köras. Även om standardstrategin använder samma lsn för att rensa alla databasernas ändringstabeller, kan den underliggande rensningsproceduren också anropas för att rensa på nivå för insamlingsinstans.

Övervaka processen

Genom att övervaka processen för insamling av ändringsdata kan du avgöra om ändringarna skrivs korrekt och med en rimlig svarstid till ändringstabellerna. Övervakning kan också hjälpa dig att identifiera eventuella fel som kan inträffa. SQL Server innehåller två dynamiska hanteringsvyer som hjälper dig att övervaka insamling av ändringsdata: sys.dm_cdc_log_scan_sessions och sys.dm_cdc_errors.

Identifiera sessioner med tomma resultatuppsättningar

Varje rad i sys.dm_cdc_log_scan_sessions representerar en logggenomsökningssession (förutom raden med ett ID på 0). En logggenomsökningssession motsvarar en körning av sp_cdc_scan. Under en session kan genomsökningen antingen returnera ändringar eller returnera ett tomt resultat. Om resultatuppsättningen är tom anges kolumnen empty_scan_count i sys.dm_cdc_log_scan_sessions till 1. Om det finns tomma resultatuppsättningar i följd, till exempel om avbildningsjobbet körs kontinuerligt, ökas empty_scan_count i den senaste befintliga raden. Om sys.dm_cdc_log_scan_sessions till exempel redan innehåller 10 rader för genomsökningar som returnerade ändringar och det finns fem tomma resultat på en rad, innehåller vyn 11 rader. Den sista raden har värdet 5 i kolumnen empty_scan_count. Kör följande fråga för att fastställa sessioner som hade en tom genomsökning:

SELECT * from sys.dm_cdc_log_scan_sessions where empty_scan_count <> 0

Fastställa svarstid

Hanteringsvyn sys.dm_cdc_log_scan_sessions inkluderar en kolumn som registrerar latensen för varje avbildningssession. Svarstiden definieras som tiden mellan att en transaktion bekräftas på en källtabell och att den senaste insamlade transaktionen bekräftas på ändringstabellen. Kolumnen för svarstid fylls endast i för aktiva sessioner. För sessioner med ett värde som är större än 0 i kolumnen empty_scan_count anges svarstidskolumnen till 0. Följande fråga returnerar den genomsnittliga svarstiden för de senaste sessionerna:

SELECT latency FROM sys.dm_cdc_log_scan_sessions WHERE session_id = 0

Du kan använda svarstidsdata för att avgöra hur snabbt eller långsamt avbildningsprocessen bearbetar transaktioner. Dessa data är mest användbara när insamlingsprocessen körs kontinuerligt. Om avbildningsprocessen körs enligt ett schema kan svarstiden vara hög på grund av fördröjningen mellan transaktioner som checkas in i källtabellen och avbildningsprocessen som körs vid den schemalagda tiden.

Ett annat viktigt mått på infångningsprocessens effektivitet är dataflödet. Det här är det genomsnittliga antalet kommandon per sekund som bearbetas under varje session. Om du vill fastställa dataflödet för en session delar du upp värdet i kolumnen command_count med värdet i varaktighetskolumnen. Följande fråga returnerar det genomsnittliga dataflödet för de senaste sessionerna:

SELECT command_count/duration AS [Throughput] FROM sys.dm_cdc_log_scan_sessions WHERE session_id = 0

Använda datainsamlare för att samla in samplingsdata

Med SQL Server-datainsamlaren kan du samla in ögonblicksbilder av data från valfri tabell eller dynamisk hanteringsvy och skapa ett informationslager för prestanda. När insamling av ändringsdata är aktiverat i en databas är det användbart att ta ögonblicksbilder av sys.dm_cdc_log_scan_sessions-vyn och sys.dm_cdc_errors-vyn med jämna mellanrum för senare analys. Följande procedur konfigurerar en datainsamlare för insamling av exempeldata från sys.dm_cdc_log_scan_sessions hanteringsvyn.

Konfigurera datainsamling

Aktivera datainsamlare och konfigurera ett informationslager för hantering. Mer information finns i Hantera datainsamling.

Kör följande kod för att skapa en anpassad insamlare för insamling av ändringsdata.

USE msdb;  

DECLARE @schedule_uid uniqueidentifier;  

-- Collect and upload data every 5 minutes  
SELECT @schedule_uid = (  
SELECT schedule_uid from sysschedules_localserver_view
WHERE name = N'CollectorSchedule_Every_5min')  

DECLARE @collection_set_id int;  

EXEC dbo.sp_syscollector_create_collection_set  
@name = N' CDC Performance Data Collector',  
@schedule_uid = @schedule_uid,
@collection_mode = 0,
@days_until_expiration = 30,
@description = N'This collection set collects CDC metadata',  
@collection_set_id = @collection_set_id output;  

-- Create a collection item using statistics from
-- the change data capture dynamic management view.  
DECLARE @parameters xml;  
DECLARE @collection_item_id int;  

SELECT @parameters = CONVERT(xml,
    N'<TSQLQueryCollector>  
        <Query>  
          <Value>SELECT * FROM sys.dm_cdc_log_scan_sessions</Value>  
          <OutputTable>cdc_log_scan_data</OutputTable>  
        </Query>  
      </TSQLQueryCollector>');  

EXEC dbo.sp_syscollector_create_collection_item  
@collection_set_id = @collection_set_id,  
@collector_type_uid = N'302E93D1-3424-4BE7-AA8E-84813ECF2419',  
@name = ' CDC Performance Data Collector',  
@frequency = 5,
@parameters = @parameters,  
@collection_item_id = @collection_item_id output;

GO

I SQL Server Management Studio expanderar du Managementoch expanderar sedan Data Collection. Högerklicka på CDC Performance Data Collectoroch klicka sedan på Starta datainsamlingsuppsättning.
Leta upp tabellen custom_snapshots.cdc_log_scan_data i informationslagret som du konfigurerade i steg 1. Den här tabellen innehåller en historisk ögonblicksbild av data från logggenomsökningssessioner. Dessa data kan användas för att analysera svarstider, dataflöde och andra prestandamått över tid.

Skriptuppgraderingsläge

När du tillämpar kumulativa uppdateringar eller servicepaket på en instans kan instansen vid omstart ange i skriptuppgraderingsläge. I det här läget kan SQL Server köra ett steg för att analysera och uppgradera interna CDC-tabeller, vilket kan leda till att objekt som index återskapas i avbildningstabeller. Beroende på mängden data som berörs kan det här steget ta lite tid eller orsaka hög transaktionslogganvändning för aktiverade CDC-databaser.

Dela via