Dépanner l’ingestion Oracle

info

Bêta

Cette fonctionnalité est en version bêta. Les administrateurs du workspace peuvent contrôler l’accès à cette fonctionnalité depuis la page Aperçus . Voir Gérer les aperçus Databricks.

Cette page décrit les problèmes courants liés au connecteur CDC intégré Oracle dans Databricks Lakeflow Connect et comment les résoudre.

Dépannage général du pipeline

Les étapes de dépannage de cette section s'appliquent à tous les pipelines d'ingestion dans Lakeflow Connect.

Si un pipeline échoue lors de son exécution, cliquez sur l'étape ayant échoué et vérifiez si le message d'erreur fournit des informations suffisantes sur la nature de l'erreur.

Vous pouvez également consulter et download les Logs des clusters depuis la page des détails du pipeline en cliquant sur Update details dans le panneau de droite, puis sur Logs . [[ ## completed ##]] Analysez les logs à la recherche d’erreurs ou d’exceptions.

Vérifier la configuration source

Si une mise à jour du pipeline échoue, confirmez que la base de données source est correctement configurée :

1. Confirmez que le mode archive log est activé :

   SQL

   SELECT LOG_MODE FROM V$DATABASE;

   La query doit retourner ARCHIVELOG.

2. Confirmez que la journalisation supplémentaire est activée :

   SQL

   SELECT supplemental_log_data_min, supplemental_log_data_pk, supplemental_log_data_all FROM V$DATABASE;

   Cette query rapporte la journalisation supplémentaire au niveau de la base de données uniquement. Si vous avez activé la journalisation supplémentaire sur des tables individuelles à la place, ces colonnes peuvent toujours renvoyer NO alors que vos tables sont correctement configurées. Pour vérifier une table spécifique, query ALL_LOG_GROUPS:

   SQL

   SELECT log_group_type FROM ALL_LOG_GROUPS WHERE owner = '<schema>' AND table_name = '<table>';

3. Vérifiez que l'utilisateur de réplication dispose des privilèges accordés par DBX_ORACLE_SETUP_UTIL.GRANT_PERMISSIONS. Voir les exigences relatives aux utilisateurs de base de données Oracle.

Échec de la validation de la journalisation supplémentaire

Databricks valide que chaque table que vous répliquez dispose au moins d'une journalisation supplémentaire de clé primaire. Une table satisfait à cette vérification lorsqu'elle a la journalisation supplémentaire activée directement, ou lorsqu'elle l'hérite du catalogue ou de la base de données. Une journalisation supplémentaire minimale seule ne satisfait pas à cette vérification.

Activez la journalisation supplémentaire de la clé primaire sur la table :

SQL

ALTER TABLE <schema>.<table> ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

Pour savoir comment choisir entre la journalisation supplémentaire par clé primaire et complète, consultez Quelle méthode de journalisation supplémentaire dois-je choisir ?.

Données chiffrées par TDE avec un portefeuille fermé

Si votre base de données possède des espaces de table ou des colonnes chiffrés par Transparent Data Encryption (TDE), le portefeuille de chiffrement (keystore) doit être ouvert. Sinon, LogMiner signale Unsupported Type pour les colonnes chiffrées et la validation échoue. Confirmez le statut du portefeuille :

SQL

SELECT STATUS FROM V$ENCRYPTION_WALLET;

Le statut doit être OPEN. Pour une base de données multi-tenant utilisant un keystore unifié, ouvrez le portefeuille dans CDB$ROOT.

ORA-12514 : le listener ne connaît pas actuellement le service demandé

Le nom de service dans la connexion Unity Catalog est inaccessible. Si votre base de données a DB_DOMAIN défini, les services de base de données enfichable (PDB) s’enregistrent avec un nom qualifié par le domaine. Utilisez le nom de service CDB$ROOT qualifié par le domaine dans la connexion. Voir Domaine de base de données.

Base de données multi-tenant : l'utilisateur ne peut pas voir les données de modification

Pour une base de données multi-tenant (CDB), confirmez que :

• L’utilisateur de réplication est un utilisateur commun (le préfixe C##).
• L'utilisateur a CONTAINER_DATA=ALL défini. L'outil de configuration définit ceci automatiquement. Voir Accès aux conteneurs pour les environnements CDB.
• Le source_catalog dans le pipeline est le nom du service CDB$ROOT.

Logs d’archive purgés avant le traitement

Si Oracle purge les Logs d'archive avant que le pipeline ne puisse les traiter, les tables concernées nécessitent un refresh complet. Augmentez la période de rétention des logs d'archive pour éviter cela. Databricks recommande de conserver les logs d'archive pendant au moins 48 heures.

PERMISSION_DENIED : Vous n’êtes pas autorisé(e) à créer des clusters

Contactez un administrateur de compte Databricks pour vous accorder les autorisations Unrestricted cluster creation, ou utilisez une politique de cluster personnalisée. Voir Exigences.

Une table est ignorée pendant l’ingestion

LogMiner ignore les tables qui contiennent des types de données ou des attributs de stockage non pris en charge (par exemple, BFILE, les tables imbriquées ou les colonnes d'identité). Consultez les limitations de LogMiner.

Le délai de découverte du schéma ou de la table a expiré dans l’assistant d’ingestion

Dans les environnements Oracle de grande taille (par exemple, 100 schémas ou plus, ou 1 000 tables ou plus), l'étape de découverte des schémas et des tables peut expirer. Accordez des droits à l'utilisateur de réplication SELECT uniquement sur les schémas et les tables que vous avez l'intention de répliquer. Cela réduit la portée de la découverte et évite le délai d'expiration. Voir Accorder des privilèges SELECT sur les tables.

authentification default : impossible de configurer les identifiants par défaut

Si vous recevez cette erreur, il existe un problème lors de la découverte des identifiants de l'utilisateur actuel. Essayez de remplacer les éléments suivants :

w = WorkspaceClient()

avec :

w = WorkspaceClient(host=input('Databricks Workspace URL: '), token=input('Token: '))

Voir Authentification dans la documentation du SDK Databricks pour Python.