Diagnostiquer les problèmes

Cette situation peut se produire pour diverses raisons. Pour résoudre ce problème:

1. Assurez-vous que la base de données source est opérationnelle et accessible.
2. Accédez au profil de connexion source depuis les pages Flux ou Profils de connexion.
3. Vérifiez que les informations de connectivité du profil de connexion sont correctes.
4. Vérifiez que le nom d'utilisateur et le mot de passe correspondent.
5. Vérifiez que le nom d'utilisateur existe dans la base de données et qu'il dispose des droits requis.
6. Enregistrez les modifications que vous avez apportées sur la page Profils de connexion.

La diffusion reprend automatiquement.

1. Assurez-vous d'avoir rempli toutes les conditions préalables Prérequis pour l'appairage de VPC.

2. Après avoir créé la configuration de connectivité privée, vérifiez que la route qui contient l'adresse IP interne de la base de données apparaît dans l'onglet Routes exportées de la page Appairage de réseaux VPC.

   Pour ce faire, accédez à la page Appairage de réseaux VPC, puis recherchez l'appairage ajouté (son nom est peering-[UUID]). La route se trouve dans l'onglet Routes exportées. Si cette route n'existe pas, ajoutez-la manuellement.

3. Datastream ne vérifie pas les chevauchements avec les routes de peering dynamiques. Fournir un sous-réseau qui chevauche une route dynamique peut entraîner des problèmes de connectivité. Par conséquent, nous vous déconseillons d'utiliser un sous-réseau faisant partie d'un routage dynamique.
4. Assurez-vous que les routes personnalisées pour les plages d'adresses IP Datastream sont correctement annoncées. Si les routes personnalisées sont manquantes, consultez la section Routes annoncées personnalisées.
5. Si le problème de connexion à la base de données source persiste, consultez Configurer un proxy inverse.

1. Assurez-vous d'avoir rempli toutes les conditions préalables.
2. Assurez-vous que vos règles de pare-feu autorisent le sous-réseau du rattachement de réseau fourni à se connecter à la base de données source.
3. Assurez-vous que les routes personnalisées pour les plages d'adresses IP Datastream sont correctement annoncées. Si les routes personnalisées sont manquantes, consultez la section Routes annoncées personnalisées.

Vous avez sélectionné les méthodes de connectivité réseau liste d'autorisation d'adresses IP publiques ou tunnel SSH de transfert pour le profil de connexion que vous créez. Toutefois, la règle d'administration Bloquer les méthodes de connectivité publique pour Datastream est activée. Vous ne pouvez donc pas sélectionner de méthodes de connectivité publiques pour votre profil de connexion.

Pour résoudre ce problème, sélectionnez la méthode de connectivité réseau privée Appairage de VPC ou Interfaces Private Service Connect, ou désactivez la règle d'administration.

Pour désactiver la règle d'administration, procédez comme suit :

1. Accédez à la page Règles d'administration dans la console Google Cloud .
2. Sélectionnez la règle d'administration Datastream - Bloquer les méthodes de connectivité publique.

3. Cliquez sur MODIFIER.

4. Dans la section Applies to (Applicable à), sélectionnez Customize (Personnaliser).

5. Dans la section Application, sélectionnez Désactivé.

6. Cliquez sur SAVE (ENREGISTRER).
7. Revenez au profil de connexion Oracle que vous créez, puis cliquez sur CREATE (CRÉER).

Cela peut se produire si votre base de données contient des milliers de tables et de schémas. Il est possible que certains d'entre eux ne soient pas inclus dans la liste des objets à extraire lors de la configuration de la source du flux dans la console Google Cloud . Au lieu de sélectionner Schémas et tables spécifiques dans la section Sélectionner des objets à inclure, sélectionnez Personnalisé. Dans le champ Critères de correspondance des objets, saisissez les schémas et les tables que vous souhaitez extraire avec Datastream.

Datastream peut supprimer les événements non compatibles pendant la diffusion. Pour résoudre le problème, vous pouvez effectuer les actions suivantes:

• Déclenchez manuellement un remplissage de l'intégralité de la table. Cela fonctionne si les événements supprimés ne sont que des événements UPSERT. Si les événements supprimés incluent des événements DELETE, vous devez tronquer la table dans BigQuery avant d'effectuer le remplissage.

  Pour savoir comment effectuer un remplissage, consultez Lancer un remplissage.

• Contactez l'assistance Google et demandez-lui d'effectuer un remplissage partiel. Cela n'est possible que si vous pouvez identifier les événements supprimés à l'aide d'une clause SQL WHERE et si aucun d'entre eux n'est un événement DELETE.
• Ignorez le problème si le nombre d'événements supprimés est faible ou s'ils ne sont pas importants.

