Capture des changements de données (CDC) avez Azure SQL Database

  • Article

S’applique à Azure SQL Database

Dans cet article, découvrez comment la capture des changements de données (CDC) est mise en œuvre dans Azure SQL Database afin d’enregistree l’activité sur une base de données lorsque des tables et des lignes ont été modifiées. Pour plus d’informations sur la fonctionnalité CDC, notamment sur la façon dont elle est implémentée dans SQL Server et Azure SQL Managed Instance, consultez CDC avec SQL Server.

Vue d’ensemble

Dans Azure SQL Database, le planificateur de capture des changements de données remplace les tâches de SQL Server Agent qui capturent et nettoient les données de changement des tables source. Le planificateur exécute automatiquement la capture et le nettoyage dans l’étendue de la base de données, e assurant la fiabilité et la performance sans dépendances externes. Les utilisateurs conservent la possibilité de lancer manuellement les processus de capture et de nettoyage si nécessaire.

Un bon exemple d’un consommateur de données utilisé par cette technologie est une application d’extraction, transformation et chargement (ETL). Une application ETL charge de façon incrémentielle les données modifiées à partir de tables sources SQL Server vers un entrepôt de données ou un mini-Data Warehouse. Même si la représentation des tables sources dans l’entrepôt de données doit refléter les modifications apportées aux tables sources, une technologie de bout en bout qui actualise un réplica de la source n’est pas appropriée. Au lieu de cela, il faut un flux de données modifiées fiable, structuré de sorte que les consommateurs puissent l'appliquer aux différentes représentations cibles des données. La capture des changements des données SQL Server apporte cette technologie.

Pour en savoir plus sur la capture des changements de données dans Azure SQL Database, reportez-vous à cet épisode Data Exposed:

Flux de données

L’illustration suivante décrit le flux de données principal pour la capture des changements de données avec Azure SQL Database :

Diagram of a flow chart that depicts data flow for change data capture.

Prérequis

Autorisations

Le rôle db_owner est nécessaire pour activer la capture des changements de données pour Azure SQL Database.

Exigences en matière de calcul pour Azure SQL Database

Vous pouvez activer CDC sur Azure SQL Database pour n’importe quel niveau de service dans le modèle d’achat vCore pour les bases de données uniques et les pools élastiques.

Pour les bases de données dans le modèle d’achat DTU, CDC est prise en charge pour les bases de données du niveau S3 ou supérieur. Les niveaux de sous-noyau (De base, S0, S1, S2) ne sont pas pris en charge pour CDC.

Activer CDC pour Azure SQL Database

Avant de pouvoir créer une instance de capture pour des tables individuelles, vous devez activer CDC pour votre Azure SQL Database.

Pour activer CDC, connectez-vous à votre Azure SQL Database, à travers Azure Data Studio ou SQL Server Management Studio (SSMS). Ouvrez une nouvelle fenêtre de requête, puis activez CDC en exécutant le T-SQL suivant :

EXEC sys.sp_cdc_enable_db;
GO

Remarque

Pour déterminer si une base de données est déjà activée, interrogez la colonne is_cdc_enabled dans l'affichage catalogue sys.databases.

Lorsqu’une capture des changements de données est activée pour une base de données, le cdc schema, le cdc user, les tables de métadonnées, ainsi que d’autres objets systèmes sont créés pour la base de données. Le cdc schema contient les tables de métadonnées de la capture des changements de données et, une fois que les tables sources sont activées pour la cdc, les tables de modifications individuelles servent de base de données de référentiel pour les données modifiées. Le cdc schema contient également les fonctions système associées utilisées pour rechercher les données modifiées.

Important

La capture des changements de données requiert une utilisation exclusive de cdc schema et de cdc user. Si un schéma ou un utilisateur de base de données nommé cdc existe actuellement dans une base de données, la cdc ne peut pas être activée pour la base des données tant que le schéma et/ou l’utilisateur n’a pas été supprimé ou renommé.

Activer CDC pour une table

Après avoir activé la CDC pour votre Azure SQL Database, vous pouvez activer la CDC au niveau de la table en sélectionnant une ou plusieurs tables pour suivre les modifications apportées aux données. Créez une instance de capture pour des tables sources individuelles à l’aide de la procédure stockée sys.sp_cdc_enable_table.

