Ändra datainsamling (CDC) med Azure SQL Database

Artikel
03/05/2025

I den här artikeln får du lära dig hur CDC (Change Data Capture) implementeras i Azure SQL Database för att registrera aktivitet i en databas när tabeller och rader har ändrats. Mer information om CDC-funktionen, inklusive hur den implementeras i SQL Server och Azure SQL Managed Instance, finns i What is change data capture (CDC)?

Överblick

I Azure SQL Database ersätter en schemaläggare för ändringsdatainsamling de SQL Server Agent-jobb som samlar in och rensar ändringsdata för källtabellerna. Schemaläggaren kör avbildnings- och rensningsprocesserna automatiskt i databasens omfång, vilket säkerställer tillförlitlighet och prestanda utan externa beroenden. Användarna behåller alternativet att initiera avbildnings- och rensningsprocesser manuellt efter behov.

Ett bra exempel på en datakonsument som används av den här tekniken är ett extraherings-, transformerings- och inläsningsprogram (ETL). Ett ETL-program läser in inkrementellt ändringsdata från SQL Server-källtabeller till ett informationslager eller ett dataarkiv. Även om representationen av källtabellerna i informationslagret måste återspegla ändringar i källtabellerna, är en teknik från slutpunkt till slutpunkt som uppdaterar en replik av källan inte lämplig. I stället behöver du en tillförlitlig dataström med ändringsdata som är strukturerade så att konsumenterna kan tillämpa dem på olika målrepresentationer av data. SQL Server-insamling av ändringsdata ger den här tekniken.

Mer information om insamling av ändringsdata i Azure SQL Database finns i det här avsnittet om data som exponeras:

Dataflöde

Följande bild visar huvuddataflödet för insamling av ändringsdata med Azure SQL Database:

Diagram över ett flödesdiagram som visar dataflödet för insamling av ändringsdata.

Förutsättningar

Behörigheter

Den db_owner rollen krävs för att aktivera insamling av ändringsdata för Azure SQL Database.

Beräkningskrav för Azure SQL Database

Du kan aktivera CDC på Azure SQL Database för valfri tjänstnivå i den vCore-baserade inköpsmodellen för både enskilda databaser och elastiska pooler.

För databaser i DTU-inköpsmodellstöds CDC för databaser på S3--nivån eller högre. Underkärnnivåer (Basic, S0, S1, S2) stöds inte för CDC.

Aktivera CDC för Azure SQL Database

Innan du kan skapa en avbildningsinstans för enskilda tabeller måste du aktivera CDC för din Azure SQL Database.

Om du vill aktivera CDC ansluter du till din Azure SQL Database via Azure Data Studio eller SQL Server Management Studio (SSMS). Öppna ett nytt frågefönster och aktivera sedan CDC genom att köra följande T-SQL:

EXEC sys.sp_cdc_enable_db;
GO

Not

För att avgöra om en databas redan är aktiverad, gör en fråga på kolumnen is_cdc_enabled i sys.databases-katalogvyn.

När ändringsdatainsamling är aktiverat för en databas skapas cdc schema, cdc user, metadatatabeller och andra systemobjekt för databasen. cdc schema innehåller metadatatabeller för ändringsdatainsamling och när cdc har aktiverats för källtabellerna fungerar de enskilda ändringstabellerna som en lagringsplats för ändringsdata. cdc schema innehåller även associerade systemfunktioner som används för att fråga efter ändringsdata.

Viktig

Ändringsdatainsamling kräver exklusiv användning av cdc schema och cdc user. Om antingen ett schema eller en databasanvändare med namnet cdc för närvarande finns i en databas kan du inte aktivera cdc för databasen förrän schemat och/eller användaren har släppts eller bytt namn.

Aktivera CDC för en tabell

När du har aktiverat CDC för din Azure SQL Database kan du sedan aktivera CDC på tabellnivå genom att välja en eller flera tabeller för att spåra dataändringar. Skapa en avbildningsinstans för enskilda källtabeller med hjälp av den lagrade proceduren sys.sp_cdc_enable_table.

Om du vill aktivera CDC för en tabell kör du följande T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL;
GO

Tips

