Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:
SQL ServerAzure SQL DatabaseAzure SQL Managed Instance
Ändringstabellen som skapas när ändringsdatafångst aktiveras i en källtabell. Tabellen returnerar en rad för varje insättnings- och borttagningsoperation som utförs mot källtabellen, och två rader för varje uppdateringsoperation som utförs mot källtabellen. När namnet på ändringstabellen inte anges vid tidpunkten då källtabellen aktiveras, härleds namnet. Namnet har cdc. capture_instance_CT där capture_instance är schemanamnet på källtabellen och källtabellens namn i formatet schema_table. Till exempel, om tabellen Person.Address i AdventureWorks-exempeldatabasen är aktiverad för insamling av förändringsdata, skulle namnet på den härledda förändringstabellen vara cdc.Person_Address_CT.
Vi rekommenderar att du inte frågar systemtabellerna direkt. Utför istället funktionerna cdc.fn_cdc_get_all_changes_<capture_instance> och cdc.fn_cdc_get_net_changes_<capture_instance> .
| Kolumnnamn | Datatyp | Description |
|---|---|---|
| __$start_lsn | binary(10) | Loggsekvensnummer (LSN) kopplat till commit-transaktionen för ändringen. Alla ändringar som gjorts i samma transaktion delar samma commit-LSN. Till exempel, om en borttagningsoperation på källtabellen tar bort två rader, innehåller ändringstabellen två rader, var och en med samma __$start_lsn värde. |
| __$end_lsn | binary(10) | Identifieras endast i informationssyfte. Stöds inte. Framtida kompatibilitet garanteras inte. I SQL Server 2012 (11.x) är denna kolumn alltid NULL. |
| __$seqval | binary(10) | Sekvensen av operationen som representeras i transaktionsloggen. Bör inte användas för beställning. Använd istället kolumnen __$command_id . |
| __$operation | int | Identifierar datamanipulationsspråket (DML)-operationen som är kopplad till ändringen. Kan vara något av följande: 1 = ta bort 2 = infoga 3 = uppdatering (gamla värden) Kolumndata har radvärden innan uppdateringssatsen exekveras. 4 = uppdatering (nya värden) Kolumndata har radvärden efter att uppdateringssatsen exekverats. |
| __$update_mask | varbinary(128) | En bitmask baserad på kolumnordningen i ändringstabellen som identifierar de kolumner som ändrats. |
| <Kolumner för fångade källtabeller> | varies | De återstående kolumnerna i ändringstabellen är de kolumner från källtabellen som identifierades som fångade kolumner när fångstinstansen skapades. Om inga kolumner specificerades i listan över fångade kolumner inkluderas alla kolumner i källtabellen i denna tabell. |
| __$command_id | int | Följer ordningen på operationer inom en transaktion. |
Anmärkningar
Kolumnen __$command_id introducerades i en kumulativ uppdatering i versionerna 2012 till 2016. För versions- och nedladdningsinformation, se KB-artikeln 3030352 på FIX: Förändringstabellen är felaktigt ordnad för uppdaterade rader efter att du aktiverat ändringsdatainsamling för en Microsoft SQL Server-databas. För mer information, se CDC:s funktionalitet kan gå sönder efter uppgradering till den senaste CU för SQL Server 2012, 2014 och 2016.
Fångade kolumndatatyper
Fångade kolumner som ingår i denna tabell har samma datatyp och värde som motsvarande källkolumner med följande undantag:
Tidsstämpelkolumner definieras som binär(8).
Identitetskolumner definieras som antingen int eller bigint.
Dock är värdena i dessa kolumner desamma som källkolumnens värden.
Stora objektdatatyper
Kolumner med datatyp , bild, text och ntext tilldelas alltid ett NULL-värde när __$operation = 1 eller __$operation = 3. Kolumner av datatypen varbinary(max),varchar(max) eller nvarchar(max) tilldelas ett NULL-värde när __$operation = 3 om inte kolumnen ändrades under uppdateringen. När __$operation = 1 tilldelas dessa kolumner sitt värde vid tidpunkten för borttagningen. Beräknade kolumner som ingår i en fångstinstans har alltid värdet NULL.
Som standard är den maximala storleken som kan läggas till en fångad kolumn i en enda INSERT, UPDATE, WRITETEXT eller UPDATETEXT-sats 65 536 byte eller 64 KB. För att öka denna storlek och stödja större LOB-data, använd alternativet Konfigurera maxtextrepl-storlek Serverkonfiguration för att ange en större maximal storlek. För mer information, se Konfigurera serverkonfigurationsalternativet för maximal textreplansstorlek.
Ändringar av datadefinitionsspråk
DDL-ändringar i källtabellen, såsom att lägga till eller ta bort kolumner, registreras i cdc.ddl_history tabellen. Dessa ändringar tillämpas inte på ändringstabellen. Det vill säga, definitionen av förändringstabellen förblir konstant. När rader infogas i ändringstabellen ignorerar fångstprocessen de kolumner som inte finns med i den fångade kolumnlistan kopplad till källtabellen. Om en kolumn förekommer i listan över fångade kolumner som inte längre finns i källtabellen, tilldelas kolumnen ett nollvärde.
Ändring av datatypen för en kolumn i källtabellen registreras också i cdc.ddl_history tabellen. Denna förändring ändrar dock definitionen av förändringstabellen. Datatypen för den fångade kolumnen i ändringstabellen ändras när fångstprocessen stöter på loggposten för DDL-ändringen som gjorts i källtabellen.
Om du behöver ändra datatypen för en fångad kolumn i källtabellen på ett sätt som minskar storleken på datatypen, använd följande procedur för att säkerställa att motsvarande kolumn i ändringstabellen kan ändras framgångsrikt.
I källtabellen, uppdatera värdena i kolumnen som ska ändras för att passa den planerade datatypsstorleken. Till exempel, om du ändrar datatypen från int till smallint, uppdatera värdena till en storlek som passar in i smallint-intervallet , -32 768 till 32 767.
I ändringstabellen, utför samma uppdateringsoperation på motsvarande kolumn.
Ändra källtabellen genom att specificera den nya datatypen. Datatypsändringen propageras framgångsrikt till ändringstabellen.
Modifieringar av datamanipulationsspråk
När insättnings-, uppdaterings- och borttagningsoperationer utförs på en källtabell aktiverad för förändringsdatainsamling, visas en post över dessa DML-operationer i databasens transaktionslogg. Processen för insamling av förändringsdata hämtar information om dessa ändringar från transaktionsloggen och lägger till antingen en eller två rader i ändringstabellen för att registrera ändringen. Posterna läggs till i ändringstabellen i samma ordning som de sattes in i källtabellen. Med det sagt måste commit av ändringstabellposter vanligtvis utföras på en grupp ändringar snarare än per varje post.
En insättningsoperation resulterar i att en rad läggs till i ändringstabellen; en borttagningsoperation resulterar i att en rad läggs till i ändringstabellen; om SQL Server implementerar en uppdatering som en "uppskjuten uppdatering", vilket betyder som ett par av borttagnings- och insättningsoperationer, resulterar uppdateringsoperationen i två rader som läggs till i ändringstabellen: den första raden som speglar raderingen av den infångade datan, och den andra raden som visar insättningen av den uppdaterade, infångade datan; om SQL Server inte implementerar en uppdatering som en "uppskjuten uppdatering" resulterar uppdateringsoperationen i två rader som läggs till i ändringstabellen: den första raden som återspeglar den infångade datan före uppdateringen, och den andra raden som återspeglar den infångade datan efter uppdateringen.
Inom ändringstabellposten används kolumnen __$start_lsn för att registrera det commit-LSN som är kopplat till ändringen i källtabellen, kolumnen __$command_id används för att ordna ändringen inom sin transaktion, och kolumnen __$operation används för att registrera den utförda operationen. Tillsammans kan dessa metadatakolumner användas för att säkerställa att commitordningen för källändringarna bevaras. Eftersom fångstprocessen hämtar sin ändringsinformation från transaktionsloggen är det viktigt att notera att ändringstabellposter inte visas synkront med motsvarande källtabellsändringar. Istället visas motsvarande ändringar asynkront, efter att fångstprocessen har bearbetat relevanta ändringsposter från transaktionsloggen.
För insättnings- och borttagningsoperationer är alla bitar i uppdateringsmasken satta. För uppdateringsoperationer kommer uppdateringsmasken i både raderna för att uppdatera gammal och uppdatera nya att ändras för att spegla de kolumner som ändrades under uppdateringen.
Se även
sys.sp_cdc_enable_table (Transact-SQL)
sys.sp_cdc_get_ddl_history (Transact-SQL)