Pour activer la CDC pour une table, exécutez la commande T-SQL suivante :

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL;
GO

Conseil

L’exemple précédent n’utilise pas un @role_name explicite en définissant le paramètre sur NULL, mais vous pouvez utiliser un rôle de gating pour limiter l’accès aux données modifiées.

Les colonnes de la table source à capturer

Par défaut, toutes les colonnes de la table source sont identifiées comme colonnes capturées. Si un suivi concerne uniquement un sous-ensemble de colonnes, par exemple pour des raisons de confidentialité ou de performance, utilisez le paramètre @captured_column_list pour spécifier le sous-ensemble de colonnes.

Pour activer la CDC pour une liste spécifique de colonnes dans une table, exécutez la commande T-SQL suivante :

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @captured_column_list = N'Column1, Column2, Column3';
GO

Conseil

Notez que l’exemple précédent n’utilise pas de @role_name explicite et en définissant le paramètre sur NULL, mais vous pouvez utiliser un rôle de gestion pour limiter l’accès aux données modifiées.

Un rôle pour contrôler l’accès à une table de modifications

L'objectif du rôle nommé consiste à contrôler l'accès aux données modifiées. Le rôle spécifié peut être un rôle serveur fixe existant ou un rôle de base de données. Si le rôle spécifié n’existe pas déjà, un rôle de base de données portant ce nom est automatiquement créé. Le utilisateurs doivent disposer de l’autorisation SELECT pour toutes les colonnes capturées de la table source. De plus, quand un rôle est spécifié, les utilisateurs qui ne sont pas membres du rôle sysadmin ou db_owner doivent également être membres du rôle spécifié.

Pour activer la CDC pour la table spécifiant un rôle de gating, exécutez la commande T-SQL suivante :

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = N'RoleName'
GO

Si vous ne voulez pas utiliser de rôle de gating, affectez explicitement le paramètre @role_name sur NULL.

Fonction pour interroger les modifications nettes

Une instance de capture inclut toujours une fonction table pour rendre toutes les entrées de table de modifications qui ont eu lieu au cours d’un intervalle défini. Cette fonction est nommée en ajoutant le nom de l’instance de capture à cdc.fn_cdc_get_all_changes_. Pour plus d’informations, consultez cdc.fn_cdc_get_all_changes.

Si le paramètre @supports_net_changes a la valeur 1, une fonction de suivi des modifications nettes est également générée pour l’instance de la capture. Cette fonction retourne une seule modification pour chaque ligne distincte modifiée dans l'intervalle spécifié dans l'appel. Pour plus d’informations, consultez cdc.fn_cdc_get_net_changes.

Pour prendre en charge les requêtes de modifications nettes, la table source doit disposer d'une clé primaire ou d'un index unique permettant d'identifier sans ambiguïté les lignes. Si un index unique est utilisé, le nom de l’index doit être spécifié à l’aide du paramètre @index_name . Les colonnes définies dans la clé primaire ou l'index unique doivent être incluses dans la liste des colonnes sources à capturer.

Pour activer la CDC pour une table avec prise en charge des modifications nettes, exécutez la commande T-SQL suivante :

EXEC sys.sp_cdc_enable_table
    @source_schema = N'SchemaName',
    @source_name = N'TableName',
    @role_name = NULL,
    @supports_net_changes = 1
GO

Si la capture des changements de données est activée sur une table avec une clé primaire existante, et que le paramètre @index_name n’est pas utilisé pour identifier un autre index unique, la fonctionnalité de capture des changements de données utilisera la clé primaire. Les modifications ultérieures à la clé primaire ne sont pas autorisées sans désactivation préalable de la capture des changements de données pour la table. Cela est vrai, que la prise en charge des requêtes de modifications nettes ait été demandée ou non lors de la configuration de la capture de données.

Si une table ne contient pas de clé primaire au moment de son activation pour la capture des changements de données, tout ajout ultérieur de clé primaire sera ignoré par la capture des changements de données. Étant donné que la capture des changements de données n'utilise pas de clé primaire créée une fois la table activée, la clé et les colonnes clés peuvent être supprimées sans restrictions.