I föregående exempel används inte en explicit @role_name genom att ange parametern till NULL, men du kan använda en gränssättande roll för att begränsa åtkomsten till de ändrade data.

Kolumner i källtabellen som ska avbildas

Som standard identifieras alla kolumner i källtabellen som insamlade kolumner. Om endast en delmängd av kolumnerna behöver spåras, till exempel av sekretess- eller prestandaskäl, använder du parametern @captured_column_list för att ange delmängden av kolumner.

Om du vill aktivera CDC för en specifik lista över kolumner i en tabell kör du följande T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @captured_column_list = N'Column1, Column2, Column3';
GO

Tips

Observera att föregående exempel inte använder en explicit @role_name eller anger parametern till NULL, dock kan du använda en gating-roll för att begränsa åtkomsten till ändringsinformation.

En roll för att styra åtkomsten till en ändringstabell

Syftet med den namngivna rollen är att styra åtkomsten till ändringsdata. Den angivna rollen kan vara en befintlig fast serverroll eller en databasroll. Om den angivna rollen inte redan finns skapas en databasroll med det namnet automatiskt. Användarna måste ha SELECT-behörighet för alla insamlade kolumner i källtabellen. När en roll anges måste dessutom användare som inte är medlemmar i sysadmin eller db_owner rollen också vara medlemmar i den angivna rollen.

Om du vill aktivera CDC för en tabell som specificerar en blockerande roll kör du följande T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = N'RoleName'
GO

Om du inte vill använda en gating-roll anger du uttryckligen parametern @role_name till NULL.

En funktion för att fråga efter nettoändringar

En instans för att fånga upp ändringar innehåller alltid en tabell-värdefunktion för att returnera alla poster i ändringstabellen som inträffat inom ett definierat intervall. Den här funktionen namnges genom att namnet på avbildningsinstansen läggs till i cdc.fn_cdc_get_all_changes_. Mer information finns i cdc.fn_cdc_get_all_changes.

Om parametern @supports_net_changes är inställd på 1 genereras även en funktion för nettoändringar för avbildningsinstansen. Den här funktionen returnerar endast en ändring för varje distinkt rad som ändrats i intervallet som anges i anropet. Mer information finns i cdc.fn_cdc_get_net_changes.

För att stödja frågor om nettoändringar måste källtabellen ha en primärnyckel eller ett unikt index för att unikt identifiera rader. Om ett unikt index används måste namnet på indexet anges med hjälp av parametern @index_name. Kolumnerna som definieras i primärnyckeln eller det unika indexet måste ingå i listan över källkolumner som ska avbildas.

Om du vill aktivera CDC för en tabell med stöd för nettoändringar kör du följande T-SQL:

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @supports_net_changes = 1
GO

Om insamling av ändringsdata är aktiverat i en tabell med en befintlig primärnyckel och parametern @index_name inte används för att identifiera ett alternativt unikt index, använder funktionen för att samla in ändringsdata den primära nyckeln. Efterföljande ändringar av primärnyckeln tillåts inte utan att du först inaktiverar insamling av ändringsdata för tabellen. Detta gäller oavsett om stöd för frågor om nettoändringar begärdes när insamling av ändringsdata konfigurerades.

Om det inte finns någon primärnyckel i en tabell när du aktiverar den för insamling av ändringsdata, ignoreras efterföljande tillägg av en primärnyckel av insamling av ändringsdata. Eftersom ändringsdatainsamling inte använder en primärnyckel som skapas efter att tabellen har aktiverats kan nyckel- och nyckelkolumnerna tas bort utan begränsningar.

Mer information om argumenten för sys.sp_cdc_enable_table lagrade procedurer finns i sys.sp_cdc_enable_table.

Tips

Om du vill ta reda på om en källtabell redan har aktiverats för insamling av ändringsdata undersöker du kolumnen is_tracked_by_cdc i sys.tables katalogvyn.

Inaktivera CDC för Azure SQL Database

Om du inaktiverar CDC för din Azure SQL Database tar du bort alla associerade metadata för insamling av ändringsdata, inklusive cdc user, cdc schemaoch de externa schemaläggningsprocesserna för insamling och rensning. Eventuella gatingroller som skapats av ändringsdatainsamling tas dock inte bort automatiskt och måste raderas uttryckligen.