Une erreur peut se produire lors de la récupération des données de capture de données modifiées (CDC) en cours si la configuration de la journalisation supplémentaire n'est pas correcte dans la base de données source. Vérifiez que la journalisation supplémentaire est correctement configurée. Plus précisément, vérifiez que la journalisation supplémentaire est activée pour les tables de base de données qui sont insérées par flux depuis la source vers la destination. La diffusion reprend automatiquement.

Les fichiers journaux ont peut-être été supprimés. Oracle purge les fichiers journaux dès que possible, sauf si vous spécifiez une période de rotation minimale pour les conserver. Sur le serveur Oracle, définissez la durée de conservation des fichiers journaux. Par exemple, utilisez CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS; pour conserver les fichiers journaux pendant au moins quatre jours.

Pour un déploiement RDS, utilisez exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',96);.

Cela peut se produire pour les flux MySQL continus si la configuration du binlog est incorrecte dans la base de données source. Pour résoudre cette erreur, procédez comme suit :

1. Vérifiez que le journal binaire est correctement configuré.
2. Vérifiez que le format du journal binaire de la base de données MySQL est défini sur ROW.
3. Redémarrez le flux.

Cela peut se produire lorsque la base de données source ne respecte pas la matrice de compatibilité des versions. Pour résoudre cette erreur, procédez comme suit :

1. Assurez-vous que la base de données source respecte la matrice.
2. Recréez le flux avec la base de données source mise à jour.

Améliorez la capacité de Datastream à lire à partir de la base de données source:

• Réduisez la taille maximale du fichier de journal binaire (binlog) pour votre base de données source. Réduire la taille augmente le nombre de fichiers binlog.
• S'il existe plusieurs fichiers binlog, définissez le nombre maximal de tâches CDC simultanées pour le flux en conséquence. La présence de plusieurs fichiers binlog permet à Datastream de lire simultanément les événements de la base de données source, jusqu'au nombre défini dans le champ maxConcurrentCdcTasks.

Vérifiez que le décodage logique est correctement configuré. Consultez Configurer une base de données PostgreSQL source.

1. Remplacez l'identité de la réplication par DEFAULT:

   ALTER TABLE TABLE_NAME REPLICA IDENTITY DEFAULT

   Remplacez TABLE_NAME par le nom de la table pour laquelle vous souhaitez modifier l'identité du réplica.
2. Supprimez la table de la liste des objets à inclure du flux. Pour en savoir plus, consultez la section Modifier les informations de configuration concernant la base de données source.
3. Supprimez la table de BigQuery. Pour en savoir plus, consultez la section Supprimer des tables.
4. Dans Datastream, ajoutez à nouveau la table au flux en modifiant la configuration de votre source.

La capture de données modifiées (CDC) doit être activée pour la base de données. Datastream a besoin d'un accès en lecture direct aux journaux de transactions afin de répliquer les modifications en temps réel dans la base de données source et d'obtenir des informations de journal complètes. Activez la CDC pour la base de données, puis réessayez.

Pour savoir comment activer la CDC pour une base de données, consultez Configurer une base de données SQL Server source.

La capture de données modifiées (CDC) doit être activée pour toutes les tables incluses dans le flux. Datastream a besoin d'un accès en lecture direct aux journaux des transactions afin de répliquer les modifications en temps réel apportées aux tables sources et d'obtenir des informations de journal complètes. Activez la CDC pour les tables incluses dans le flux, puis réessayez.

Pour savoir comment activer la capture de données modifiées pour les tables sources, consultez Configurer une base de données SQL Server source.

Ce problème peut se produire lorsque les journaux de transactions n'existent plus dans la base de données source. Lorsque vous répliquez des données à partir d'une source SQL Server à l'aide de la méthode CDC des journaux de transactions, les journaux peuvent être tronqués avant que Datastream ne les lise. Dans ce cas, Datastream ne peut pas répliquer de manière fiable la base de données source vers la destination.

Pour résoudre le problème, récupérez votre flux ou envisagez d'utiliser la méthode CDC des tables de modifications à la place. Pour en savoir plus sur les différences entre les deux méthodes, consultez la section Présentation de SQL Server en tant que source.

L'utilisateur de l'application connectée ou de l'application cliente externe que vous avez configurée pour authentifier la connexion entre votre organisation Salesforce et Datastream ne dispose pas d'autorisations suffisantes pour accéder aux données que vous souhaitez répliquer. Assurez-vous d'avoir correctement configuré votre source Salesforce. Pour en savoir plus, consultez Configurer une source Salesforce.