Pour plus d’informations sur les arguments de procédure stockée sur sys.sp_cdc_enable_table, consultez sys.sp_cdc_enable_table (Transact-SQL).

Conseil

Pour déterminer si une table source a déjà été activée pour la capture des données modifiées, examinez la colonne is_tracked_by_cdc dans l’affichage catalogue sys.tables.

Désactivation de la CDC pour Azure SQL Database

La désactivation de la CDC pour votre base de données Azure SQL Database supprime toutes les métadonnées de capture des changements de données associés, notamment le cdc user, le cdc schema, et les processus de capture et de nettoyage du planificateur externe. Toutefois, tous les rôles de régulation créés par la capture des changements de données ne sont pas supprimés automatiquement et doivent être éliminés explicitement.

Remarque

Pour déterminer si CDC est activé sur une base de données, interrogez la colonne is_cdc_enabled dans l'affichage catalogue sys.databases.

Il n’est pas nécessaire de désactiver la CDC pour les tables individuelles avant de la désactiver au niveau de la base de données.

Pour désactiver la CDC au niveau de la base de données, exécutez la commande T-SQL suivante :

EXEC sys.sp_cdc_disable_db;
GO

Conseil

Après avoir désactivé la CDC au niveau de la base de données, vous devez réactiver la CDC pour les tables individuelles si vous voulez utiliser la fonctionnalité CDC une fois de plus.

Gérer la CDC

Dans Azure SQL Database, la CDC est une fonctionnalité cruciale pour suivre et gérer les modifications dans les tables de votre base de données. Contrairement aux environnements SQL Server traditionnels, Azure SQL Database utilise un planificateur de capture des changements de données pour gérer les tâches CDC au lieu de s’appuyer sur des tâches SQL Server Agent. Ce planificateur lance automatiquement des processus de capture et de nettoyage périodiques des tables CDC au sein de votre base de données, en assurant fiabilité et performance sans dépendances externes.

Capture et nettoyage automatiques de la CDC

Le travail de capture de la CDC dans Azure SQL Database fonctionne en toute transparence, s’exécutant toutes les 20 secondes pour suivre efficacement les modifications. Simultanément, le travail de nettoyage s’exécute toutes les heures, ce qui garantit que vos tables CDC restent optimisées. Les utilisateurs peuvent être assurés que la gestion de la CDC se produit automatiquement sans intervention manuelle.

Important

Si dans une base de données serverless la CDC est activée et qu’elle est en pause, la CDC ne s’exécute pas. L’analyse de la CDC n’aura pas d’impact sur la fonctionnalité de pause automatique.

Contrôle manuel de la CDC

Pendant que la CDC s’exécute automatiquement, les utilisateurs ont toujours la possibilité d’effectuer des opérations de CDC manuelles à la demande. Les procédure sp_cdc_scan et sp_cdc_cleanup_change_tables vous permettent de déclencher des tâches de capture et de nettoyage en fonction des besoins.

Surveiller la CDC

Azure SQL Database fournit des outils précieux pour surveiller les activités de CDC. Deux vues de gestion dynamique, sys.dm_cdc_log_scan_sessions et sys.dm_cdc_errors, offrent des aperçus sur les processus de CDC, ce qui garantit une visibilité totale de vos modifications de données.

Personnalisation de la CDC

Bien qu’Azure SQL Database simplifie la gestion de la CDC, certaines limitations existent :

  • La fréquence des tâches de la capture et de nettoyage de la CDC ne peut pas être personnalisée.
  • Les valeurs pollinginterval et continuous des tâches de capture et de nettoyage ne sont pas applicables dans Azure SQL Database.
  • La suppression de l’entrée de la tâche de capture de la table cdc.cdc_jobs n’interrompt pas la tâche de capture en arrière-plan.
  • La suppression de l’entrée de la tâche de nettoyage arrête la tâche de nettoyage.
  • La table cdc.cdc_jobs réside dans le schéma cdc et non dans msdb.

Malgré ces limitations, vous pouvez toujours personnaliser les options suivantes :

  • Interrogez la table cdc.cdc_jobs pour obtenir les détails de configuration actuels.
  • Ajustez les options maxtrans et maxscans à l’aide de la procédure stockée dans sp_cdc_change_job.
  • Gérez les tâches en employant sp_cdc_drop_job et sp_cdc_add_job en fonction des besoins.

