Capture des changements de données et les autres fonctionnalités

  • Article

S’applique à :SQL ServerAzure SQL Managed Instance

Cet article décrit comment les fonctionnalités suivantes interagissent avec la capture de données modifiées pour SQL Server et Azure SQL Managed Instance. Pour Azure SQL Database, consultez capture de données modifiées avec Azure SQL Database.

Suivi des modifications

La capture de données modifiées et le suivi des modifications peuvent être activés sur la même base de données. Aucune considération particulière ne s'applique. Pour plus d’informations, consultez Work with Change Tracking.

Mise en miroir de bases de données

Une base de données prenant en charge la capture de données modifiées peut être mise en miroir. Pour faire en sorte que la capture et le nettoyage s'exécutent automatiquement après un basculement, suivez ces étapes :

  1. Vérifiez que SQL Server Agent s’exécute sur la nouvelle instance de serveur principal.

  2. Créez le travail de capture et le travail de nettoyage sur la nouvelle base de données principale (base de données miroir initiale). Pour créer les travaux, utilisez la procédure stockée sp_cdc_add_job .

Pour consulter la configuration actuelle d’un travail de capture ou de nettoyage, utilisez la procédure stockée sys.sp_cdc_help_jobs sur la nouvelle instance de serveur principal. Pour une base de données spécifique, le travail de capture est nommé cdc.nom_base_de_données_capture, tandis que le travail de nettoyage est nommé cdc.nom_base_de_données_cleanup, où nom_base_de_données est le nom de la base de données.

Pour modifier la configuration d’un travail, utilisez la procédure stockée sys.sp_cdc_change_job .

Pour plus d’informations sur la miroir de base de données, consultez La mise en miroir de bases de données (SQL Server)

Réplication transactionnelle

La capture de données modifiées et la réplication transactionnelle peuvent coexister dans la même base de données, mais le remplissage des tables de modifications est géré différemment lorsque les deux fonctionnalités sont activées. La capture de données modifiées et la réplication transactionnelle utilisent toujours la même procédure, sp_replcmds, pour lire les modifications dans le journal des transactions. Lorsque la capture de données modifiées est activée par elle-même, un travail SQL Server Agent appelle sp_replcmds. Quand les deux fonctionnalités sont activées sur la même base de données, l’Agent de lecture du journal appelle sp_replcmds. Cet agent remplit à la fois les tables de modifications et les tables de bases de données de distribution. Pour plus d’informations, consultez Replication Log Reader Agent.

Considérez un scénario dans lequel la capture de données modifiées est activée sur la base de données AdventureWorks2022 , et deux tables sont activées pour la capture. Pour remplir les tables de modifications, le travail de capture appelle sp_replcmds. La base de données est activée pour la réplication transactionnelle, et une publication est créée. Ensuite, l'Agent de lecture du journal est créé pour la base de données et le travail de capture est supprimé. L'Agent de lecture du journal continue à analyser le journal à partir du dernier numéro séquentiel dans le journal qui été validé dans la table de modifications. Cela garantit la cohérence des données dans les tables de modifications. Si la réplication transactionnelle est désactivée dans cette base de données, l'Agent de lecture du journal est supprimé et le travail de capture est recréé.

Remarque

Lorsque l'Agent de lecture du journal est utilisé à la fois pour la capture de données modifiées et la réplication transactionnelle, les modifications répliquées sont écrites en premier dans la base de données de distribution. Puis, les modifications capturées sont écrites dans les tables de modifications. Les deux opérations sont validées ensemble. Si l'écriture dans la base de données de distribution s'effectue avec une latence, la même latence est observée avant l'affichage des modifications dans les tables de modifications.

L’option proc exec de réplication transactionnelle n’est pas disponible lorsque la capture de données modifiées est activée.

Restauration ou attachement de base de données

SQL Server utilise la logique suivante pour déterminer si la capture de données modifiées reste activée après la restauration ou l’attachement d’une base de données :

  • Si une base de données est restaurée sur le même serveur avec le même nom de base de données, la capture de données modifiées reste activée.

  • Si une base de données est restaurée sur un autre serveur, par défaut, la capture de données modifiées est désactivée et toutes les métadonnées connexes sont supprimées.

    Pour conserver la fonction de capture de données modifiées, utilisez l’option KEEP_CDC lors de la restauration de la base de données. Pour plus d'informations sur cette option, consultez RESTORE.

  • Si une base de données est détachée puis attachée au même serveur ou à un autre serveur, la capture de données modifiées reste activée.

  • Si une base de données est attachée ou restaurée avec l’option KEEP_CDC à n’importe quelle édition autre que Standard, Enterprise ou SQL Managed Instance, l’opération est bloquée, car la capture de données modifiées nécessite des éditions SQL Server Standard, Enterprise ou SQL Managed Instance. Le message d’erreur 934 est affiché :

    SQL Server cannot load database '%.*ls' because change data capture is enabled. The currently installed edition of SQL Server does not support change data capture. Either restore database without KEEP_CDC option, or upgrade the instance to one that supports change data capture.

Vous pouvez utiliser sys.sp_cdc_disable_db pour supprimer la capture de données modifiées d’une base de données restaurée ou attachée.

Après la restauration d’une base de données sur Azure SQL Managed Instance, CDC reste activé, mais vous devez vous assurer que les tâches d’analyse et de nettoyage sont ajoutées et en cours d’exécution. Vous pouvez ajouter manuellement les travaux en exécutant sys.sp_cdc_add_job.

Bases de données autonomes

La capture de données modifiées n’est pas prise en charge dans les bases de données autonomes.

Groupes de disponibilité

Quand vous utilisez des groupes de disponibilité Always On, l’énumération des changements doit être effectuée sur le réplica secondaire afin de réduire la charge du disque sur le réplica principal.

Index Columnstore

La capture de données modifiées ne peut pas être activée sur les tables avec un index columnstore cluster. À compter de SQL Server 2016, il peut être activé sur des tables avec un index columnstore non cluster.

Colonnes calculées

La capture de données modifiées ne prend pas en charge les valeurs des colonnes calculées, même si la colonne calculée est définie comme persistante. Les colonnes calculées incluses dans une instance de capture ont toujours une valeur NULL. Ce comportement est prévu, ce n’est pas un bogue.

Linux

La capture de données modifiées est prise en charge pour SQL Server 2017 sur Linux à partir de CU18 et DE SQL Server 2019 sur Linux.

Voir aussi