Not

Om du vill ta reda på om en databas har cdc aktiverat frågar du kolumnen is_cdc_enabled i sys.databases katalogvyn.

Det är inte nödvändigt att inaktivera CDC för enskilda tabeller innan du inaktiverar CDC på databasnivå.

Om du vill inaktivera CDC på databasnivå kör du följande T-SQL:

EXEC sys.sp_cdc_disable_db;
GO

Tips

När du har inaktiverat CDC på databasnivå måste du aktivera CDC för enskilda tabeller igen om du vill använda CDC-funktionen igen.

Hantera CDC

I Azure SQL Database är CDC en viktig funktion för att spåra och hantera ändringar i dina databastabeller. Till skillnad från traditionella SQL Server-miljöer använder Azure SQL Database en schemaläggare för ändringsdatainsamling för att hantera CDC-uppgifter i stället för att förlita sig på SQL Server Agent-jobb. Den här schemaläggaren initierar automatiskt periodiska avbildnings- och rensningsprocesser för CDC-tabeller i databasen, vilket säkerställer tillförlitlighet och prestanda utan externa beroenden.

Automatisk CDC-insamling och rensning

CDC-avbildningsjobbet i Azure SQL Database fungerar sömlöst och körs var 20:e sekund för att spåra ändringar effektivt. Samtidigt körs rensningsjobbet varje timme, vilket säkerställer att DINA CDC-tabeller förblir optimerade. Användarna kan vara säkra på att CDC-hanteringen sker automatiskt utan manuella åtgärder.

Viktig

Om en serverlös databas har CDC aktiverat och är i pausat tillstånd körs inte CDC. CDC-genomsökningen påverkar inte funktionen för autopaus.

Manuell CDC-kontroll

Medan CDC körs automatiskt behåller användarna flexibiliteten att utföra manuella CDC-åtgärder på begäran. Med procedurerna sp_cdc_scan och sp_cdc_cleanup_change_tables kan du utlösa insamlings- och rensningsuppgifter efter behov.

Övervaka CDC

Azure SQL Database innehåller värdefulla verktyg för att övervaka CDC-aktiviteter. Två dynamiska hanteringsvyer, sys.dm_cdc_log_scan_sessions och sys.dm_cdc_errors, ger insikter om CDC-processer, vilket säkerställer att du har fullständig insyn i dina dataändringar.

CDC-anpassning

Även om Azure SQL Database effektiviserar CDC-hanteringen finns det vissa begränsningar:

Det går inte att anpassa frekvensen för CDC-insamlings- och rensningsjobb.
Värdena för pollinginterval och continuous för avbildnings- och rensningsjobb gäller inte i Azure SQL Database.
Om du tar bort posten för avbildningsjobbet från tabellen cdc.cdc_jobs stoppas inte bakgrundsavbildningsjobbet.
Om du släpper rensningsjobbposten stoppas rensningsjobbet.
Tabellen cdc.cdc_jobs finns i schemat cdc, inte msdb.

Trots dessa begränsningar kan du fortfarande anpassa följande alternativ:

Sök i cdc.cdc_jobs-tabellen för nuvarande konfigurationsdetaljer.
Justera alternativen för maxtrans och maxscans med hjälp av den sp_cdc_change_job lagrade proceduren.
Hantera jobb genom att använda sp_cdc_drop_job och sp_cdc_add_job efter behov.

Prestandaöverväganden och rekommendationer

Att aktivera insamling av ändringsdata för Azure SQL Database har en prestandaeffekt som kan jämföras med att aktivera CDC för SQL Server eller Azure SQL Managed Instance. Flera faktorer påverkar dock prestandaeffekten vid aktivering av CDC, inklusive:

Antalet CDC-aktiverade tabeller i Azure SQL Database.
Frekvens för ändringar i de spårade tabellerna eller volymen av transaktioner. Aktiva transaktioner förhindrar loggtrunkering tills transaktionen slutförs och CDC-genomsökningen hinner ikapp, eller tills transaktionen avbryts. Detta kan leda till att transaktionsloggen fylls i mer än vanligt och bör övervakas så att transaktionsloggen inte fylls.
Kontrollera att det finns ledigt utrymme i källdatabasen, eftersom CDC-artefakter (till exempel CT-tabeller, cdc_jobs osv.) lagras i samma databas.
Oavsett om du har en enskild databas eller en del av en elastisk pool.
Databaser i en elastisk pool delar resurser mellan sig (till exempel diskutrymme), vilket innebär att aktivering av CDC på flera databaser riskerar att nå den maximala storleken på den elastiska poolens diskutrymme. Övervaka resurser som CPU, minne och loggdataflöde. Mer information finns i Resurshantering i kompakta elastiska pooler.
När du hanterar databaser i elastiska pooler är det viktigt att överväga antalet CDC-aktiverade tabeller och antalet databaser som dessa tabeller tillhör. Vi rekommenderar att du utvärderar din arbetsbelastning och vidtar nödvändiga åtgärder, till exempel skalning av den elastiska poolen. För mer information, se Skala elastiska poolresurser i Azure SQL Database.

Viktig

Dessa överväganden är allmänna riktlinjer. För exakt vägledning för att optimera prestanda för en viss arbetsbelastning, kontakta Microsoft-support.

Tänk på följande metodtips när du använder CDC med Azure SQL Database:

Testa arbetsbelastningen noggrant innan du aktiverar CDC på databaser i produktion för att hjälpa dig att fastställa lämplig SLO-anpassning för din arbetsbelastning. Mer information om Beräkningsstorlekar för Azure SQL Database finns i Tjänstnivåer.
Överväg att skala antalet virtuella kärnor eller övergå till en högre databasnivå, till exempel Hyperskala, för att upprätthålla den tidigare prestandanivån när CDC har aktiverats på din Azure SQL Database. Mer information finns i köpmodell för virtuella kärnor – Azure SQL Database och Hyperskala-tjänstnivå.
Övervaka utrymmesutnyttjandet noggrant. Mer information finns i Hantera filutrymme för databaser i Azure SQL Database.
Övervaka loggenereringshastigheten, för mer information, se Resursförbrukning efter användararbetsbelastningar och interna processer.
CDC-genomsöknings- och rensningsprocesserna är en del av din vanliga databasarbetsbelastning (förbrukar även resurser). Beroende på volymen av transaktioner kan prestandaförsämringen vara betydande på grund av att genomsöknings- och rensningsprocesserna inte håller jämna steg med arbetsbelastningen eftersom hela rader läggs till i ändringstabeller och för uppdateringsåtgärder ingår även förhandsversion. Vi föreslår att du utvärderar din arbetsbelastning och vidtar nödvändiga åtgärder enligt de tidigare rekommendationerna. Mer information finns i avsnittet CDC-hantering i den här artikeln.

Viktig

Schemaläggaren kör hämtning och rensning automatiskt i SQL-databasen. CDC-avbildningsjobbet körs var 20:e sekund och rensningsjobbet körs varje timme.

För att förhindra en ökning av svarstiden kontrollerar du att antalet CDC-aktiverade databaser inte överskrider antalet virtuella kärnor som allokerats till en elastisk pool. Mer information finns i Resurshantering i kompakta elastiska pooler.
Baserat på din arbetsbelastning och prestandanivå bör du överväga att ändra CDC-kvarhållningsperioden till ett mindre antal än standardvärdet på tre dagar för att säkerställa att rensningsprocessen kan hålla jämna steg med ändringar i ändringstabellen. Det är bra att upprätthålla en lägre kvarhållningsperiod samtidigt som databasstorleken övervakas.
Inget serviceavtal (SLA) tillhandahålls när ändringar fylls i i ändringstabellerna. Svarstid på undersekunder stöds inte heller.

Kända problem och begränsningar

Aggressiv loggtrunkering

När du aktiverar CDC (Change Data Capture) i Azure SQL Database inaktiveras den aggressiva loggtrunkeringsfunktionen i Accelerated Database Recovery (ADR). Det beror på att CDC-genomsökningen kommer åt databastransaktionsloggen. Aktiva transaktioner förhindrar trunkering av transaktionsloggen tills CDC-genomsökningen kommer ikapp, eller så avbryts transaktionen.