Remarques et recommandations sur la performance

L’activation de la capture des changements de données pour Azure SQL Database a un effet de performance comparable à l’activation de la CDC pour SQL Server ou Azure SQL Managed Instance. Toutefois, plusieurs facteurs influencent l’effet de performance lors de l’activation de la CDC, notamment :

  • Le nombre de tables avec la CDC activée dans votre Azure SQL Database.

  • La fréquence des modifications dans les tables suivies ou dans le volume de transactions. Les transactions actives empêchent la troncation du journal des transactions jusqu’à ce que la transaction soit validée et que l’analyse de la CDC soit rattrapée ou que la transaction soit abandonnée. Cela peut entraîner le remplissage du journal des transactions plus que d’habitude. Il est donc important de surveiller que le journal des transactions ne se remplisse pas.

  • Assurez-vous qu’il y a de l’espace disponible dans la base de données source, car les artefacts CDC (par exemple, les tables CT, cdc_jobs, etc.) sont stockés dans la même base de données.

  • Que vous ayez une base de données unique ou qu’elle fasse partie d’un pool élastique.

  • Comme les bases de données d’un pool élastique partagent des ressources (par exemple, l’espace disque), l’activation de la capture des changements de données sur plusieurs bases de données présente le risque d’atteindre la taille maximale de la taille du disque du pool élastique. Supervisez les ressources comme le processeur, la mémoire et le débit du journal. Pour plus d’informations, consultez Gestion des ressources dans les pools élastiques denses.

  • Lorsque vous traitez des bases de données dans des pools élastiques, il est essentiel de prendre en compte le nombre de tables avec CDC activée et le nombre de bases de données auxquelles ces tables appartiennent. Nous vous suggérons d’évaluer votre charge de travail et de prendre les mesures nécessaires, telles que la mise à l’échelle du pool élastique. Pour plus d’informations, consultez Mettre à l’échelle des ressources de pools élastiques dans Azure SQL Database.

Important

Ces considérations représentent des conseils généraux. Pour obtenir des conseils précis afin d‘optimiser les performances d’une charge de travail spécifique, contactez le support Microsoft.

Tenez compte des meilleures pratiques suivantes lorsque vous utilisez la CDC avec Azure SQL Database :

  • Testez soigneusement votre charge de travail avant d’activer la CDC sur les bases de données en production pour vous aider à déterminer le SLO adapté à votre charge de travail. Pour plus d’informations sur Azure SQL Database, consultez Niveaux de service.

  • Envisagez de mettre à l’échelle le nombre de vCores ou de passer à un niveau de base de données supérieur, tel que Hyperscale, pour maintenir le niveau de performances précédent une fois que la CDC a été activée sur votre Azure SQL Database. Pour plus d’informations, consultez le modèle d’achat vCore - Azure SQL Database et Niveau de service Hyperscale

  • Surveillez étroitement l’utilisation de l’espace. Pour plus d’informations, consultez la section Gérer l’espace de fichiers pour les bases de données dans Azure SQL Database.

  • Surveillez le taux de génération des journaux ; pour plus d’informations, consultez Consommation de ressources par les charges de travail utilisateur et les processus internes.

  • Les processus d’analyse et de nettoyage de la CDC font partie de votre charge de travail de base de données standard (qui consomment également des ressources). En fonction du volume de transactions, la dégradation des performances peut être importante en raison des processus d’analyse et de nettoyage qui ne respectent pas la charge de travail, car des lignes entières sont ajoutées aux tables de modification et pour les opérations de mise à jour, la préimage est également incluse. Nous vous suggérons d’évaluer votre charge de travail et de prendre les mesures requises en fonction des recommandations précédentes. Pour plus d’informations, voir la section Gestion de la CDC qui se trouve plus loin dans cet article.

Important