L'API Salesforce Bulk 2.0 est activée par défaut pour les éditions Performances, Illimitée, Entreprise et Développeur. Ce message d'erreur indique que l'API est désactivée dans votre édition ou que les identifiants que vous utilisez ne disposent pas d'autorisations suffisantes. Assurez-vous que le profil utilisateur que vous utilisez dispose de l'autorisation API Enabled.

Vous avez dépassé la limite de requêtes de l'API Salesforce. Ce message s'affiche lorsque vous atteignez 90% de votre quota de limite d'API. Dans ce cas, Datastream réessaie l'opération plus tard. Vous pouvez envisager d'augmenter votre quota d'API Salesforce.

Lorsque vous interrogez des enregistrements supprimés, Salesforce limite la réponse à 600 000 identifiants d'enregistrement. La granularité de requête la plus faible dans Salesforce est d'une minute. Si vous supprimez plus de 600 000 enregistrements en une minute, Salesforce renvoie cette erreur.

Datastream ne peut pas s'authentifier auprès de Salesforce. Vous avez probablement utilisé de mauvais identifiants ou un mauvais nom de domaine.

Lorsque vous sélectionnez le mode d'écriture Ajout uniquement pour votre flux, vos données sont ajoutées dans BigQuery en tant que flux d'événements INSERT, UPDATE-INSERT, UPDATE-DELETE et DELETE, sans consolidation. Cela peut entraîner l'écriture de lignes en double dans BigQuery lorsque vous effectuez un remplissage en arrière-plan ou lorsqu'un problème se produit et que l'outil d'écriture BigQuery réessaie les opérations d'écriture. Pour résoudre ce problème, nous vous recommandons d'exécuter régulièrement une requête de déduplication semblable à celle-ci:

Vérifiez qu'une clé primaire est définie dans votre table source. BigQuery en a besoin pour fusionner les modifications dans la table de destination.

Si aucune clé primaire n'est définie, envisagez d'en ajouter une dans la table source ou de destination. Pour ajouter une clé primaire dans votre table BigQuery de destination, procédez comme suit:

1. Mettre le flux en pause.
2. Tronquez la table dans BigQuery.
3. Ajoutez la clé primaire à la définition de la table.
4. Relancez le flux.
5. Déclenchez le remplissage de la table.

Par défaut, Datastream n'autorise pas l'ajout d'une clé primaire à une table déjà répliquée dans BigQuery sans clé primaire ni la suppression d'une clé primaire d'une table répliquée dans BigQuery avec une clé primaire. Vous pouvez toutefois modifier la définition de la clé primaire d'une table source répliquée dans BigQuery qui dispose déjà d'une clé primaire:

1. Vérifiez la métrique de latence totale pour le flux et attendez au moins la durée de latence actuelle pour vous assurer que tous les événements en cours d'exécution sont écrits dans la destination. Tous les événements avec la clé primaire d'origine peuvent ainsi être diffusés.
2. Mettez le flux en pause.
3. Copiez la commande LDD (langage de définition de données) CREATE TABLE pour la table dans BigQuery:

       SELECT ddl FROM PROJECT_ID.DATASET.INFORMATION_SCHEMA.TABLES
         WHERE table_name='TABLE_NAME';

   Remplacez les éléments suivants :

   • PROJECT_ID: identifiant de votre Google Cloud projet.
   • DATASET_ID: identifiant de l'ensemble de données dans BigQuery.
   • TABLE_NAME: nom de la table pour laquelle vous souhaitez copier la commande LDD.
4. Placez la table dans BigQuery.
5. Ajustez la commande LDD CREATE TABLE avec les nouvelles clés primaires. Incluez les clés de partition et de cluster, ainsi que le OPTION max_staleness:

       CREATE TABLE `[PROJECT_ID].[DATASET_ID].[TABLE_NAME]`
       (
         product_id INT64 NOT NULL,
         product_name STRING,
         datastream_metadata STRUCT,
         PRIMARY KEY (product_id) NOT ENFORCED
       )
       CLUSTER BY dept_no
       OPTIONS(
         max_staleness=INTERVAL '0-0 0 0:MINS:0' YEAR TO SECOND
       );
       ;
       

   Remplacez les éléments suivants :

   • PROJECT_ID: identifiant de votre Google Cloud projet.
   • DATASET_ID: identifiant de l'ensemble de données dans BigQuery.
   • TABLE_NAME: nom de la table pour laquelle vous avez copié la commande LDD.
   • MINS: nombre de minutes que vous souhaitez définir pour l'option max_staleness, par exemple 15.
6. Exécutez la requête ajustée pour recréer la table dans BigQuery.
7. Relancez le flux.
8. Déclenchez le remplissage de la table.