När du aktiverar CDC rekommenderar vi att du använder det återanvändbara indexalternativet när du skapar eller återskapar ett index. Index som kan återupptas håller inte en tidskrävande transaktion öppen och tillåter loggtrunkering under åtgärden för bättre hantering av loggutrymme. Mer information finns i Guidelines for online index operations – Resumable Index considerations.

Tjänstnivå för Azure SQL Database

CDC stöds för databaser och elastiska pooler i alla tjänstnivåer i den vCore-baserade inköpsmodellen, men databaser som är lägre än S3- (till exempel Basic, S0, S1, S2) stöds inte i DTU-inköpsmodell.

Logggränser för Azure SQL Database

Accelererad databasåterställning och CDC är kompatibla. Det aggressiva loggtrunkeringsbeteendet för ADR inaktiveras dock när CDC är aktiverat. Det beror på att CDC-genomsökningen aktivt kommer åt och interagerar med databastransaktionsloggen, vilket förhindrar ADRs aggressiva beteende vid loggtrunkering.

När du aktiverar CDC kan du observera högre transaktionslogganvändning. Du kan behöva skala upp till en högre tjänstnivå eller beräkningsstorlek för att säkerställa att tillräckligt med transaktionsloggutrymme är tillgängligt för alla dina arbetsbelastningars behov.

Tips

Om din arbetsbelastning kräver högre övergripande prestanda på grund av högre dataflöde för transaktionsloggar och snabbare transaktionsincheckningstider använder du tjänstnivån Hyperskala.

Online DDL-uttalanden stöds inte

Online DDL-instruktioner stöds inte när ändringsdatafångst är aktiverat på en databas.

Anpassning av datainsamling och datarensning

Det går inte att konfigurera insamlingsfrekvensen och rensningsprocesserna för CDC i Azure SQL Databases. Schemaläggaren kör inspelning och rensning automatiskt.

Redundans i Azure SQL Database

I lokala eller GeoDR-failover-scenarier, om din databas har CDC aktiverad, sker processen för att samla in och rensa dataändringar automatiskt på den nya primära databasen efter att failover har inträffat.

Microsoft Entra ID

Not

Microsoft Entra ID tidigare kallades Azure Active Directory (Azure AD).

Om du skapar en databas i Azure SQL Database som Microsoft Entra-användare och aktiverar CDC på den kan en SQL-användare (till exempel en i sysadmin roll) inte inaktivera/göra ändringar i CDC-artefakter. En annan Microsoft Entra-användare kan dock aktivera/inaktivera CDC på samma databas.

På samma sätt fungerar det inte att aktivera eller avaktivera change data capture som en Microsoft Entra-användare om du skapar en databas som SQL-användare.

Det går inte att aktivera CDC om du skapar en databas i Azure SQL Database som Microsoft Entra-användare, inte aktiverar CDC och sedan försöker aktivera CDC när du har återställt databasen.

Lös problemet genom att ansluta till databasen med ditt Microsoft Entra-administratörskonto och köra följande T-SQL:

ALTER AUTHORIZATION ON DATABASE::[<restored_db_name>] TO [<azuread_admin_login_name>];

EXEC sys.sp_cdc_enable_db;

Återställning till en viss tidpunkt (PITR)

Om du har aktiverat CDC på Azure SQL Database som SQL-användare behåller PITR (Point-in-time-restore) CDC i den återställde databasen, såvida den inte återställs till ett SLO med underkärnor. Om de återställs till ett subcore-SLO är CDC-artefakter inte tillgängliga.

Om du aktiverar CDC på din databas som Microsoft Entra-användare går det inte att återställa till en viss tidpunkt (PITR) till ett SLO med sub-core-prestanda. Återställ databasen till samma eller högre SLO som källan och inaktivera cdc om det behövs.

Felsökning

Det här avsnittet innehåller vägledning och felsökningssteg som är associerade med CDC i Azure SQL Database. CDC-relaterade fel kan hindra avbildningsprocessens funktion och leda till att databastransaktionsloggen utökas.

Om du vill undersöka dessa fel kan du använda den dynamiska hanteringsvyn sys.dm_cdc_errors. Om den sys.dm_cdc_errors dynamiska hanteringsvyn returnerar eventuella fel kan du läsa följande avsnitt för att förstå åtgärdsstegen.