Le planificateur exécute la capture et le nettoyage de manière automatique dans SQL Database. Le travail de capture de la CDC s’exécute toutes les 20 secondes, et le travail de nettoyage toutes les heures.

  • Pour éviter une augmentation de la latence, assurez-vous que le nombre de bases de données compatibles avec la CDC ne dépasse pas le nombre de vCores alloués à un pool élastique. Pour plus d’informations, consultez Gestion des ressources dans les pools élastiques denses.

  • En fonction de votre charge de travail et de votre niveau de performance, envisagez de modifier la période de rétention de la CDC en un nombre inférieur à la valeur par défaut de trois jours pour vous assurer que le processus de nettoyage puisse suivre les modifications de la table de modifications. La maintenance d’une période de rétention inférieure lors de la surveillance de la taille de la base de données est une bonne pratique.

  • Aucun Contrat de niveau de service (SLA) n’est fourni pour savoir quand les modifications sont apportées aux tables de changement. La latence bien inférieure à une seconde n’est pas non plus prise en charge.

Problèmes connus et limitations

Troncation agressive du journal

Quand vous activez la capture des changements de données (CDC) sur Azure SQL Database, la fonctionnalité de troncation de journal agressive de la récupération de base de données accélérée (ADR) est automatiquement désactivée. En effet, l’analyse CDC accède au journal des transactions de base de données. Les transactions actives continueront d’empêcher la troncation du journal des transactions jusqu’à la validation de la transaction et au rattrapage par l’analyse CDC ou jusqu’à ce que la transaction soit annulée. Cela peut entraîner le remplissage du journal des transactions plus que d’habitude. Il est donc important de surveiller que le journal des transactions ne se remplisse pas.

Lors de l’activation de la CDC, nous vous recommandons d’utiliser l’option d’index pouvant être reprise lorsque vous créez ou régénérez un index. Les index de reprise ne gardent pas une transaction longue durée ouverte et permettent la troncation des journaux pendant l’opération pour une meilleure gestion de l’espace journal. Pour plus d’informations, consultez les Recommandations pour les opérations d’index en ligne - Considérations relatives à l’index de reprise.

Niveau de service Azure SQL Database

Bien que la CDC soit prise en charge pour les bases de données et les pools élastiques dans n’importe quel niveau de service dans le modèle d’achat vCore, les bases de données inférieures à S3 (par exemple, base, S0, S1, S2) ne sont pas prises en charge dans le modèle d’achat DTU.

Limites du journal Azure SQL Database

La récupération de base de données accélérée et la CDC ne sont pas compatibles dans Azure SQL Database. Cela est dû au fait que l’analyse CDC accède activement au journal des transactions de la base de données et interagit avec ce dernier, ce qui peut entrer en conflit avec le comportement agressif de troncation des journaux de l’ADR.

Pour éviter les problèmes de scalabilité et de gestion de l’espace, surveillez étroitement votre base de données Azure SQL et envisagez de passer à un niveau de base de données supérieur et de permettre à votre journal des transactions de croître en fonction de vos besoins de charge de travail.

Conseil

Si votre charge de travail exige des performances globales plus élevées en raison d’un débit de journal des transactions plus élevé et de temps de validation des transactions plus rapides, utilisez le niveau de service Hyperscale.

Personnalisation de capture et de nettoyage

La configuration de la fréquence des processus de capture et de nettoyage pour CDC dans Azure SQL Databases n’est pas possible. Le planificateur exécute automatiquement la capture et le nettoyage.

Basculement vers Azure SQL Database

Dans le cas de scénarios de basculement local ou GeoDR, si votre base de données a la CDC activée, le processus de capture et de nettoyage des modifications de données se produira automatiquement sur la nouvelle base de données primaire à la suite du basculement.

Microsoft Entra ID

Remarque

Microsoft Entra ID était précédemment connu sous le nom d’Azure Active Directory (Azure AD).

Si vous créez un Azure SQL Database en tant qu’utilisateur Microsoft Entra et que vous y activez la fonctionnalité CDC, un utilisateur SQL (par exemple même un dans le rôle sysadmin) ne peut pas désactiver ni modifier les artefacts CDC. Toutefois, un autre utilisateur Microsoft Entra peut activer/désactiver la CDC sur la même base de données.

De même, si vous créez une base de données en tant qu’utilisateur SQL, l’activation/désactivation de la capture des changements de données en tant qu’utilisateur Microsoft Entra ne fonctionne pas.

L’activation de la CDC échoue si vous créez une base de données dans Azure SQL Database en tant qu’utilisateur Microsoft Entra, vous n’activez pas la CDC et, ensuite, vous essayez d’activer la CDC après la restauration de la base de données.

