CDC.<>capture_instance_CT (Transact-SQL)
Si applica a: SQL Server database SQL di Azure Istanza gestita di SQL di Azure
Tabella delle modifiche creata quando Change Data Capture è abilitato in una tabella di origine. La tabella restituisce una riga per ogni operazione di inserimento ed eliminazione eseguita nella tabella di origine e due righe per ogni operazione di aggiornamento eseguita nella tabella di origine. Quando il nome della tabella delle modifiche non viene specificato al momento dell'abilitazione della tabella di origine, viene derivato il nome. Il formato del nome è cdc.capture_instance_CT dove capture_instance è il nome dello schema della tabella di origine e il nome della tabella di origine nel formato schema_table. Ad esempio, se la tabella Person.Address nel database di esempio AdventureWorks è abilitata per Change Data Capture, il nome della tabella delle modifiche derivata sarà cdc.Person_Address_CT.
È consigliabile non eseguire direttamente query sulle tabelle di sistema. Eseguire invece le funzioni cdc.fn_cdc_get_all_changes_<capture_instance> e cdc.fn_cdc_get_net_changes_<capture_instance>.
Nome colonna | Tipo di dati | Descrizione |
---|---|---|
__$start_lsn | binary(10) | Numero di sequenza del file di log (LSN) associato alla transazione commit per la modifica. Tutte le modifiche di cui è stato eseguito il commit nella stessa transazione condividono lo stesso valore LSN di commit. Ad esempio, se un'operazione di eliminazione nella tabella di origine rimuove due righe, la tabella delle modifiche contiene due righe, ognuna con lo stesso valore __$start_lsn . |
__$end_lsn | binary(10) | Identificato solo a scopo informativo. Non supportato. Non è garantita la compatibilità con le versioni future. In SQL Server 2012 (11.x), questa colonna è sempre NULL. |
__$seqval | binary(10) | Sequenza dell'operazione come rappresentata nel log delle transazioni. Non deve essere utilizzato per l'ordinamento. Usare invece la colonna __$command_id . |
__$operation | int | Identifica l'operazione DML (Data Manipulation Language) associata alla modifica. Può essere uno dei seguenti: 1 = eliminazione 2 = inserimento 3 = aggiornamento (valori obsoleti) I dati della colonna includono valori di riga prima dell'esecuzione dell'istruzione di aggiornamento. 4 = aggiornamento (valori nuovi) I dati della colonna includono valori di riga dopo l'esecuzione dell'istruzione di aggiornamento. |
__$update_mask | varbinary(128) | Maschera di bit basata su numeri ordinali di colonna della tabella delle modifiche che identificano le colonne modificate. |
<colonne della tabella di origine acquisite> | variabile | Le colonne rimanenti della tabella delle modifiche sono le colonne della tabella di origine identificate come colonne acquisite durante la creazione dell'istanza di acquisizione. Se non è stata specificata alcuna colonna nell'elenco delle colonne acquisite, tutte le colonne della tabella di origine vengono incluse in questa tabella. |
__$command_id | int | Tiene traccia dell'ordine delle operazioni all'interno di una transazione. |
Osservazioni:
La __$command_id
colonna è stata introdotta in un aggiornamento cumulativo nelle versioni da 2012 a 2016. Per informazioni sulla versione e sul download, vedere l'articolo della Knowledge Base 3030352 in FIX: la tabella delle modifiche viene ordinata in modo non corretto per le righe aggiornate dopo aver abilitato Change Data Capture per un database di Microsoft SQL Server. Per altre informazioni, vedere La funzionalità CDC potrebbe interrompersi dopo l'aggiornamento alla versione più recente di AGGIORNAMENTO automatico per SQL Server 2012, 2014 e 2016.
Tipi di dati delle colonne acquisite
Le colonne acquisite incluse in questa tabella hanno lo stesso tipo di dati e valore delle corrispondenti colonne di origine, con le seguenti eccezioni:
Le colonne timestamp sono definite come binary(8).Timestamp columns are defined as binary(8).
Le colonne Identity sono definite come int o bigint.
Tuttavia, i valori in queste colonne sono uguali ai valori della colonna di origine.
Tipi di dati per oggetti di grandi dimensioni:
Alle colonne di tipo di dati image, text e ntext viene sempre assegnato un valore NULL quando __$operation = 1 o __$operation = 3. Alle colonne di tipo di dati varbinary(max), varchar(max)o nvarchar(max) viene assegnato un valore NULL quando __$operation = 3, a meno che la colonna non sia cambiata durante l'aggiornamento. Quando __$operation = 1, a queste colonne viene assegnato il relativo valore al momento dell'eliminazione. Le colonne calcolate incluse in un'istanza di acquisizione hanno sempre un valore NULL.
Per impostazione predefinita, la dimensione massima che può essere aggiunta a una colonna acquista in una singola istruzione INSERT, UPDATE, WRITETEXT o UPDATETEXT è pari a 65.536 byte o 64 KB Per aumentare queste dimensioni per supportare dati LOB di dimensioni maggiori, usare l'opzione Di configurazione del server Max text repl size per specificare una dimensione massima maggiore. Per altre informazioni, vedere Configurare l'opzione di configurazione del server max text repl size.
Modifiche DDL
Le modifiche DDL alla tabella di origine, ad esempio l'aggiunta o l'eliminazione di colonne, vengono registrate nella tabella cdc.ddl_history . Queste modifiche non vengono applicate alla tabella delle modifiche. ossia la definizione della tabella delle modifiche rimane costante. Quando si inseriscono righe nella tabella delle modifiche, il processo di acquisizione ignora le colonne che non vengono visualizzate nell'elenco di colonne acquisite associato alla tabella di origine. Se una colonna è visualizzata nell'elenco di colonne acquisite che non compare più nella tabella di origine, alla colonna viene assegnato un valore Null.
Anche la modifica del tipo di dati di una colonna nella tabella di origine viene registrata nella tabella cdc.ddl_history . Tuttavia, questa modifica non altera la definizione della tabella delle modifiche. Il tipo di dati della colonna acquisita nella tabella delle modifiche viene modificato quando il processo di acquisizione incontra il record del log per la modifica DDL apportata alla tabella di origine.
Se è necessario modificare il tipo di dati di una colonna acquisita nella tabella di origine in una modalità che decresce la dimensione del tipo di dati, utilizzare la procedura descritta di seguito per assicurasi che la colonna equivalente nella tabella delle modifiche possa essere modificata correttamente.
Nella tabella di origine, aggiornare i valori nella colonna da modificare per adattarli nella dimensione del tipo di dati pianificata. Ad esempio, se si modifica il tipo di dati da int a smallint, aggiornare i valori a una dimensione che rientra nell'intervallo smallint , -32.768 a 32.767.
Nella tabella delle modifiche, eseguire la stessa operazione di aggiornamento alla colonna equivalente.
Modificare la tabella di origine specificando il nuovo tipo di dati. La modifica del tipo di dati è propagata correttamente alla tabella delle modifiche.
Modifiche DML
Quando su una tabella di origine abilitata per Change Data Capture vengono eseguite operazioni di inserimento, aggiornamento ed eliminazione, nel log delle transazioni del database viene visualizzato un record relativo a tali operazioni DML. Il processo change data capture recupera informazioni su tali modifiche dal log delle transazioni e aggiunge una o due righe alla tabella delle modifiche per registrare la modifica. Le voci vengono aggiunte alla tabella delle modifiche nello stesso ordine in cui è stato eseguito il commit nella tabella di origine. Detto questo, il commit delle voci della tabella delle modifiche deve in genere essere eseguito su un gruppo di modifiche anziché su ogni voce.
Un'operazione di inserimento comporta l'aggiunta di una riga alla tabella delle modifiche; un'operazione di eliminazione comporta l'aggiunta di una riga alla tabella delle modifiche; se SQL Server implementa un aggiornamento come "aggiornamento posticipato", ovvero come coppia di operazioni di eliminazione e inserimento, l'operazione di aggiornamento comporta l'aggiunta di due righe alla tabella delle modifiche: la prima riga riflette l'eliminazione dei dati acquisiti e la seconda riga che riflette l'inserimento dei dati acquisiti, acquisiti; se SQL Server non implementa un aggiornamento come "aggiornamento posticipato", l'operazione di aggiornamento restituisce due righe aggiunte alla tabella delle modifiche: la prima riga che riflette i dati acquisiti prima dell'aggiornamento e la seconda riga che riflette i dati acquisiti dopo l'aggiornamento.
All'interno della voce della tabella delle modifiche, la colonna __$start_lsn viene utilizzata per registrare l'LSN di commit associato alla modifica alla tabella di origine, la colonna __$command_id viene usata per ordinare la modifica all'interno della transazione e la colonna __$operation viene usata per registrare l'operazione eseguita. Nel loro complesso queste colonne di metadati possono essere utilizzate per garantire che venga mantenuto l'ordine di commit delle modifiche di origine. Poiché il processo di acquisizione ottiene le informazioni sulle modifiche dal log delle transazioni, è importante notare che le voci della tabella delle modifiche non vengono visualizzate in modo sincrono con le modifiche della tabella di origine corrispondenti. Al contrario, le modifiche corrispondenti vengono visualizzate in modo asincrono dopo che il processo di acquisizione ha elaborato le voci di modifica attinenti dal log delle transazioni.
Per le operazioni di inserimento ed eliminazione, sono impostati tutti i bit della maschera di aggiornamento. Per le operazioni di aggiornamento, la maschera di aggiornamento sia nelle vecchie righe aggiornate obsolete che nelle righe di nuovo aggiornamento sarà modificata per riflettere le colonne modificate durante l'aggiornamento.
Vedi anche
sys.sp_cdc_enable_table (Transact-SQL)
sys.sp_cdc_get_ddl_history (Transact-SQL)