Ändra datainsamling (CDC) med Azure SQL Database

Gäller för:Azure SQL Database

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 CDC med SQL Server.

Översikt

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:

Förutsättningar

Behörigheter

Rollen db_owner 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 vilken tjänstnivå som helst inom den vCore-baserade inköpsmodellen för både enskilda databaser och elastiska pooler.

För databaser i DTU-inköpsmodellen stö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

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

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 insamlingsinstans 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

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

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 antingen sysadmin - eller db_owner-rollen också vara medlemmar i den angivna rollen.

Om du vill aktivera CDC för tabell som anger en gating-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 avbildningsinstans innehåller alltid en tabellvärdesfunktion för att returnera alla ändringstabellposter som inträffat inom ett definierat intervall. Den här funktionen namnges genom att namnet på avbildningsinstansen läggs till cdc.fn_cdc_get_all_changes_i . 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 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 infångade ä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 avbilda ä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 den är aktiverad 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 lagrad sys.sp_cdc_enable_table procedur finns i sys.sp_cdc_enable_table (Transact-SQL).

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 processerna cdc user, cdc schemaoch den externa schemaläggarens insamling och rensning. Eventuella gating-roller som skapats av ändringsdatainsamling tas dock inte bort automatiskt och måste tas bort uttryckligen.

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

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.

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 avbildnings- 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-avbildnings- och rensningsjobb.
• Värdena pollinginterval och continuous för insamlings- och rensningsjobb gäller inte i Azure SQL Database.
• Om du tar bort posten för avbildningsjobbet cdc.cdc_jobs från tabellen stoppas inte bakgrundsinsamlingsjobbet.
• 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:

• Fråga tabellen cdc.cdc_jobs om du vill ha aktuell konfigurationsinformation.
• Justera alternativen maxtrans och maxscans med den sp_cdc_change_job lagrade proceduren.
• Hantera jobb genom att sp_cdc_drop_job använda 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 transaktionsgenomsökningen och CDC-genomsökningen kommer ikapp, eller så avbryts transaktionen. 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 resursen mellan dem (till exempel diskutrymme), vilket innebär att CDC på flera databaser riskerar att nå den maximala storleken på den elastiska pooldiskens storlek. Ö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. Mer information finns i Skala elastiska poolresurser i Azure SQL Database.

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öpmodellen för virtuella kärnor – Azure SQL Database och tjänstnivån Hyperskala.

• Övervaka utrymmesutnyttjandet noggrant. Mer information finns i Hantera filutrymme för databaser i Azure SQL Database.

• Övervaka logggenereringshastigheten, mer information finns i 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.

• 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 transaktionsloggar tills transaktionsgenomsökningen och CDC-genomsökningen kommer ikapp, eller så avbryts transaktionen. Detta kan leda till att transaktionsloggen fylls i mer än vanligt och bör övervakas så att transaktionsloggen inte fylls.

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 Riktlinjer för onlineindexåtgärder – Överväganden för återupptagande av index.

Tjänstnivå för Azure SQL Database

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

Logggränser för Azure SQL Database

Accelererad databasåterställning och CDC är inte kompatibla i Azure SQL Database. Det beror på att CDC-genomsökningen aktivt kommer åt och interagerar med databastransaktionsloggen, vilket kan vara i konflikt med adr:s aggressiva beteende för loggtrunkering.

För att förhindra problem med skalbarhet och utrymmeshantering bör du noga övervaka din Azure SQL Database och överväga att skala till en högre databasnivå och låta transaktionsloggen växa enligt dina arbetsbelastningsbehov.

Anpassning av insamling och rensning

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

Redundans i Azure SQL Database

I händelse av lokala redundansscenarier eller GeoDR-redundansscenarier, om databasen har CDC aktiverat, sker processen för att samla in och rensa dataändringar automatiskt på den nya primära databasen efter redundansväxlingen.

Microsoft Entra-ID

Om du skapar en databas i Azure SQL Database som Microsoft Entra-användare och aktiverar CDC på den sysadmin , kan en SQL-användare (till exempel en i rollen) 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 inte aktivering/inaktivering av ändringsdatainsamling 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 tidpunkt (PITR)

Om du har aktiverat CDC på din 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 SLO med underkärnor ä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 tidpunkt (PITR) till ett SLO med underkärnor. Å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 fråga den dynamiska hanteringsvyn sys.dm_cdc_errors. Om den sys.dm_cdc_errors dynamiska hanteringsvyn returnerar några fel kan du läsa följande avsnitt för att förstå åtgärdsstegen.

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

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 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: 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 återaktivera CDC för enskilda tabeller manuellt när CDC har aktiverats för databasen.

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 cdc user (sys.database_principals) eller byta cdc usernamn på .

• Rekommendation: Se till att cdc användaren finns i databasen och har även rollen db_owner tilldelad. Information om hur du skapar användaren finns i cdc exemplet Skapa cdc-användare och tilldela roll.

Fel 15517 – Det går inte att köra som databasens huvudnamn eftersom huvudkontot inte finns

• Orsak: Den här typen av huvudnamn kan inte personifieras eller så har du inte behörighet. Felet kan inträffa när CDC-metadata har tagits bort eller 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-systemlagringsprocedurer, standardbehörigheter cdc user (sys.database_principals) eller byta namn på cdc user.

• Rekommendation: Se till att cdc användaren finns i databasen och har även rollen db_owner tilldelad. Information om hur du skapar användaren finns i cdc 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 inte kan hitta eller komma åt replikeringssystemtabellen %s. Det kan bero på att tabellen saknas eller inte kan nås. CDC för att 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 systemtabellen finns och är tillgänglig genom att fråga tabellen direkt. Fråga systemkatalogen sys.objects , ange predikatsatsen med is_ms_shipped=1 och schema_name=cdc för att visa en lista över 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 återaktivera CDC för enskilda tabeller manuellt 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: Användaren cdc har tagits bort från databasrollen db_owner eller från serverrollen sysadmin .

• Rekommendation: Kontrollera att cdc användaren har tilldelats db_owner rollen. Information om hur du skapar användaren finns i cdc 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 det inte är ett alternativ att ta bort onödiga data/objekt bör du överväga att skala till en högre databasnivå.

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å.

CDC-begränsning

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

• Orsak: Om du ändrar storleken på kolumnerna i en CDC-aktiverad tabell med DDL-instruktioner kan det orsaka problem med den efterföljande CDC-avbildningsprocessen. Dynamisk sys.dm_cdc_errors hanteringsvy (DMV) är ett användbart sätt att kontrollera eventuella CDC-problem, till exempel felnummer 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 ett tabellavsnitt 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 DISABLE TRIGGER (Transact-SQL).

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 du aktiverar CDC 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 skicka DML till tabellen, köra ett avbildningsjobb för att bearbeta ändringar, köra DDL för tabellen, köra ett avbildningsjobb för att bearbeta DDL-ändringar och sedan återaktivera DML-bearbetning. Mer information finns i CDC-avbildningsjobb misslyckas när ändringar bearbetas.

Skapa användare och tilldela roll

Om har cdc user 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ändaren tillhör antingen sysadmin rollen 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 användaren cdc inte tillhör någon av rollerna kör du följande T-SQL-fråga för att lägga db_owner till rollen i cdc användaren.

EXEC sp_addrolemember 'db_owner' , 'cdc';

Relaterat innehåll

• Arbeta med ändringsdata
• Spåra dataändringar
• Administrera och övervaka insamling av ändringsdata
• Temporala tabeller