FAQ sur le connecteur CDC intégré Oracle

info

Bêta

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

Cette page répond aux questions fréquemment posées sur le connecteur CDC intégré Oracle dans Databricks Lakeflow Connect.

FAQ sur les connecteurs gérés généraux

Les réponses figurant dans la FAQ sur les connecteurs gérés s’appliquent à tous les connecteurs gérés dans Lakeflow Connect. Continuez votre lecture pour consulter les FAQ spécifiques aux connecteurs.

Quelle méthode d'extraction le connecteur utilise-t-il ?

Le connecteur utilise Oracle LogMiner en mode non validé et non continu, et se connecte via JDBC. Il n’utilise pas XStream, Oracle GoldenGate ou l’accès direct aux fichiers de logs redo.

En mode non validé, LogMiner lit les changements avant qu’ils ne commit, ce qui permet à la réplication de start immédiatement et maintient une faible charge de traitement et de mémoire (PGA) sur la base de données source. Le pipeline met en attente les changements bruts et applique une transaction à la destination uniquement après avoir lu le commit correspondant. En mode validé, que le connecteur n’utilise pas, LogMiner met en mémoire tampon des transactions entières dans la mémoire PGA de la base de données source, ce que les transactions volumineuses peuvent épuiser.

LogMiner n'est-il pas obsolète ?

Non. Oracle continue de prendre en charge LogMiner en tant que fonctionnalité de base de données intégrée pour interroger les Logs redo en ligne et archivés via SQL. Oracle a rendu obsolète l'option CONTINUOUS_MINE de DBMS_LOGMNR.START_LOGMNR dans Oracle Database 12c et l'a supprimée dans la version 19c, mais le connecteur utilise LogMiner en mode non validé et ne repose pas sur l'extraction continue ; ce changement n'affecte donc pas l'ingestion.

Si le pipeline échoue, l’ingestion reprend-elle sans perte de données ?

Oui. Databricks garde une trace de ce que le connecteur a extrait de la source et appliqué dans la destination. En cas d’incident, Databricks peut reprendre à ce point tant que les logs d’archive restent sur la base de données source. Si les logs d’archive sont purgés avant l’exécution du pipeline, la reprise n’est pas possible et les tables cibles nécessitent un refresh complet.

Le connecteur capture-t-il les fuseaux horaires pour les colonnes de date et d’heure ?

Le connecteur préserve les informations de fuseau horaire pour les colonnes TIMESTAMP WITH TIME ZONE et TIMESTAMP WITH LOCAL TIME ZONE lorsque la précision des fractions de seconde est de 6 ou moins. Les colonnes DATE sont mappées vers TIMESTAMP, et les colonnes TIMESTAMP simples sont ingérées en tant que chaînes, les deux sans conversion de fuseau horaire. Voir la référence du connecteur CDC intégré Oracle.

Quelle méthode de journalisation supplémentaire devrais-je choisir ?

Activez la journalisation supplémentaire au niveau de la table, ou au niveau du conteneur (PDB) ou de la base de données. Lorsqu’il est configuré au niveau du schéma ou du conteneur, les tables héritent du niveau de journalisation supplémentaire configuré.

• La journalisation supplémentaire de clé primaire est le minimum requis et suffit pour la plupart des tables, y compris les tables qui n'ont pas de clé primaire. Lorsqu'une table n'a pas de clé primaire, elle enregistre toutes les colonnes à l'exception des types LOB et LONG, et le connecteur les traite comme une clé groupée lors de l'écriture dans la table Delta de destination.
• La journalisation supplémentaire complète ( Full supplemental logging ) n’est requise que sur les tables dont les colonnes de clé primaire ou de clé unique sont mises à jour par des instructions UPDATE. Sans cela, le pipeline échoue et demande un refresh complet lorsqu’il rencontre une telle mise à jour. Étant donné que cette méthode enregistre chaque colonne dans les logs de redo, elle utilise davantage d’espace disque.

Databricks recommande de répliquer les tables qui possèdent une clé primaire. Voir Activer la journalisation supplémentaire.

À quelle fréquence puis-je planifier l'exécution du pipeline d'ingestion ?

Le pipeline s’exécute en mode Trigger. Pour ingérer des données selon un calendrier récurrent, exécutez-les à partir d’une tâche Lakeflow Jobs, planifiée assez fréquemment pour traiter les modifications avant que les logs d’archivage ne soient purgés sur la source. Consultez les tâches de maintenance courantes des pipelines et la planification des mises à jour récurrentes.

Le connecteur prend-il en charge les bases de données multi-tenant (CDB) ?

Oui. Pour une base de données multi-tenant, créez un utilisateur commun dans CDB$ROOT et utilisez le nom de service CDB$ROOT dans la connexion Unity Catalog. Les instances Amazon RDS multi-tenant pour Oracle ne sont pas prises en charge. Voir Bases de données multi-tenant (CDB).

Puis-je effectuer une ingestion à partir d'une instance physique en veille ou en lecture seule ?

Non. La capture de changements basée sur LogMiner nécessite une instance Oracle principale.

Le connecteur prend-il en charge le Logical Standby utilisant Active Data Guard ?

Non. Le connecteur effectue uniquement la réplication à partir de la base de données principale. Une base de données de secours logique utilise déjà LogMiner pour appliquer les modifications provenant de la base principale et restreint l'accès à LogMiner pour les utilisateurs non-DBA, ce qui empêche toute réplication supplémentaire basée sur LogMiner.

Le connecteur prend-il en charge les réplicas en lecture ?

Non, pas pour le moment.

Le connecteur prend-il en charge Oracle on-premise ?

Oui, pour les bases de données sources accessibles via AWS Direct Connect, Azure ExpressRoute ou un VPN avec une bande passante suffisante.

Le connecteur prend-il en charge Oracle E-Business Suite (EBS) ?

Oui, si vous avez accès à la base de données sous-jacente. Le connecteur lit directement depuis la base de données, et non depuis la couche application.

Le connecteur prend-il en charge les applications Oracle telles que CCS, WACS et Fusion ?

Pas officiellement. Le connecteur se connecte directement à la base de données et lit les changements avec LogMiner ; il n’est donc pas conscient des applications. Si une application expose son port de base de données, le connecteur peut répliquer les tables sous-jacentes, mais il ne prend pas en compte les relations au niveau de l’application entre elles ; les tables associées peuvent donc devenir incohérentes. Pour cette raison, Databricks ne prend pas officiellement en charge Oracle Customer Cloud Service (CCS), Work and Asset Cloud Service (WACS), Oracle Fusion ou des applications similaires.

Puis-je ingérer des données à partir de vues Oracle ?

Non, pas pour le moment. Le connecteur effectue l'ingestion uniquement à partir de tables.