Pour résoudre ce problème, connectez-vous à votre base de données avec votre compte administrateur Microsoft Entra et exécutez le T-SQL suivant :

ALTER AUTHORIZATION ON DATABASE::[<restored_db_name>] TO [<azuread_admin_login_name>];

EXEC sys.sp_cdc_enable_db;

Restauration à un point dans le temps

Si vous avez activé la CDC sur votre Azure SQL Database en tant qu’utilisateur SQL, la restauration à un point dans le temps (PITR) conserve la CDC dans la base de données restaurée, à moins qu’elle ne soit restauré dans un sous-programme SLO. Si ils sont restaurés en SLO de sous-unité, les artefacts de la CDC ne sont pas disponibles.

Si vous activez la CDC sur votre base de données en tant qu’utilisateur Microsoft Entra, il n’est pas possible de restaurer à un point dans le temps (PITR) à un sous-SLO. Restaurez la base de données au SLO identique ou supérieur à la source, puis désactivez la CDC si nécessaire.

Dépannage

Cette section fournit des conseils et des étapes de dépannage associées à la CDC sur Azure SQL Database. Les erreurs liées à la CDC peuvent entraver le bon fonctionnement du processus de saisie et entraîner l’expansion du journal des transactions de la base de données.

Pour examiner ces erreurs, vous pouvez interroger la vue de gestion dynamique sys.dm_cdc_errors. Si la vue de gestion dynamique sys.dm_cdc_errors renvoie des erreurs, se reporter à la section suivante pour comprendre les étapes d’atténuation.

Remarque

Pour plus d’informations sur un code d’erreur particulier, consultez les Événements et erreurs du moteur de base de données.

Voici les différentes catégories de résolution des problèmes incluses dans cette section :

Category Description
Métadonnées modifiées Inclut des renseignements sur la façon d’atténuer les problèmes liés à la CDC lorsque la table déposée a été modifiée ou abandonnée.
Gestion de l’espace de la base de données Inclut des informations sur la façon d’atténuer les problèmes lorsque l’espace de la base de données a été épuisé.
Limitation de la CDC Inclut des informations sur la façon d’atténuer les problèmes causés par les limitations de la CDC.

Métadonnées modifiées

Erreur 200/208 : nom d’objet non valide

  • Cause : l’erreur peut se produire lorsque les métadonnées de la CDC ont été supprimées. Pour que la CDC fonctionne correctement, vous ne devez pas modifier manuellement ses métadonnées telles que CDC schema, modifier les tables, les procédures stockées dans le système CDC, les autorisations cdc user par défaut (sys.database_principals) ou renommer le cdc user.

  • Recommandation : Pour résoudre ce problème, vous devez désactiver et réactiver la CDC de votre base de données. Lorsque vous activez la capture des changements de données pour une base de données, elle crée le schéma cdc, l’utilisateur cdc, les tables de métadonnées et d’autres objets système pour la base de données. Vous devez réactiver manuellement la CDC pour les tables individuelles une fois qu’elle est activée.

Remarque

Les objets trouvés dans l’affichage catalogue système sys.objects avec is_ms_shipped=1 et schema_name=cdc ne doivent pas être modifiés, ni supprimés.

Erreur 1202 : le principal de la base de données n’existe pas ou l’utilisateur n’est pas membre

  • Cause : l’erreur peut se produire lorsque l’utilisateur de la CDC a été supprimé. Pour que la CDC fonctionne correctement, vous ne devez pas modifier manuellement les métadonnées CDC telles que CDC schema, les tables modifiées, les procédures stockées sur le système CDC, les autorisations cdc user par défaut (sys.database_principals) ou renommer cdc user.

  • Recommandation : vérifiez que l’utilisateur cdc existe dans votre base de données et dispose également du rôle db_owner attribué. Pour créer l’utilisateur cdc, consultez l’exemple Créer un utilisateur cdc et lui attribuer un rôle.