Notera

Mer information om en viss felkod finns i Händelser och fel i databasmotorn.

Det här är de olika felsökningskategorierna som ingår i det här avsnittet:

Kategori	Beskrivning
Metadata har ändrats	Innehåller information om hur du åtgärdar problem som rör CDC när den spårade tabellen har ändrats eller tagits bort.
Databasutrymmeshantering	Innehåller information om hur du åtgärdar problem när databasutrymmet har uttömts.
CDC-begränsning	Innehåller information om hur du åtgärdar problem som orsakas av CDC-begränsningar.

Metadata har ändrats

Fel 200/208 – Ogiltigt objektnamn

Orsak: Felet kan inträffa när CDC-metadata har tagits bort. För att CDC ska fungera korrekt bör du inte ändra cdc-metadata manuellt, till exempel CDC schema, ändra tabeller, lagrade procedurer för CDC-system, standardbehörigheter cdc user (sys.database_principals) eller byta namn på cdc user.
Rekommendation: För att lösa det här problemet måste du inaktivera och återaktivera CDC för databasen. När du aktiverar insamling av ändringsdata för en databas skapas cdc-schemat, cdc-användaren, metadatatabellerna och andra systemobjekt för databasen. Du måste manuellt aktivera CDC för enskilda tabeller efter att CDC har aktiverats för databasen.

Anteckning

Objekt som finns i sys.objects systemkatalogvyn med is_ms_shipped=1 och schema_name=cdc bör inte ändras eller tas bort.

Fel 1202 – Databasens huvudnamn finns inte eller så är användaren inte medlem

Orsak: Felet kan inträffa när CDC-användaren har tagits bort. För att CDC ska fungera korrekt bör du inte manuellt ändra CDC-metadata, till exempel CDC schema, ändra tabeller, CDC-systemlagrade procedurer, standardbehörigheter för cdc user (sys.database_principals) eller byta namn på cdc user.
Rekommendation: Kontrollera att cdc användaren finns i databasen och att db_owner rollen har tilldelats. Om du vill skapa cdc användare kan du läsa exemplet Skapa cdc-användare och tilldela roll.

Fel 15517 – Det går inte att köra som databasprincipalen eftersom principalen inte finns.

Orsak: Den här typen av huvudnamn kan inte personifieras eller så har du inte behörighet. Felet kan inträffa om CDC-metadata har tagits bort eller om det inte längre är en del av db_owner-rollen. För att CDC ska fungera korrekt bör du inte manuellt ändra CDC-metadata, till exempel CDC schema, ändra tabeller, CDC-systemlagrade procedurer, standardbehörigheter cdc user (sys.database_principals) eller byta namn på cdc user.
Rekommendation: Kontrollera att cdc användaren finns i databasen och att db_owner rollen har tilldelats. Om du vill skapa cdc användare kan du läsa exemplet Skapa cdc-användare och tilldela roll.

Fel 18807 – Det går inte att hitta ett objekt-ID för replikeringssystemets tabell

Orsak: Det här felet inträffar när SQL Server-databasmotorn inte kan hitta eller komma åt replikeringssystemtabellen%s. Tabellen kanske saknas eller kan inte nås. För att CDC ska fungera korrekt ändrar du inte CDC-metadata manuellt, till exempel CDC schema, ändringstabeller, CDC-systemlagrade procedurer, standardbehörigheter cdc user (sys.database_principals) eller byter namn på cdc user.
Rekommendation: Kontrollera att systemtabellen finns och är tillgänglig genom att fråga tabellen direkt. Utför en sökning i systemkatalogen sys.objects och ställ in predikatsatsen med is_ms_shipped=1 och schema_name=cdc för att lista alla CDC-relaterade objekt. Om frågan inte returnerar några objekt bör du inaktivera och sedan återaktivera CDC för databasen. Om du aktiverar insamling av ändringsdata för en databas skapas cdc schema, cdc user, metadatatabeller och andra systemobjekt för databasen. Du måste aktivera CDC manuellt för enskilda tabeller när CDC har aktiverats för databasen.

