CDC.<>capture_instance_CT (Transact-SQL)
S’applique à : 
SQL Server Azure SQL Database Azure SQL Managed Instance
Table de modifications créée lorsque la capture de 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 où la table source est activée, le nom est dérivé. Le format du nom est cdc.capture_instance_CT où capture_instance est le nom du schéma de la table source et le nom de la table source au format schema_table. Par exemple, si la table Person.Address dans l’exemple de base de données AdventureWorks est activée pour la capture de données modifiées, le nom de la table de modification dérivée est cdc.Person_Address_CT.
Nous vous recommandons de ne pas interroger directement les tables système. Au lieu de cela, exécutez les fonctions cdc.fn_cdc_get_all_changes_<capture_instance> et cdc.fn_cdc_get_net_changes_<capture_instance> .
| Nom de la 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 contient 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 2012 (11.x), cette colonne est toujours NULL. |
| __$seqval | binary(10) | Séquence de l’opération représentée dans le journal des transactions. Ne doit pas être utilisé pour l’ordre. Utilisez plutôt la colonne __$command_id . |
| __$operation | int | Identifie l'opération de langage de manipulation de données associée à la modification. Il peut s'agir d'une des méthodes suivantes : 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 ordinals de colonne de la table de modification identifiant les colonnes qui ont changé. |
| <colonnes des tables sources capturées> | varie | 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. |
| __$command_id | int | Suit l’ordre des opérations dans une transaction. |
Notes
La __$command_id colonne a été introduite dans une mise à jour cumulative dans les versions 2012 à 2016. Pour plus d’informations sur la version et le téléchargement, consultez l’article de la base de connaissances 3030352 au correctif : la table de modifications est ordonnée de manière incorrecte pour les lignes mises à jour après avoir activé la capture de données modifiées pour une base de données Microsoft SQL Server. Pour plus d’informations, consultez la fonctionnalité cdc peut s’interrompre après la mise à niveau vers la dernière mise à niveau pour SQL Server 2012, 2014 et 2016.
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 d’horodatage sont définies comme binaires(8).
Les colonnes d’identité sont définies en tant qu’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
Les colonnes d’image, de texte et de ntext de type de données sont toujours affectées à une valeur NULL lorsque __$operation = 1 ou __$operation = 3. Les colonnes de type de données varbinary(max), varchar(max)ou nvarchar(max) reçoivent une valeur NULL lorsque __$operation = 3, sauf si la colonne a changé pendant la mise à jour. Lorsque __$operation = 1, ces colonnes reçoivent leur valeur au moment de la suppression. Les colonnes calculées incluses dans une instance de capture ont toujours une valeur NULL.
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 pour prendre en charge les données métier plus volumineuses, utilisez l’option Configurer la taille maximale de la taille de serveur de repl de texte pour spécifier une taille maximale supérieure. Pour plus d’informations, consultez Configurer l’option de configuration du serveur max text repl size.
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 modification, le processus de capture ignore les colonnes qui n’apparaissent pas dans la liste de colonnes capturées associée à 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 la procédure suivante 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 modifiez le type de données d’int à smallint, mettez à jour les valeurs en une taille qui correspond à la plage smallint, -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 des données modifiées récupère des 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 dans le même ordre qu’elles ont été validées dans la table source. Cela dit, la validation des entrées de table de modifications doit généralement être effectuée sur un groupe de modifications plutôt que sur chaque entrée.
Une opération d’insertion entraîne l’ajout d’une ligne à la table de modifications ; une opération de suppression entraîne l’ajout d’une ligne à la table de modifications ; si SQL Server implémente une mise à jour en tant que « mise à jour différée », ce qui signifie qu’une paire d’opérations de suppression et d’insertion entraîne l’ajout de deux lignes à la table de modifications : la première ligne reflétant la suppression des données capturées et la deuxième ligne reflétant l’insertion des données mises à jour et capturées ; si SQL Server n’implémente pas de mise à jour en tant que « mise à jour différée », l’opération de mise à jour génère deux lignes ajoutées à la table de modifications : la première ligne reflétant les données capturées avant la mise à jour et la deuxième ligne reflétant les données capturées après la mise à jour.
Dans l’entrée de table de modification, la colonne __$start_lsn est utilisée pour enregistrer le LSN de validation associé à la modification de la table source, la colonne __$command_id est utilisée pour classer la modification dans sa transaction et la colonne __$operation est utilisée pour enregistrer l’opération effectuée. 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é. Étant donné que le processus de capture obtient ses informations de modification à partir du journal des transactions, il est important de noter que les entrées de table de modification ne s’affichent pas de manière synchrone avec leurs modifications de table source correspondantes. 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
sys.sp_cdc_enable_table (Transact-SQL)
sys.sp_cdc_get_ddl_history (Transact-SQL)