Erreur 15517 : impossible d’exécuter en tant que principal de base de données, car le principal n’existe pas

  • Cause : ce type de principal ne peut pas être usurpé ou vous n’avez pas l’autorisation de le faire. L’erreur peut se produire lorsque les métadonnées CDC ont été supprimées ou qu’elles ne font plus partie du rôle db_owner. Pour que la CDC fonctionne correctement, vous ne devez pas modifier manuellement les métadonnées CDC telles que CDC schema, les tables modifiées, les procédures stockées système CDC, les autorisations cdc user par défaut (sys.database_principals) ou renommer le cdc user.

  • Recommandation : vérifiez que l’utilisateur cdc existe dans votre base de données et dispose également du rôle db_owner attribué. Pour créer l’utilisateur cdc, consultez l’exemple Créer un utilisateur cdc et lui attribuer un rôle.

Erreur 18807 : impossible de trouver un ID d’objet pour la table système de réplication

  • Cause : cette erreur se produit lorsque SQL Server ne peut pas trouver ou accéder à la table système de réplication « %s ». Cela peut être dû au fait que la table est manquante ou inaccessible. Pour que la CDC fonctionne correctement, vous ne devez pas modifier manuellement ses métadonnées telles que CDC schema, les tables modifiées, les procédures stockées système modifiées, les autorisations cdc user par défaut (sys.database_principals) ou renommer le cdc user.

  • Recommandation : vérifiez que la table système existe et qu’elle est accessible en l’interrogeant directement. Interrogez le catalogue système sys.objects, définissez la clause de prédicat avec is_ms_shipped=1 et schema_name=cdc pour répertorier tous les objets liés à CDC. Si la requête ne renvoie aucun objet, vous devez désactiver et réactiver la capture de données modifiées pour votre base de données. L’activation de la capture des données modifiiées pour une base de données crée le cdc schema, cdc user, les tables de métadonnées et d’autres objets système pour la base de données. Vous devez réactiver manuellement la CDC pour les tables individuelles une fois qu’elle est activée.

Erreur 21050 : seuls les membres du rôle serveur fixe sysadmin ou db_owner peuvent effectuer cette opération

  • Cause : l’utilisateur cdc a été supprimé du rôle de base de données db_owner ou du rôle serveur sysadmin.

  • Recommandation : vérifiez que l’utilisateur cdc a le rôle db_owner attribué. Pour créer l’utilisateur cdc, consultez l’exemple Créer un utilisateur cdc et lui attribuer un rôle.

Gestion de l’espace de la base de données

Erreur 1105 : impossible d’allouer de l’espace pour l’objet dans la base de données, car le groupe de fichiers est plein

  • Cause : cette erreur se produit lorsque le groupe de fichiers principal d’une base de données manque d’espace et que SQL Database ne parvient pas à allouer plus d’espace pour un objet (par exemple, une table ou un index) dans ce groupe de fichiers.

  • Recommandation : pour résoudre ce problème, supprimez toutes les données inutiles de votre base de données pour libérer de l’espace. Identifiez les tables, index ou autres objets inutilisés dans le groupe de fichiers qui peuvent être supprimés en toute sécurité. Surveiller de près l’utilisation de l’espace, pour plus d’informations, consultez Gérer l’espace des fichiers pour les bases de données dans Azure SQL Database.

    Si la suppression de données/objets inutiles n’est pas une option, envisagez de mettre à l’échelle un niveau de base de données supérieur.

Important

Pour des informations détaillées sur les tailles de calcul (SLO) d’Azure SQL Database (base de données unique), consultez Limites de ressources pour les bases de données uniques utilisant le modèle d’achat vCore et Limites de ressources pour des bases de données uniques utilisant le modèle d’achat DTU - Azure SQL Database.

Erreur 1132 : le pool élastique a atteint sa limite de stockage

  • Cause : cette erreur se produit lorsque l’utilisation du stockage dans votre pool élastique a dépassé la limite allouée.

  • Recommandation : pour résoudre ce problème, implémentez des stratégies d’archivage et de purge des données pour conserver uniquement les données nécessaires dans les bases de données qui font partie du pool élastique. Surveillez étroitement l’utilisation de l’espace. Pour plus d’informations, consultez la section Gérer l’espace de fichiers pour les bases de données dans Azure SQL Database.

    Si l’archivage des données ou la suppression d’objets/données inutiles n’est pas une option, envisagez de mettre à l’échelle vers un niveau de base de données supérieur.

Important