Fel 21050 – Endast medlemmar i sysadmin- eller db_owner fast serverroll kan utföra den här åtgärden

Orsak: Den cdc användaren har tagits bort från db_owner-databasrollen eller från sysadmin-serverrollen.
Rekommendation: Kontrollera att cdc användaren har tilldelats db_owner roll. Om du vill skapa cdc användare kan du läsa exemplet Skapa cdc-användare och tilldela roll.

Hantering av databasutrymme

Fel 1105 – Det gick inte att allokera utrymme för objektet i databasen eftersom filgruppen är full

Orsak: Det här felet uppstår när den primära filgruppen för en databas får slut på utrymme och SQL Database inte kan allokera mer utrymme för ett objekt (till exempel en tabell eller ett index) i den filgruppen.
Rekommendation: Lös problemet genom att ta bort onödiga data i databasen för att frigöra utrymme. Identifiera oanvända tabeller, index eller andra objekt i filgruppen som kan tas bort på ett säkert sätt. Övervaka utrymmesanvändningen noggrant. Mer information finns i Hantera filutrymme för databaser i Azure SQL Database.

Om onödiga data/objekt tas bort inte är ett alternativbör du överväga att skala till en högre databasnivå.

Viktig

Detaljerad information om beräkningsstorlekar för Azure SQL Database (enskild databas) finns i Resursgränser för enskild databas med köpmodellen för virtuella kärnor och Resursgränser för enskild databas med DTU-inköpsmodellen – Azure SQL Database.

Fel 1132 – Den elastiska poolen har nått sin lagringsgräns

Orsak: Det här felet uppstår när lagringsanvändningen i den elastiska poolen har överskridit den allokerade gränsen.
Rekommendation: Lös problemet genom att implementera strategier för dataarkivering och rensning för att endast behålla nödvändiga data i de databaser som ingår i den elastiska poolen. Övervaka utrymmesutnyttjandet noggrant. Mer information finns i Hantera filutrymme för databaser i Azure SQL Database.

Om det inte är ett alternativ att arkivera data eller ta bort onödiga data/objekt kan du överväga att skala till en högre databasnivå.

Viktig

Detaljerad information om beräkningsstorlekar för Azure SQL Database (enkel databas) finns i Resursgränser för elastiska pooler med köpmodellen för virtuella kärnor och Resursgränser för elastiska pooler med DTU-inköpsmodellen.

CDC-begränsning

Fel 2628 – sträng- eller binärdata trunkeras i tabellen

Orsak: Om du ändrar storleken på kolumner i en CDC-aktiverad tabell med DDL-instruktioner kan det orsaka problem med den efterföljande CDC-avbildningsprocessen. Den dynamiska hanteringsvyn sys.dm_cdc_errors (DMV) är användbar för att kontrollera eventuella CDC-problem, till exempel fel nummer 2628 och 8115.
Rekommendation: Innan du gör ändringar i kolumnstorleken måste du utvärdera om ändringen är kompatibel med befintliga data i CDC-ändringstabeller. För att lösa det här problemet måste du inaktivera och återaktivera CDC för databasen. Mer information om hur du aktiverar CDC för en databas eller en tabell finns i Aktivera CDC för Azure SQL Database och Aktivera CDC för en tabell avsnitt i den här artikeln.

Fel 22830 – Inbyggd funktion "SUSER_SNAME" i personifieringskontext stöds inte i den här versionen av SQL Server

Orsak: Det här felet inträffar när CDC aktiveras om det finns en användarutlösare i databasen, som har ett anrop till SUSER_SNAME() på create_table. Du kan lista utlösare med följande Transact-SQL skript. Det här kommandot ger information om objektutlösaren och motsvarande object_id:
```
SELECT name,
    object_id
FROM sys.triggers
WHERE parent_class_desc = 'DATABASE'
    AND is_disabled = 0;
```
När du får utlösardefinitionerna kan du söka efter anrop som görs till SYSTEM_USER med följande skript:
```
SELECT OBJECT_DEFINITION(object_id) AS trigger_definition;
```
Rekommendation: Lös problemet genom att följa dessa steg för varje användarutlösare som hämtades från föregående skript.
- Inaktivera utlösaren
- Aktivera CDC
- Återaktivera utlösaren

