cdc.<capture_instance>_CT (Transact-SQL)
Table de modifications créée lorsque la capture des données modifiées est activée sur une table source. La table retourne une ligne pour chaque opération d'insertion et de suppression effectuée sur la table source, et deux lignes pour chaque opération de mise à jour effectuée sur la table source. Lorsque le nom de la table de modifications n'est pas spécifié au moment de l'activation de la table source, le nom est dérivé. Le format du nom est cdc.capture_instance_CT où capture_instance est le nom de schéma de la table source et le nom de table source au format schema_table. Par exemple, si la table Person.Address dans l'exemple de base de données AdventureWorks2008R2 est activée pour la capture des données modifiées, le nom de la table de modifications dérivé serait cdc.Person_Address_CT.
Nous vous recommandons de ne pas interroger les tables système directement. À la place, exécutez les fonctions cdc.fn_cdc_get_all_changes_<capture_instance> et cdc.fn_cdc_get_net_changes_<capture_instance>.
Nom de colonne |
Type de données |
Description |
|---|---|---|
__$start_lsn |
binary(10) |
Numéro séquentiel dans le journal associé à la transaction de validation pour la modification. Toutes les modifications validées dans la même transaction partagent le même numéro séquentiel dans le journal de validation. Par exemple, si une opération de suppression sur la table source supprime deux lignes, la table de modifications contiendra deux lignes, chacune avec la même valeur __$start_lsn. |
__$end_lsn |
binary(10) |
Identifié à titre d'information uniquement. Non pris en charge. La compatibilité future n'est pas garantie. Dans SQL Server 2008, cette colonne a toujours pour valeur NULL. |
__$seqval |
binary(10) |
Valeur de classement utilisée pour classer les modifications de ligne dans une transaction. |
__$operation |
int |
Identifie l'opération de langage de manipulation de données associée à la modification. Valeurs possibles : 1 = suppression 2 = insertion 3 = mise à jour (anciennes valeurs) Les données de colonne ont des valeurs de ligne avant d'exécuter l'instruction UPDATE. 4 = mise à jour (nouvelles valeurs) Les données de colonne ont des valeurs de ligne après l'exécution de l'instruction UPDATE. |
__$update_mask |
varbinary(128) |
Masque de bits basé sur les ordinaux de colonne de la table de modifications identifiant les colonnes modifiées. |
<colonnes de table source capturées> |
variable |
Les colonnes restantes de la table de modifications sont les colonnes de la table source qui ont été identifiées comme colonnes capturées lorsque l'instance de capture a été créée. Si aucune colonne n'a été spécifiée dans la liste des colonnes capturées, toutes les colonnes de la table source sont incluses dans cette table. |
Notes
Types de données de la colonne capturée.
Les colonnes capturées incluses dans cette table ont les mêmes type de données et valeur que leurs colonnes sources correspondantes avec les exceptions suivantes :
Les colonnes Timestamp sont définies comme binary(8).
Les colonnes Identity sont définies comme int ou bigint.
Toutefois, les valeurs dans ces colonnes sont les mêmes que celles des colonnes sources.
Types de données des objets importants
Pour les types de données métier varchar(max), nvarchar(max), varbinary(max), image, text, ntext et xml, l'ancienne valeur apparaîtra seulement dans l'ancienne ligne de mise à jour si la colonne a réellement changé pendant la mise à jour. Pour les autres types de données, la valeur de colonne apparaîtra toujours dans les deux lignes de mise à jour.
Par défaut, la taille maximale qui peut être ajoutée à une colonne capturée dans une seule instruction INSERT, UPDATE, WRITETEXT ou UPDATETEXT est de 65 536 octets ou 64 Ko. Pour augmenter cette taille afin de prendre en charge des données d'objets importants en plus grand nombre, utilisez l'option max text repl size pour spécifier une plus grande taille maximale. Pour plus d'informations, consultez Procédure : configurer l'option max text repl size (SQL Server Management Studio).
Modifications du langage de définition de données (DDL)
Les modifications DDL apportées à la table source, telles que l'ajout ou la suppression de colonnes, sont enregistrées dans la table cdc.ddl_history. Ces modifications ne sont pas appliquées à la table de modifications. Autrement dit, la définition de la table de modifications reste constante. Lors de l'insertion de lignes dans la table de modifications, le processus de capture ignore les colonnes qui n'apparaissent pas dans la liste des colonnes capturées associées à la table source. Si une colonne apparaît dans la liste des colonnes capturées qui n'est plus dans la table source, une valeur Null est assignée à la colonne.
La modification du type de données d'une colonne dans la table source est également enregistrée dans la table cdc.ddl_history. Toutefois, cette modification altère la définition de la table de modifications. Le type de données de la colonne capturée dans la table de modifications est modifié lorsque le processus de capture rencontre l'enregistrement du journal pour la modification DDL apportée à la table source.
Si vous devez modifier le type de données d'une colonne capturée dans la table source d'une façon qui réduit la taille du type de données, utilisez cette procédure pour vous assurer que la colonne équivalente dans la table de modifications peut être correctement modifiée.
Dans la table source, mettez à jour les valeurs dans la colonne à modifier pour qu'elles s'ajustent à la taille de type de données planifiée. Par exemple, si vous remplacez le type de données int par smallint, mettez à jour les valeurs à une taille qui s'ajuste à la plage smallint, de -32 768 à 32 767.
Dans la table de modifications, effectuez la même opération de mise à jour sur la colonne équivalente.
Modifiez la table source en spécifiant le nouveau type de données. La modification du type de données est propagée avec succès à la table de modifications.
Modifications du langage de manipulation de données
Lorsque des opérations d'insertion, de mise à jour et de suppression sont effectuées sur une table source où la capture de données modifiées est activée, un enregistrement de ces opérations DML apparaît dans le journal des transactions de la base de données. Le processus de capture de la capture de données modifiées récupère les informations sur ces modifications dans le journal des transactions et ajoute une ou deux lignes à la table de modifications pour enregistrer la modification. Les entrées sont ajoutées à la table de modifications selon l'ordre dans lequel elles ont été validées dans la table source, même si la validation d'entrées de table de modifications doit en général être effectuée sur un groupe de modifications plutôt que sur une entrée unique.
Dans l'entrée de la table de modifications, la colonne __$start_lsn sert à enregistrer le numéro séquentiel dans le journal (LSN) de validation associé à la modification apportée à la table source et la colonne __$seqval à classer la modification dans sa transaction. Ensemble, ces colonnes de métadonnées peuvent être utilisées pour faire en sorte que l'ordre de validation des modifications de source soit conservé. Dans la mesure où le processus de capture obtient ses informations de modification du journal des transactions, il est important de noter que les entrées de table de modifications n'apparaissent pas de façon synchrone avec leurs modifications correspondantes de la table source. Les modifications apparaissent en effet de façon asynchrone, une fois que le processus de capture a traité les entrées de modification pertinentes du journal des transactions.
Pour les opérations d'insertion et de suppression, tous les bits du masque de mise à jour sont définis. Pour les opérations de mise à jour, le masque de mise à jour sera modifié dans les lignes de mise à jour nouvelles et anciennes pour refléter les colonnes qui ont changé pendant la mise à jour.
Voir aussi