Pour des informations détaillées sur les tailles de calcul (SLO) d’Azure SQL Database (base de données unique), consultez Limites de ressources pour des pools élastiques utilisant le modèle d’achat vCore et Limites de ressources pour des pools élastiques utilisant le modèle d’achat DTU.

Limitation de la CDC

Erreur 2628 : les données binary ou String seront tronquées dans la table

  • Cause : la modification de la taille des colonnes d’une table avec CDC à l’aide d’instructions DDL peut entraîner des problèmes avec le processus de capture CDC suivant. La vue de gestion dynamique (DMV) sys.dm_cdc_errors est utile pour vérifier toute CDC pour tout problème signalé, comme les erreurs numéro 2628 et 8115.

  • Recommandation : avant d’apporter des modifications à la taille des colonnes, vous devez évaluer si la modification est compatible avec les données existantes dans les tables de modification de CDC. Pour résoudre ce problème, vous devez désactiver et réactiver la CDC pour votre base de données. Pour plus d’informations sur l’activation de la CDC pour une base de données ou une table, consultez les sections Activer la CDC pour Azure SQL Database et Activer la CDC pour une table de cet article.

Erreur 22830 : la fonction intégrée « SUSER_SNAME » dans le contexte d'emprunt d'identité n'est pas prise en charge dans cette version de SQL Server

  • Cause : cette erreur se produit lors de l'activation du CDC si un déclencheur utilisateur existe dans la base de données et qu'il fait appel à la fonction SUSER_SNAME() on create_table. Vous pouvez répertorier les déclencheurs avec le script Transact-SQL suivant. Cette commande fournit les détails du déclencheur d’objet et le object_id suivants :

    SELECT name,
    object_id
FROM sys.triggers
WHERE parent_class_desc = 'DATABASE'
    AND is_disabled = 0;

    une fois que vous avez obtenu les définitions du déclencheur, vous pouvez rechercher les appels effectués vers SYSTEM_USER avec le script suivant :

    SELECT OBJECT_DEFINITION(object_id) AS trigger_definition;

  • Recommandation : pour résoudre ce problème, procédez comme suit pour chaque déclencheur utilisateur obtenu à partir du script précédent.

    • Désactiver le déclencheur
    • Activer la fonctionnalité CDC
    • Réactiver le déclencheur

Pour plus d’informations, consultez la section DISABLE TRIGGER (Transact-SQL).

Erreur 913 : la tâche de saisie CDC échoue lors du traitement des modifications pour une table avec le type de données CLR du système

  • Cause : cette erreur se produit lorsque l’activation de la CDC sur une table avec le type de données CLR du système, que l’on apporte des modifications à la DML, puis que l’on apporte des modifications à la DDL sur la même table pendant que la tâche de capture de la CDC traite les modifications liées à d’autres tables.

  • Recommandation : les étapes recommandées sont de mettre DML au repos, d’exécuter une tâche de capture pour traiter les modifications, d’exécuter DDL pour la table, d’exécuter une tâche de capture pour traiter les modifications DDL, puis de réactiver le traitement DML. Pour plus d’informations, consultez La tâche de capture de la CDC échoue lors du traitement des modifications.

Créer un utilisateur et attribuer un rôle

Si cdc user a été supprimé, vous pouvez ajouter à nouveau manuellement l’utilisateur.

Utilisez le script T-SQL suivant pour créer un utilisateur (cdc) et attribuer le rôle approprié (db_owner).

IF NOT EXISTS (
    SELECT *
    FROM sys.database_principals
    WHERE NAME = 'cdc'
)
BEGIN
    CREATE USER [cdc] WITHOUT LOGIN
    WITH DEFAULT_SCHEMA = [cdc];
END

EXEC sp_addrolemember 'db_owner', 'cdc';

Vérifier et ajouter l’appartenance au rôle

Pour vérifier si l’utilisateur cdc appartient au rôle sysadmin ou db_owner, exécutez la requête T-SQL suivante :

EXECUTE AS USER = 'cdc';

SELECT is_srvrolemember('sysadmin'), is_member('db_owner');

Si l’utilisateur cdc n’appartient pas à un rôle, exécutez la requête T-SQL suivante pour ajouter un rôle db_owner à l’utilisateur cdc.

EXEC sp_addrolemember 'db_owner' , 'cdc';

Contenu connexe