Mer information finns i INAKTIVERA TRIGGERSYSTEM.

Fel 913 – CDC-avbildningsjobb misslyckas när ändringar bearbetas för en tabell med system-CLR-datatyp

Orsak: Det här felet uppstår när CDC aktiveras i en tabell med system-CLR-datatypen, gör DML-ändringar och sedan gör DDL-ändringar i samma tabell medan CDC-avbildningsjobbet bearbetar ändringar relaterade till andra tabeller.
Rekommendation: De rekommenderade stegen är att pausa DML för tabellen, köra ett fångstjobb för att bearbeta ändringar, köra DDL för tabellen, köra ett fångstjobb för att bearbeta DDL-ändringar och sedan återuppta DML-bearbetning. Mer information finns i , när CDC-avbildningsjobb misslyckas vid bearbetning av ändringar för en tabell med system-CLR-datatyp (geometri, geografi eller hierarkiid).

Skapa användare och tilldela roll

Om cdc user har tagits bort kan du lägga till användaren igen manuellt.

Använd följande T-SQL-skript för att skapa en användare (cdc) och tilldela rätt roll (db_owner).

IF NOT EXISTS (
    SELECT *
    FROM sys.database_principals
    WHERE NAME = 'cdc'
)
BEGIN
    CREATE USER [cdc] WITHOUT LOGIN
    WITH DEFAULT_SCHEMA = [cdc];
END

EXEC sp_addrolemember 'db_owner', 'cdc';

Kontrollera och lägg till rollmedlemskap

Kontrollera om cdc användare tillhör rollen sysadmin eller db_owner genom att köra följande T-SQL-fråga:

EXECUTE AS USER = 'cdc';

SELECT is_srvrolemember('sysadmin'), is_member('db_owner');

Om cdc användaren inte tillhör någon av rollerna kör du följande T-SQL-fråga för att lägga till db_owner roll i cdc användaren.

EXEC sp_addrolemember 'db_owner' , 'cdc';

Dela via

Ändra datainsamling (CDC) med Azure SQL Database

Överblick

Dataflöde

Förutsättningar

Behörigheter

Beräkningskrav för Azure SQL Database

Aktivera CDC för Azure SQL Database

Aktivera CDC för en tabell

Kolumner i källtabellen som ska avbildas

En roll för att styra åtkomsten till en ändringstabell

En funktion för att fråga efter nettoändringar

Inaktivera CDC för Azure SQL Database

Hantera CDC

Automatisk CDC-insamling och rensning

Manuell CDC-kontroll

Övervaka CDC

CDC-anpassning

Prestandaöverväganden och rekommendationer

Kända problem och begränsningar

Aggressiv loggtrunkering

Tjänstnivå för Azure SQL Database

Logggränser för Azure SQL Database

Online DDL-uttalanden stöds inte

Anpassning av datainsamling och datarensning

Redundans i Azure SQL Database

Microsoft Entra ID

Återställning till en viss tidpunkt (PITR)

Felsökning

Metadata har ändrats

Fel 200/208 – Ogiltigt objektnamn

Fel 1202 – Databasens huvudnamn finns inte eller så är användaren inte medlem

Fel 15517 – Det går inte att köra som databasprincipalen eftersom principalen inte finns.

Fel 18807 – Det går inte att hitta ett objekt-ID för replikeringssystemets tabell

Fel 21050 – Endast medlemmar i sysadmin- eller db_owner fast serverroll kan utföra den här åtgärden

Hantering av databasutrymme

Fel 1105 – Det gick inte att allokera utrymme för objektet i databasen eftersom filgruppen är full

Fel 1132 – Den elastiska poolen har nått sin lagringsgräns

CDC-begränsning

Fel 2628 – sträng- eller binärdata trunkeras i tabellen

Fel 22830 – Inbyggd funktion "SUSER_SNAME" i personifieringskontext stöds inte i den här versionen av SQL Server

Fel 913 – CDC-avbildningsjobb misslyckas när ändringar bearbetas för en tabell med system-CLR-datatyp

Skapa användare och tilldela roll

Kontrollera och lägg till rollmedlemskap

Relaterat innehåll

Feedback

Ytterligare resurser