Questions fréquemment posées sur Oracle GoldenGate

Obtenez des réponses aux questions les plus fréquemment posées sur l'implémentation d'IA Oracle GoldenGate.

Pourquoi Oracle GoldenGate est-il important pour l'IA d'entreprise ?

Oracle GoldenGate est important pour l'IA d'entreprise, car l'IA dépend des données d'entreprise actuelles et fiables. Les modèles, les systèmes RAG et les agents d'IA ne peuvent pas justifier ou agir de manière fiable lorsque vous travaillez à partir d'instantanés de batch obsolètes ou de copies incomplètes de données opérationnelles. GoldenGate diffuse les événements métier au fur et à mesure qu'ils se produisent, donnant aux systèmes d'IA un accès à une nouvelle réalité opérationnelle tout en préservant la gouvernance, la cohérence et l'auditabilité.

Comment Oracle GoldenGate prend-il en charge les agents RAG et AI ?

Oracle GoldenGate prend en charge les agents de RAG et d'IA en fournissant en permanence des données opérationnelles dans des bases de données vectorielles, des pipelines RAG, des bases de connaissances d'IA, des lakehouses et des systèmes orientés événements. Grâce aux fonctionnalités d'IA GoldenGate, les enregistrements modifiés peuvent être enrichis, intégrés, résumés, classés ou acheminés dans le cadre du pipeline, de sorte que les systèmes d'IA fonctionnent sur le contexte commercial actuel plutôt que sur des clichés obsolètes.

Comment GoldenGate prend-il en charge les données vectorielles ?

Il peut répliquer des vecteurs existants, déplacer des vecteurs dans Oracle AI Database, transmettre des modifications de vecteurs et générer des incorporations pendant la réplication.

Pourquoi utiliser @AISERVICE ?

Utilisez @AISERVICE lorsque l'intégration ou l'enrichissement doit être exécuté dans un service d'IA externe, tel qu'une adresse gérée ou soutenue par GPU. Reportez-vous à Intégration d'IA externe avec @AISERVICE

Pourquoi utiliser @DBFUNCTION ?

Utilisez @DBFUNCTION lorsque la logique d'intégration doit s'exécuter dans la base de données cible dans le cadre du traitement d'application des modifications. Reportez-vous à Intégration de base de données native avec @DBFUNCTION

Comment les charges vectorielles historiques doivent-elles être gérées ?

Utilisez l'instanciation en masse ou le chargement natif de base de données pour les données historiques, puis laissez GoldenGate traiter les modifications incrémentielles.

Quels sont les principaux cas d'utilisation d'Oracle GoldenGate ?

Oracle GoldenGate est utilisé pour la haute disponibilité et la reprise après sinistre essentielles, les migrations sans temps d'arrêt, les analyses en temps réel, l'ingestion de lakehouse, les architectures orientées événements, les pipelines d'IA et de RAG, les architectures de structure de données et la synchronisation des données régie dans les environnements hybrides et multiclouds.

Oracle GoldenGate prend-il en charge la migration de base de données Oracle E-Business Suite (EBS) et les informations de certification Oracle pour EBS sont-elles toujours valides ?

Oracle EBS ne certifie aucun produit de réplication logique pour les migrations, en se concentrant plutôt sur les méthodes de base de données traditionnelles (import/export, Oracle Data Pump).

Bien que GoldenGate puisse être utilisé pour remplacer une partie du travail effectué par ces méthodes de base de données traditionnelles afin de réduire le temps d'inactivité global associé à une migration, il ne doit pas être utilisé sur tous les objets.

Les projets qui ne sont pas pris en charge par GoldenGate ou qui sont liés au travail temporaire doivent être migrés à l'aide de méthodes traditionnelles pendant une fenêtre de temps d'arrêt.

L'architecture de référence AWS pour GoldenGate avec EFS prend-elle en charge les scénarios de récupération après sinistre inter-région ?

Consultez le blog AWS Haute disponibilité pour l'architecture de microservices Oracle GoldenGate dans AWS, qui décrit une conception de haute disponibilité dans la région.

Dans ce contexte :

• Les caractéristiques de réplication EFS sont quasiment en temps réel au sein d'une région et
• L'architecture est conçue pour les scénarios de basculement locaux.

Pour les scénarios de récupération après sinistre inter-région, le comportement diffère considérablement :

• La réplication EFS est asynchrone (avec un RPO plus élevé, par exemple, minutes), ce qui peut entraîner l'absence de fichiers trace après le basculement
• La promotion des bases de données entre les régions peut introduire des RESETLOGS / nouvelles limites d'incarnation

En raison de ces facteurs, les modèles de conception dans la région décrits dans le blog AWS ne s'étendent pas directement à la récupération après sinistre inter-région sans considérations supplémentaires.

Recommandation :

Pour les architectures inter-région, utilisez le déplacement de données actif (par exemple, GoldenGate Distribution Path) plutôt que de compter sur le stockage partagé répliqué de manière asynchrone pour les fichiers trace.

Quelles sont les versions d'Oracle Database prises en charge par GoldenGate ?

• GoldenGate 19c et 21c prennent en charge les bases de données Oracle de 11.2.0.4 à 21c
• GoldenGate 26ai prend en charge les bases de données Oracle de 19c à 26ai+

Pour plus d'informations, reportez-vous à https://www.oracle.com/integration/goldengate/certifications/.

Quels sont les différents types de configuration et de cas d'utilisation de GoldenGate ?

• Unidirectionnel : les données circulent d'une source à une cible.
• Bidirectionnel : les données circulent entre la source et la cible.
• Multidirectionnel : flux de données entre plusieurs sources et cibles.
• Entreposage de données en temps réel : maintenez votre entrepôt de données à jour grâce à des données transactionnelles en direct.
• Récupération après sinistre : gérez une copie synchronisée de votre base de données à des fins de basculement.
• Migrations sans temps d'arrêt : déplacez les bases de données vers de nouvelles plates-formes ou versions avec un minimum de perturbations.
• Intégration d'applications : partagez des données entre différentes applications en temps réel.
• Cascade : au lieu d'une réplication directe de source à cible, les modifications sont d'abord répliquées vers une instance GoldenGate intermédiaire (ou plusieurs instances), qui propage ensuite les modifications en aval.
• Distribution : topologie de un à plusieurs, architecture et modèle de conception utilisés pour déplacer des données entre plusieurs bases de données, environnements cloud et files d'attente de messages en temps réel.
• Consolidation : Elle permet aux entreprises de centraliser les données provenant de plusieurs sources dans un référentiel unique, également appelé ODS (Operation Data Store), une base de données intégrée en temps réel qui consolide les données de plusieurs systèmes transactionnels pour prendre en charge le reporting opérationnel et la prise de décision.
• Streaming de messages en temps réel : GoldenGate permet aux utilisateurs de publier des messages vers OCI Streaming, Apache Kafka, Confluent et d'autres plates-formes de diffusion en continu de messages certifiées Kafka GoldenGate.
• Lacs de données en temps réel : réplication en temps réel vers des services de stockage cloud (OCI Object Storage, ADLS, Amazon S3, Google Cloud Storage) dans différents formats, notamment JSON, ORC, Parquet, etc.
• Migration MongoDB sans temps d'arrêt : GoldenGate prend en charge les migrations sans temps d'arrêt de MongoDB vers Oracle AI Database, ce qui permet aux clients d'exécuter leurs migrations sans interruption de l'activité.
• Ingestions d'entrepôt cloud : GoldenGate permet aux utilisateurs d'alimenter de grandes quantités de données vers des services d'entrepôt de données natifs du cloud et de lake house tels qu'Autonomous Database, Snowflake, Databricks, etc.
• Data Streams avec les normes AsyncAPI : GoldenGate permet aux développeurs de s'abonner facilement à GoldenGate Data Streams pour intégrer directement leurs applications à GoldenGate en recevant le format JSON dans leurs applications.

Quels sont les composants clés de GoldenGate ?

• Fichiers trace : Les fichiers qui ont capturé les modifications sont stockés.
• Extract : Capture les modifications à partir des fichiers de journalisation/transaction de la base de données source et écrit dans le fichier trace.
• Chemin de distribution : lit le fichier trace et les autres processus vers le système cible où le processus Replicat lit et s'applique à la base de données ou à la cible BigData.
• Replicat : applique les modifications capturées à la base de données cible.

A quoi sert Oracle GoldenGate et quels sont ses principaux cas d'utilisation ?

Oracle GoldenGate est une solution d'intégration et de réplication de données qui capture, transforme et apporte des modifications transactionnelles sur plusieurs systèmes hétérogènes en temps réel.

Les principaux cas d'utilisation d'Oracle GoldenGate sont les suivants :

• Migrations de bases de données sans temps d'arrêt et scénarios d'annulation
• Analyses et reporting en temps réel
• Récupération après sinistre et haute disponibilité
• Régions principales multiples actives/actives/centres de données
• Intégration des données sur les plates-formes on-premise et cloud
• Transmission en continu de messages en temps réel
• Lacs en temps réel
• Migration sans temps d'arrêt MongoDB
• Ingestions d'entrepôt cloud
• Flux de données avec les normes AsyncAPI

Quelles sont les bases de données et plates-formes prises en charge par Oracle GoldenGate ?

Oracle GoldenGate prend en charge un large éventail de bases de données et de cibles, notamment :

• Oracle AI Database
• MySQL
• PostgreSQL
• SQL Server
• Db2 LUW, Db2 z/OS, Db2 pour i
• Amazon RDS, Aurora, Google GCP, Azure Database
• Plates-formes Big Data telles que Kafka et Hadoop
• Flocon de neige
• Apache Iceberg
• Différents formats tels que JSON, Parquet, Avro, Texte délimité, etc.
• Banques de données NoSQL telles que MongoDB, Cassandra, etc.
• Plates-formes de transmission de messages comme Apache Kafka, Azure Event Hubs, Confluent, etc.

Oracle GoldenGate peut capturer à partir des applications Oracle Fusion SaaS et OTM SaaS exécutées dans OCI.

Oracle GoldenGate ne peut pas effectuer de capture à partir de Salesforce.com/SFDC.

Oracle GoldenGate peut répliquer les modifications dans Teradata et TimesTen, mais ne peut pas effectuer de capture à partir de ces deux éléments.

Il est recommandé de consulter les mesures de certification GoldenGate pour obtenir une prise en charge spécifique des bases de données et des cibles. Pour plus d'informations, reportez-vous à https://www.oracle.com/integration/goldengate/certifications/.

Quelles sont les différences entre l'architecture Oracle GoldenGate Classic et l'architecture de microservices ?

• Architecture classique : Modèle monolithique plus ancien avec GGSCI pour l'administration. Supprimé en 26ai.
• Architecture de microservices (MA) : conception modulaire moderne basée sur REST avec des services individuels (par exemple, Service Manager, Service Admin). MA offre une meilleure évolutivité, sécurité et facilité d'utilisation.

Pour plus d'informations sur MA, reportez-vous à Architecture des microservices Oracle GoldenGate.

Quelles sont les différences entre Oracle GoldenGate et les autres outils de réplication ?

Oracle GoldenGate est idéal pour l'intégration de données, la réplication de base de données, le déplacement de données, les migrations de base de données, l'ingestion de données en temps réel pour les raisons suivantes :

• Il prend en charge des centaines de sources et de cibles en gras (https://www.oracle.com/integration/goldengate/certifications/)

• Il a une communauté de soutien incroyable à travers de nombreux canaux différents, y compris
  • https://forums.oracle.com/ords/r/apexds/community/questions?domain=dev-community&clear=RP,1&p1categoryid=323434627485172278516635768604469106823
  • https://www.reddit.com/r/oracle/
  • https://www.dbasupport.com/forums/

• GoldenGate est considéré comme l'étalon-or en matière de réplication de base de données. Tous les concurrents s'efforcent d'être plus comme GoldenGate et prennent en charge les nombreuses fonctionnalités qu'il prend en charge.

• GoldenGate présente de nombreux avantages uniques, notamment la possibilité de créer des abonnements à ses fichiers trace. Pour plus d'informations sur un service entièrement géré dans OCI GoldenGate disponible dans les hyperscalers OCI, Google Cloud et Azure, reportez-vous à A propos des flux de données, Réplication active-active et Analyses de flux de données.

• GoldenGate est aussi essentiel que les bases de données qu'il réplique et de nombreuses topologies peuvent être utilisées pour fournir une récupération après sinistre et une haute disponibilité pour GoldenGate lui-même, y compris une automatisation complète avec des solutions de récupération après sinistre de base de données. https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/maa-platinum-and-oracle-goldengate-best-practices.html

• Vous trouverez d'autres raisons pour lesquelles GoldenGate est le meilleur ici : https://www.oracle.com/a/ocom/docs/techpaper-goldengate-advantages.pdf.

Quels sont les prérequis pour l'installation d'Oracle GoldenGate sur la base de données XYZ ?

Plate-forme et compatibilité

• Version des microservices GoldenGate prise en charge
• Versions de base de données prises en charge (source et cible)
• Système d'exploitation pris en charge (Linux recommandé)
• Système d'exploitation et base de données 64 bits

Modèle de déploiement

• Type de déploiement défini (noeud unique ou multinoeud)
• Cible de déploiement (VM, Bare Metal ou Kubernetes)
• Tous les composants de microservices planifiés (Administration, Distribution, Récepteur, etc.)

Configuration de la base de données

• Base de données en mode ARCHIVELOG / journalisation des transactions
• Journalisation supplémentaire activé
• Utilisateur de base de données GoldenGate disposant des privilèges requis
• Conservation adéquate des fichiers de journalisation/transactions
• clés primaires ou identificateurs uniques sur les tables

Infrastructure et ressources système

• UC et mémoire suffisantes pour l'extraction, la réplication et les services
• Espace disque suffisant pour les fichiers trace, les points de reprise et les journaux
• Hautes performances d'E/S pour le stockage des fichiers trace

Stockage

• Système de fichiers dédié pour le déploiement, les traces et les journaux
• Stockage partagé si la haute disponibilité est requise (par exemple, ACFS ou banque de fichiers cloud)
• Stratégie de nettoyage et de conservation des fichiers trace

Réseau et ports

• Connectivité réseau fiable entre les systèmes
• Ports requis ouverts pour le serveur d'administration, la distribution et le récepteur
• Résolution correcte des noms d'hôte (fichier DNS ou hôtes)
• Faible latence pour la réplication en temps réel

OS et configuration utilisateur

• Utilisateur de système d'exploitation dédié (par exemple, ogg)
• Droits d'accès corrects sur tous les répertoires
• Variables d'environnement requises configurées
• Limites du système d'exploitation configurées (limites pour les fichiers/processus)

Connectivité de la base de données

• Chaînes de connexion/TNS/adresses configurées
• Connectivité testée

Exigences spécifiques aux microservices

• Déploiement géré via le gestionnaire de services
• Banque d'informations d'identification configurée
• Configuration HTTPS (recommandé)
• Proxy inverse ou équilibreur de charge facultatif
• Accès au navigateur pour l'interface utilisateur d'administration

Sécurité

• Stockage sécurisé des informations d'identification
• Configuration TLS/SSL (si nécessaire)
• Règles de pare-feu alignées sur les ports de service
• Accès à l'administration en fonction des rôles

Haute disponibilité (facultatif)

• Conception de déploiement multinoeuds
• Configuration partagée ou répliquée
• Equilibreur de charge pour les services
• Stratégie de basculement définie

Disponibilité opérationnelle

• Synchronisation de l'heure (NTP)
• Configuration de la surveillance et des alertes
• Approche de gestion des journaux
• Sauvegarde avant activation de la réplication
• Planification de la capacité pour la charge de travail

Pour plus d'informations sur la préparation des bases de données pour Oracle GoldenGate, reportez-vous à Préparation des bases de données.

Quelles sont les différences entre les déploiements sécurisés et non sécurisés ?

• Déploiement sécurisé : utilise TLS/SSL pour la communication cryptée, OAuth pour l'authentification et garantit une sécurité de bout en bout. Pour plus d'informations sur les déploiements sécurisés, reportez-vous à Déploiements sécurisés.
• Déploiement non sécurisé : repose sur une communication HTTP/non chiffrée en texte clair. Recommandé uniquement pour les environnements internes/de test.

Comment configurer les microservices Oracle GoldenGate à l'aide d'OGGCA ?

• Exécutez oggca.sh (Linux) ou oggca.bat (Windows).
• Configurez Service Manager et Deployment, en spécifiant des ports, des chemins et des certificats si nécessaire.
• oggca.sh peut également être exécuté en mode silencieux en fournissant un fichier de réponses.

Pour plus d'informations, reportez-vous à Ajouter un déploiement et à Ajouter un déploiement en mode silencieux à l'aide d'OGGCA.

Quelles sont les meilleures pratiques pour optimiser les performances d'Oracle GoldenGate ?

Pour les déploiements Oracle GoldenGate modernes, l'approche recommandée est d'utiliser l'extraction intégrée avec la réplication parallèle, car la réplication parallèle est désormais la méthode de réplication stratégique et préférée pour les opérations d'application de cible hautes performances.

Le processus Replicat intégré est progressivement supprimé au profit du processus Parallel Replicat, car ce dernier offre une meilleure évolutivité, des performances d'application des transactions améliorées et un traitement parallèle plus efficace pour les charges de travail d'entreprise volumineuses.

Une architecture GoldenGate bien optimisée doit séparer les étapes de capture, de transport et d'application en utilisant des fichiers trace locaux et distants, ce qui améliore la résilience et isole la réplication des interruptions réseau. Les performances dépendent également fortement de l'infrastructure sous-jacente, notamment le stockage rapide, la taille appropriée de la mémoire de base de données, une configuration efficace des fichiers de journalisation et une connectivité réseau stable.

La surveillance continue du décalage Extract, du décalage Replicat, du débit et de l'activité des points de reprise est essentielle pour identifier de manière proactive les goulets d'étranglement avant qu'ils n'affectent la latence de réplication.

En général, les meilleures performances de GoldenGate sont obtenues grâce à une combinaison de conception d'architecture évolutive, d'une répartition appropriée des charges de travail, d'un réglage des bases de données et d'un parallélisme soigneusement géré, ce qui permet aux entreprises de maintenir une faible latence et une réplication fiable même dans le cadre de charges de travail transactionnelles volumineuses.

Comment surveiller le décalage et résoudre les problèmes de performances ?

• Utilisez le service Performance Metrics dans MA.
• Utiliser les commandes de décalage et de statut dans le client d'administration et l'API REST
• Recherchez les goulets d'étranglement tels que la latence du réseau ou les E/S de disque.
• Activer la table de signal d'activité
• Utilisateur GoldenGate Module d'extension OEM
• Exporter les mesures avec StatsD
• Afficher le statut actuel dans WebUI

Quels outils ou commandes puis-je utiliser pour surveiller les processus Oracle GoldenGate ?

Dans l'architecture des microservices Oracle GoldenGate, la surveillance est principalement effectuée via le service d'administration Web, les API REST et le service de mesures de performances, plutôt que via les outils d'architecture classiques traditionnels tels que GGSCI. Le service d'administration fournit des tableaux de bord centralisés qui permettent aux administrateurs de surveiller l'état et le statut des processus Extract, Distribution, Récepteur et Réplicat parallèle en temps réel. Grâce à l'interface Web, les utilisateurs peuvent suivre le décalage de réplication, la progression des points de reprise, les débits, le statut des chemins et les performances des processus sur l'ensemble du déploiement. Les API REST fournissent également un accès par programmation aux données de surveillance, ce qui permet l'intégration aux structures d'automatisation et aux plates-formes d'observabilité d'entreprise.

L'un des composants clés de la surveillance dans l'architecture de microservices est le service de mesures de performances (PMSRVR), qui collecte et expose les mesures opérationnelles pour les processus de réplication et les chemins de distribution. Ces mesures peuvent être intégrées aux solutions de surveillance telles qu'Oracle Enterprise Manager, OCI Monitoring, Prometheus et Grafana pour fournir des tableaux de bord centralisés, des alertes et une analyse des performances à long terme. Les administrateurs s'appuient également sur les journaux de déploiement, les fichiers de rapport et les informations de diagnostic disponibles via les interfaces Service Manager et Administration Service pour résoudre les erreurs, surveiller le comportement des processus et examiner les problèmes de latence.

Pour les déploiements OCI GoldenGate, des fonctionnalités de surveillance supplémentaires sont disponibles via la console OCI, OCI Logging, OCI Monitoring et OCI Alarms, offrant une visibilité native du cloud sur l'état du déploiement, le comportement de mise à l'échelle, le décalage de réplication et les événements opérationnels. Dans l'ensemble, la surveillance dans GoldenGate Microservices Architecture se concentre sur l'observabilité centralisée, la gestion basée sur les API et l'intégration aux plates-formes de surveillance d'entreprise pour fournir des informations en temps réel sur les performances de réplication et l'état du système.

Les utilisateurs peuvent créer leurs propres tableaux de bord et application de surveillance en accédant aux exports StatsD et aux appels d'API.

Que sont les fichiers trace et comment Oracle GoldenGate les utilise-t-il dans la réplication ?

Les fichiers trace stockent les modifications de données capturées par le processus Extract dans un format indépendant de la plate-forme.

• Ils servent d'intermédiaire entre les processus Extract et Replicat.

• Fournir une tolérance aux pannes en autorisant la réexécution des modifications capturées.

• Il dissocie les composants Extract et Replicat pour permettre une plus grande flexibilité des architectures GoldenGate, telles que 1 à plusieurs pour la distribution des données, ainsi que la réplication en cascade. Elle rend également la réplication multiplateforme plus efficace.

• Il est au format binaire propriétaire qui peut être interprété par l'utilitaire Logdump, qui est généralement nécessaire lors des sessions de dépannage. Pour plus de détails, reportez-vous au guide Référence Logdump.

• Pour les utilisateurs qui souhaitent utiliser des données directement à partir du fichier trace GoldenGate, la meilleure option est d'utiliser GoldenGate Data Streams, qui permet à l'utilisateur de s'abonner vers un canal géré par GoldenGate Data Streams en lisant les fichiers trace GoldenGate et en insérant chaque enregistrement du fichier trace en tant qu'événement dans ce canal.

Quel est le type de réplication le plus recommandé ?

Commencer par la réplication parallèle : Pour la plupart des cas d'utilisation, en particulier ceux impliquant des charges globales transactionnelles volumineuses, la réplication parallèle non intégrée offre les meilleures performances et flexibilité.

GoldenGate Les applications distribuées et les analyses prennent en charge la réplication classique et coordonnée.

Pour GoldenGate pour les applications distribuées et les analyses, selon la cible, le processus Replicat coordonné offre de meilleures performances.

Comment configurer TLS/SSL pour la réplication sécurisée des données ?

• Oracle GoldenGate prend en charge le cryptage TLS/SSL dans la connexion de banque de données et le chemin de distribution entre les déploiements GoldenGate.

• Pour le chemin de distribution utilisant TLS/SSL, les certificats sont gérés via l'adresse RestAPI du gestionnaire de services. L'utilisation peut également effectuer la tâche de gestion des certificats via WebUI du gestionnaire de services.

• Le chemin de distribution peut être créé sous Service de distribution ou Service de destinataire (chemin initié par la cible).

• Mettez à jour les fichiers de paramètres avec les directives ENCRYPTION.

• Pour sécuriser le chemin de distribution à l'aide de TLS/SSL, le déploiement doit être configuré en tant que "déploiement non sécurisé + NGINX" ou "déploiement sécurisé". Pour plus d'informations, reportez-vous à Données sécurisées en transit et à Comment convertir un déploiement non sécurisé en déploiement sécurisé avec SSL/TLS.

  • Lorsque vous utilisez NGINX, le protocole TLS s'interrompt au niveau de NGINX. Seul le port d'écoute NGINX doit être exposé au trafic entrant.
  • Lorsque vous utilisez un déploiement sécurisé, tous les ports d'écoute des services GoldenGate doivent être exposés au trafic entrant. Le protocole TLS se termine sur les ports de service.

Quelles sont les options de cryptage des fichiers trace ?

• Oracle GoldenGate prend actuellement en charge les trois méthodes de cryptage suivantes : lors de la communication avec Oracle GoldenGate exécuté sur HP NSK, la méthode ENCKEYS est également prise en charge. Cependant, cela est fortement déconseillé si aucune construction NSK HP n'est impliquée. Toutes les méthodes ci-dessus prennent en charge l'algorithme de chiffrement AES.
  • Utiliser la clé de cryptage maître dans le portefeuille
  • Oracle OKV pour coffre sur site
  • OCI KMS pour le service Vault
• Configurez le chiffrement via le paramètre ENCRYPTTRAIL.

Pour plus d'informations sur la sécurisation des données, reportez-vous à Sécuriser les données au repos dans la documentation sur les microservices Oracle GoldenGate.

Comment intégrer Oracle GoldenGate à des fournisseurs d'identités externes (IAM, OAM, par exemple) pour la propre authentification de GoldenGate ?

• L'architecture de microservices Oracle GoldenGate prend en charge l'intégration avec des fournisseurs d'identités externes tels qu'Oracle Identity and Access Management (IAM), Oracle Access Manager (OAM) et Azure Entra ID pour fournir une authentification centralisée, un accès avec connexion unique (SSO) et un contrôle d'accès basé sur les rôles pour les services d'administration et de surveillance GoldenGate. Cette intégration est particulièrement importante dans les environnements d'entreprise et cloud où la gouvernance centralisée des identités, la conformité de la sécurité et l'authentification fédérée sont requises.

• Dans l'architecture de microservices GoldenGate, l'authentification est gérée via le gestionnaire de services et les services d'administration, qui prennent en charge l'intégration avec les fournisseurs d'identités d'entreprise à l'aide de normes telles que OAuth 2.0, OpenID Connect (OIDC), SAML et l'authentification LDAP en fonction du modèle de déploiement et des fonctionnalités du fournisseur. Pour les déploiements OCI GoldenGate, l'intégration est généralement effectuée via Oracle Cloud Infrastructure Identity and Access Management (OCI IAM), ce qui permet aux administrateurs d'utiliser des utilisateurs, des groupes, des stratégies et des services de fédération OCI centralisés pour un accès sécurisé aux déploiements GoldenGate et aux API REST.

• Lors de l'intégration à Oracle Access Manager (OAM) ou aux solutions SSO d'entreprise, GoldenGate est généralement configuré derrière un proxy inverse ou une passerelle Web qui gère l'authentification et la validation de jeton. Une fois l'authentification réussie, les informations d'identité et d'autorisation de l'utilisateur sont transmises aux services GoldenGate. Cette approche permet de centraliser les stratégies de connexion, l'application de l'authentification à plusieurs facteurs, la gestion des sessions et la fédération d'identités d'entreprise sans avoir besoin d'informations d'identification distinctes propres à GoldenGate.

• Pour les intégrations Azure Entra ID, GoldenGate peut utiliser les services d'annuaire externe fournis par Entra ID pour l'authentification des utilisateurs et la mise en correspondance des rôles, ce qui permet aux organisations de gérer l'accès administratif via les stratégies de sécurité et les groupes d'utilisateurs d'entreprise existants. Le contrôle d'accès basé sur les rôles peut ensuite être appliqué pour contrôler les droits d'accès pour l'administration, la gestion du déploiement, la surveillance et l'accès aux API dans l'environnement GoldenGate.

• GoldenGate Les API REST peuvent également être sécurisées à l'aide de mécanismes d'authentification d'entreprise, ce qui permet aux plates-formes d'automatisation externes, aux pipelines d'intégration continue et de déploiement continu et aux outils de surveillance de s'authentifier à l'aide de jetons d'identité centralisés plutôt que de comptes de service locaux. Dans les déploiements cloud natifs et hybrides, cette intégration améliore la cohérence de la sécurité sur les plates-formes d'entreprise tout en simplifiant la gestion du cycle de vie des utilisateurs et la conformité des audits.

• Globalement, l'intégration d'Oracle GoldenGate à des fournisseurs d'identités externes permet une authentification centralisée, une authentification unique, une gestion des identités fédérée et des contrôles de sécurité de niveau entreprise, ce qui facilite la sécurité et la gestion des déploiements GoldenGate dans les environnements d'entreprise et OCI à grande échelle.

• Chaque fournisseur d'ID a une implémentation légèrement différente sur l'adresse pour la demande de jeton, même avec OIDC et la norme OAuth 2.0. GoldenGate devra créer un profil spécifique pour que ce fournisseur d'ID s'intègre à GoldenGate. Par conséquent, si votre fournisseur d'ID ne figure pas sur la liste prise en charge, vous pouvez générer une demande d'amélioration.

Comment migrer des bases de données sans temps d'arrêt à l'aide d'Oracle GoldenGate ?

Oracle GoldenGate permet des migrations de base de données quasiment sans temps d'arrêt en répliquant en permanence les modifications transactionnelles de la base de données source vers la base de données cible pendant que les deux systèmes restent en ligne. Au lieu de nécessiter une longue période d'indisponibilité pour les activités d'export, d'import et de basculement, GoldenGate permet aux entreprises de synchroniser les données en temps réel afin que le basculement final de la migration puisse être effectué avec une interruption minimale des applications.

Dans une architecture de migration sans temps d'arrêt standard, GoldenGate capture les modifications de la base de données source à l'aide de l'extraction intégrée et les écrit dans des fichiers trace. Les modifications sont ensuite transmises via Distribution Services et appliquées à la base de données cible à l'aide de la réplication parallèle. Pendant que le chargement initial des données est migré via la sauvegarde/restauration, Data Pump, la duplication RMAN ou d'autres méthodes de chargement en masse, GoldenGate réplique en permanence les transactions en cours afin que la cible reste synchronisée avec la source tout au long du processus de migration.

Le workflow de migration suit généralement plusieurs phases :

• préparation et configuration de l'environnement
• chargement initial des données
• réplication de modification continue
• validation et synchronisation
• coupure contrôlée

Au cours de la phase de chargement initial, une copie complète de la base de données est transférée vers l'environnement cible. Une fois les données de référence chargées, GoldenGate applique toutes les modifications transactionnelles en cours capturées à partir de la base de données source. Cette réplication continue réduit considérablement la période d'indisponibilité car la base de données cible est déjà presque synchronisée avant le début du basculement.

La validation des données est un élément essentiel des migrations sans temps d'arrêt. Oracle GoldenGate Veridata est couramment utilisé pour comparer les bases de données source et cible lors de la réplication afin de garantir la cohérence des données avant la permutation de production. La validation continue permet d'identifier rapidement les divergences et réduit les risques de migration.

Au moment du basculement, l'activité de l'application est brièvement mise en pause, les transactions restantes peuvent être répliquées et les administrateurs vérifient que le décalage de réplication atteint zéro. Une fois la synchronisation confirmée, les applications sont redirigées vers la base de données cible et l'environnement cible devient le nouveau système de production. Etant donné que la plupart des mouvements de données se sont produits pendant que les systèmes étaient en ligne, la fenêtre d'indisponibilité réelle est généralement réduite au seul processus final de synchronisation et de redirection d'application.

GoldenGate prend en charge les migrations sans temps d'arrêt dans les domaines suivants :

• Migrations entre Oracle et Oracle
• mises à niveau entre versions
• migrations de plate-forme
• migrations sur site vers OCI
• migrations de base de données hétérogènes
• transitions multicloud et cloud hybride

Dans les déploiements OCI GoldenGate et l'architecture de microservices GoldenGate moderne, la gestion de la migration est encore plus simplifiée grâce à des interfaces Web centralisées, des API REST, des services de déploiement automatisés et des fonctionnalités de surveillance intégrées. Les services de réplication parallèle, de capture intégrée et de distribution évolutive permettent de gérer efficacement les charges de travail transactionnelles volumineuses pendant les activités de migration.

Dans l'ensemble, Oracle GoldenGate permet des migrations sans temps d'arrêt en combinant une réplication en temps réel continue, un traitement parallèle évolutif, une validation continue et des procédures de basculement contrôlées, ce qui permet aux entreprises de migrer des bases de données critiques avec un minimum de perturbations de l'activité et une réduction des risques opérationnels.

Quelles sont les meilleures pratiques de configuration de la réplication bidirectionnelle ?

Les meilleures pratiques de configuration de la réplication bidirectionnelle avec Oracle GoldenGate sont les suivantes :

• Définir une architecture de réplication active-active et des règles de propriété des données claires.
• Evitez les conflits de mise à jour en vous assurant que les mêmes données ne sont pas modifiées simultanément sur les deux systèmes chaque fois que cela est possible.
• Configurer les stratégies de détection et de résolution des conflits (CDR) de manière appropriée.
• Utilisez des clés primaires ou des clés uniques sur toutes les tables répliquées.
• Assurez-vous que les tables source et cible ont des structures et des types de données identiques.
• Excluez de la réplication les tables, objets temporaires et opérations non prises en charge inutiles.
• Utilisez des mécanismes de prévention des boucles pour éviter que les transactions répliquées ne soient renvoyées au système d'origine.
• Gérer les jeux de caractères, les fuseaux horaires et les définitions de schéma de base de données synchronisés.
• Surveillez en permanence le décalage de réplication, l'état des processus et les événements de conflit.
• Testez régulièrement les procédures de basculement, de permutation et de récupération.
• Configurez des points de reprise et une gestion de trace appropriés.
• Séparer les charges de travail et dimensionner l'infrastructure de manière appropriée pour le trafic actif-actif.
• Utiliser la journalisation supplémentaire et les configurations de journalisation des transactions appropriées.
• Mettre en œuvre des pratiques strictes de surveillance, d'alerte et d'audit.
• Validez régulièrement la cohérence des données à l'aide d'outils tels qu'Oracle GoldenGate Veridata.
• Planifiez soigneusement la réplication LDD et les modifications de schéma.
• Documenter clairement les règles de gestion des conflits et les procédures opérationnelles.

Les environnements de réplication bidirectionnelle nécessitent une planification minutieuse car ils sont plus complexes que la réplication unidirectionnelle et peuvent présenter des défis tels que :

• conflits de mise à jour
• boucles de réplication
• divergences de données
• sensibilité à la latence
• complexité opérationnelle.

Qu'est-ce que cela signifie lorsque le processus Replicat affiche des transactions bloquées et comment le corriger ?

Lorsque le processus Replicat affiche des transactions bloquées, cela signifie généralement que le processus Replicat ne peut pas appliquer une ou plusieurs transactions sur la base de données cible et que la progression de la réplication s'arrête ou est retardée.

Les causes courantes sont les suivantes :

• verrous de base de données ou sessions bloquantes sur la cible
• enregistrements manquants ou en conflit
• violations de contrainte
• erreurs de clé en double
• opérations non prises en charge
• transactions à longue durée d'exécution
• non-concordance de type de données
• problèmes de réseau ou de connectivité
• ressources système insuffisants

Les étapes de dépannage standard sont les suivantes :

• examiner le fichier de rapport Replicat et le fichier de rebut pour détecter les erreurs
• consultez les journaux d'erreurs GoldenGate
• Identifier la transaction ou la table à l'origine du blocage
• vérifier la disponibilité et l'état de la base de données cible
• vérification des objets verrouillés ou des sessions bloquantes
• résoudre les conflits de données ou les problèmes de contrainte
• confirmer que les fichiers trace sont accessibles et intacts
• vérification de la progression du point de reprise
• redémarrer le processus Replicat après avoir corrigé le problème si nécessaire

Dans certains cas, les administrateurs peuvent avoir besoin de :

• ignorer les transactions problématiques,
• repositionner Replicat,
• ou resynchroniser les tables concernées

selon le cas, la gravité et les besoins de l'entreprise.

Comment gérer l'espace disque et purger les anciens fichiers trace dans Microservices ?

Dans l'architecture des microservices Oracle GoldenGate, la gestion de l'espace disque et la purge des fichiers trace sont importantes pour éviter l'épuisement du stockage et maintenir des environnements de réplication en bon état.

Les fichiers trace sont généralement gérés à l'aide de stratégies de purge automatisées qui suppriment les anciens fichiers trace une fois qu'ils ne sont plus nécessaires par les processus en aval.

Les pratiques courantes sont les suivantes :

• configuration de la purge automatique des fichiers trace
• surveiller régulièrement l'utilisation du disque
• séparation du stockage de trace et du stockage du système d'exploitation
• utilisation de systèmes de fichiers ou de volumes dédiés
• définition de stratégies de conservation en fonction des exigences de récupération

Les fichiers trace peuvent généralement être purgés lorsque :

• tous les processus Extract et Replicat les ont traités
• Les points de reprise ont progressé au-delà des fichiers
• les fichiers ne sont pas destinés à la récupération ou à la resynchronisation

Dans les microservices, la gestion des traces est généralement gérée via :

• le serveur d'administration
• Service de distribution
• Service de destinataire
• outils d'administration en ligne de commande
• API REST ou

Les recommandations supplémentaires sont les suivantes :

• activation de la surveillance et des alertes de l'espace disque
• archivage des traces si nécessaire pour l'audit
• utilisation du stockage externe pour de longues périodes de conservation
• vérification périodique des stratégies de purge et des tendances de croissance du stockage

Une bonne gestion des traces permet d'éviter :

• arrêts de réplication
• conditions complètes du disque
• dégradation des performances
• complications de récupération.

Comment configurer le démarrage et le redémarrage automatiques dans les microservices ?

Dans l'architecture des microservices Oracle GoldenGate, le démarrage et le redémarrage automatiques peuvent être configurés pour démarrer et récupérer automatiquement les services de déploiement et les processus de réplication après des échecs ou des redémarrages de serveur.

Cette configuration est généralement effectuée par :

• activation des profils de démarrage automatique pour les processus d'extraction et de réplication
• activation des stratégies de redémarrage automatique avec intervalles de nouvelle tentative et nombre de nouvelles tentatives
• configuration du comportement de démarrage du gestionnaire de services
• intégration du déploiement avec des services de système d'exploitation ou des plates-formes d'orchestration de conteneurs

Les paramètres de redémarrage automatique permettent de garantir une haute disponibilité en redémarrant automatiquement les processus en échec sans intervention manuelle.

Les options courantes de configuration sont les suivantes :

• délai de démarrage
• nombre de nouvelles tentatives
• retry interval
• ordre de dépendance
• seuils d'échec

Ces paramètres peuvent généralement être gérés via :

• l'interface Web des microservices GoldenGate
• API REST
• ou outils d'administration en ligne de commande

Le démarrage et le redémarrage automatiques sont couramment utilisés dans :

• environnements haute disponibilité de production
• déploiements cloud
• environnements en conteneur
• architectures de reprise après sinistre
• systèmes de réplication sans surveillance.

Quelles sont les étapes de dépannage du décalage de réplication ?

Les étapes courantes de dépannage pour le décalage de réplication Oracle GoldenGate sont les suivantes :

• Vérifiez le statut du décalage à l'aide des commandes ou des tableaux de bord de surveillance GoldenGate.
• Vérifiez si les processus Extract, Pump ou Replicat s'exécutent normalement.
• Recherchez les avertissements ou les échecs dans les fichiers de rapport GoldenGate et les journaux d'erreurs.
• Recherchez les éventuelles transactions à longue durée d'exécution sur la base de données source.
• Surveillez la latence et la bande passante du réseau entre les systèmes source et cible.
• Vérifiez que les fichiers trace sont générés et utilisés correctement.
• Vérifiez l'utilisation de la CPU, de la mémoire, des E/S de disque et du stockage sur les serveurs source et cible.
• Assurez-vous que la progression du point de reprise avance normalement.
• Passez en revue les problèmes de performances de la base de données, tels que les verrous, les requêtes lentes ou les conflits de ressources.
• Vérifiez que les journaux d'archivage ou de transactions sont disponibles et qu'ils ne sont pas manquants.
• Recherchez les opérations par lots volumineuses ou les pics de volume de transactions.
• Réglez les performances du processus Replicat à l'aide du parallélisme ou du traitement par lots si nécessaire.
• Vérifiez que les emplacements de disque du fichier trace disposent d'un espace suffisant.
• Validez les configurations de paramètres pour les processus Extract, Pump et Replicat.
• Redémarrez les processus concernés si nécessaire après avoir résolu la cause première.

L'analyse du décalage de réplication se concentre généralement sur l'identification de l'origine du goulet d'étranglement :

• activité de la base de données source,
• retards du réseau,
• GoldenGate traitement,
• ou les performances de la base cible.

Comment utiliser GoldenGate pour les flux de données distribués et la dualité relationnelle JSON ?

• Les vues de dualité relationnelle JSON d'Oracle Database 23ai permettent aux développeurs d'utiliser facilement des données relationnelles en tant que modèles de documents JSON. Cela combine les avantages des documents JSON avec ceux du modèle relationnel, tout en évitant les limites de chacun. La vue de dualité relationnelle JSON d'Oracle est essentiellement une vue SQL qui présente les données JSON dans un format relationnel structuré.
• La réplication d'objets métier avec Oracle JSON Relational Duality et GoldenGate Data Streams donne la priorité aux produits de données et devient la source unique d'informations fiables pour les applications, les structures de transaction, les maillages de données/événements et les structures de données en garantissant l'unicité des objets de données.
• Pour plus d'informations sur la configuration des flux de données GoldenGate avec la dualité relationnelle JSON, reportez-vous à Oracle LiveLabs.

Quelles sont les options avancées de transformation des données dans GoldenGate ?

• Utiliser les fonctions de mise en correspondance, de filtrage et de transformation des colonnes dans les fichiers de paramètres.
• Intégrer SQLEXEC pour les requêtes ou procédures personnalisées.

GoldenGate peut-il être exécuté sur z/OS pour capturer les modifications apportées à Db2 ou les transmettre à zOS ?

• GoldenGate n'exécute pas l'extraction/la réplication directement sur z/OS. Au lieu de cela, le processus Extract/Replicat s'exécutera à distance sur la plate-forme de support telle que AIX/Linux/zLinux et se connectera au système d'exploitation z/OS Db2 pour la capture à distance et la livraison à distance.
• GoldenGate doit installer un petit package vers Db2 z/OS pour appeler certaines API afin de capturer les modifications à partir des fichiers journaux Db2. Les détails sont disponibles dans la section Install Extract Components on Db2 z/OS.

Si vous exécutez uniquement Replicat sur le système d'exploitation z/OS Db2, ce package n'est pas nécessaire.

GoldenGate pour Db2 pour i et Db2 LUW dispose-t-il d'une architecture de microservices ?

• Oui. A partir de GoldenGate 26ai, GoldenGate a ajouté l'architecture de microservices et uniquement l'architecture de microservices pour ces deux builds.
• Avant 26ai, seules les architectures classiques sont disponibles pour les deux versions.

GoldenGate fournit-il des pilotes ODBC dans Db2 pour i/Db2 pour l'installation de build LUW/Db2 z/OS ?

Non, l'utilisateur final devra installer les pilotes ODBC appropriés en utilisant son propre contrat de licence avec IBM pour ces pilotes ODBC s'ils ne sont pas déjà installés sur le serveur sur lequel GoldenGate est en cours d'installation. Reportez-vous au guide de l'utilisateur du pilote ODBC d'IBM pour savoir comment télécharger les pilotes ODBC appropriés.

Comment exécuter GoldenGate dans le conteneur Docker ?

Oracle GoldenGate peut être exécuté dans des conteneurs Docker en déployant le logiciel GoldenGate en tant que service en conteneur. Oracle fournit des images de conteneur GoldenGate via Oracle Container Registry (OCR), ce qui permet aux utilisateurs d'extraire et de déployer des images prédéfinies pour une configuration et des environnements standardisés plus rapides.

L'exécution de GoldenGate dans des conteneurs offre des avantages tels que :

• déploiement et mises à niveau simplifiés
• portabilité entre les environnements
• évolutivité simplifiée
• meilleure intégration avec les plates-formes cloud natives

GoldenGate L'architecture de microservices est généralement préférée pour les déploiements de conteneurs car elle est conçue pour les environnements distribués modernes et fonctionne bien avec les plates-formes d'orchestration Docker et Kubernetes.

Les déploiements GoldenGate en conteneur sont couramment utilisés dans :

• environnements cloud
• Pipelines CI/CD
• Plates-formes Kubernetes
• architectures hybrides et multiclouds
• solutions innovantes de réplication et de diffusion de données

Le stockage persistant est généralement configuré en externe pour conserver les traces, les points de reprise et les données de configuration en dehors du cycle de vie du conteneur.

A quoi sert OCI GoldenGate ?

Oracle Cloud Infrastructure (OCI) GoldenGate est une plate-forme Data Fabric cloud native entièrement gérée qui permet le déplacement, l'intégration et la diffusion en temps réel de données dans des environnements hétérogènes à l'échelle de l'entreprise. Il capture et fournit des modifications de données transactionnelles avec une faible latence entre les bases de données, les entrepôts de données, les plates-formes d'analyse, les systèmes de messagerie et les services cloud.

En tant que composant central d'une stratégie Data Fabric innovante, OCI GoldenGate aide les entreprises à connecter, synchroniser et rendre opérationnelles les données distribuées dans les environnements sur site, hybrides et multicloud. Il prend en charge un large éventail de cas d'utilisation, notamment la réplication de données en temps réel, les migrations sans temps d'arrêt, le reporting opérationnel, les architectures orientées événements, les analyses de diffusion en continu, les pipelines de données d'IA/ML et la synchronisation des données.

OCI GoldenGate fournit également des fonctionnalités intégrées pour concevoir, orchestrer, surveiller, transformer, valider et comparer des pipelines de données via une expérience utilisateur unifiée et intuitive.

Dans quelles régions OCI GoldenGate est-il disponible ?

Recherchez ici les régions en cours sur lesquelles OCI GoldenGate est déployé - https://www.oracle.com/cloud/data-regions/

Où puis-je trouver la documentation OCI GoldenGate ?

La documentation OCI GoldenGate est disponible à l'adresse suivante : https://docs.oracle.com/en/cloud/paas/goldengate-service/index.html

Quels sont les principaux cas d'utilisation d'OCI GoldenGate ?

Voici les principaux cas d'utilisation d'OCI GoldenGate :

• Réplication de données : migration, CDC, reporting hors ligne, entreposage de données en temps réel, intégration avec des sources et des cibles non Oracle, et ingestion et livraison Big Data
• Pipelines de données : corréler les événements de données et les données ETL dans des micro-batches
• Analyse de diffusion en continu : séries chronologiques, ML intégré et géospatial
• Vérification des données : comparer les données à grande vitesse
• Expérience utilisateur simple pour déplacer des données sur site vers des bases de données Autonomous AI, Cloud at Customer et Object Storage
• Des cas d'utilisation simples de haute disponibilité/récupération après sinistre et multi-actifs pour les déploiements de région à région OCI, hybrides, sur site à OCI et multicloud continueront d'évoluer à mesure que de nouveaux types et fonctionnalités de déploiement seront ajoutés.

Quelles sont les différences entre OCI GoldenGate et GoldenGate sur OCI Marketplace ?

Voici quelques différences entre les deux offres :

• OCI GoldenGate est un service entièrement géré où Oracle gère les opérations d'infrastructure telles que les sauvegardes, l'application de patches et les mises à niveau. GoldenGate sur OCI Marketplace est géré par le client.
• OCI GoldenGate utilise des structures de service OCI telles que les déploiements, les connexions, les adresses privées et le redimensionnement géré
• OCI GoldenGate est basé sur des microservices et ne prend pas en charge l'architecture classique
• Tarification : OCI GoldenGate utilise des crédits universels et il existe un chemin BYOL pour les utilisateurs sur site. GoldenGate sur OCI Marketplace nécessite des licences on-premise.
• Connectivité simplifiée aux bases de données d'IA autonomes dans OCI GoldenGate avec gestion automatique des portefeuilles et prise en charge des adresses privées par rapport à une configuration plus manuelle dans GoldenGate sur OCI Marketplace.
• Redimensionnement : OCI GoldenGate évolue automatiquement jusqu'à 3 fois le nombre d'OCPU sélectionnées lors de la création d'une instance (limite maximale de 24 OCPU par déploiement). Le redimensionnement d'une instance est manuel avec GoldenGate sur OCI Marketplace.

Où puis-je trouver les objectifs de niveau de service et les contrats de niveau de service ?

Utilisez le document pilier du service cloud public Oracle PaaS et IaaS en cours et la page de contrat de niveau de service Oracle Cloud en cours :

https://www.oracle.com/cloud/sla/.

Combien coûte OCI GoldenGate ?

OCI GoldenGate est facturé en fonction de l'OCPU utilisée par l'hôte OCI GoldenGate. La mesure d'OCPU par heure suit la définition standard :

• OCPU par heure correspond au nombre d'heures d'unité Oracle Compute (OCPU) utilisées dans le cadre du service Oracle Cloud. Une OCPU fournit la capacité d'UC équivalente à l'un coeur physique de processeur avec hyperthread activé. Chaque OCPU correspond à deux threads d'exécution matériels, appelés UC virtuelles. Chaque OCPU dispose d'une quantité de mémoire prédéfinie. Chaque heure d'OCPU partielle consommée est facturée comme une heure complète.

• Il n'y a pas de minimum d'OCPU.
• Prix par OCPU et par heure : 1,3441 $
• Nombre d'OCPU de déploiement OCI GoldenGate : entre 1 et 24 OCPU
• Stratégie de redimensionnement automatique :
  • Les clients peuvent activer ou désactiver le redimensionnement automatique.
  • Les clients choisissent une taille de base (minimum) parmi 1‚ 24 OCPU (entre 1 et 8 OCPU de base si le redimensionnement automatique est activé).
  • Le redimensionnement automatique est 3x la taille de base sélectionnée comme suit :
    • Redimensionnement automatique d'OCI GG :
      • Choix de l'utilisateur : Activer ou désactiver le redimensionnement automatique : l'utilisateur peut choisir s'il souhaite le redimensionnement automatique
        • Choisir la taille de base : pour les besoins de la facturation, l'utilisateur choisit la taille de base dans les OCPU.
        • Redimensionnement automatique : le redimensionnement s'effectue automatiquement et de manière transparente
      • Surveillance : OCI GoldenGate émet une télémétrie sur le nombre d'OCPU utilisées à un moment donné
      • Heures partielles : suivez les mêmes règles qu'Autonomous Database et Exadata Cloud Service : "Aux fins d'Oracle Autonomous Data Warehouse et d'Oracle Autonomous Transaction Processing, les heures d'OCPU partielles consommées sont facturées en tant qu'heures partielles avec un minimum d'une minute."
      • Utilisation maximale : suivez les mêmes règles qu'Autonomous Database et Exadata Cloud Service : si le redimensionnement automatique est activé, Cloud Service fournira toujours une capacité pour le nombre d'OCPU que vous avez indiqué lors de la création ou du redimensionnement explicite. votre service, mais Cloud Service peut également fournir des OCPU supplémentaires (jusqu'à 3x au total du nombre d'OCPU indiquées lors de la création ou du redimensionnement explicite de votre service) selon les besoins, en fonction de votre charge de travail. La consommation d'OCPU par heure est calculée comme suit : nombre maximal (nombre d'OCPU pour votre service, OCPU réelles utilisées par votre service). L'utilisation réelle d'OCPU est basée sur la consommation par minute, moyenne sur l'heure."

Vous pouvez également vous référer à l'estimateur cloud qui inclut OCI GoldenGate dans la catégorie Intégration de données : https://www.oracle.com/cloud/costestimator.html

Comment fonctionnent les licences pour BYOL ?

Taux de conversion :

• Pour chaque 8 licences de processeur, vous pouvez activer jusqu'à 1 OCPU d'OCI GoldenGate.
• Pour chaque tranche de 400 licences Named User Plus prises en charge, vous pouvez activer jusqu'à 1 heure OCPU d'OCI GoldenGate.

L'une des licences de logiciels prises en charge suivantes peut être agrégée pour atteindre le taux de conversion ci-dessus :

• ou Oracle GoldenGate
• Oracle GoldenGate pour non Oracle AI Database ou
• Oracle GoldenGate for Distributed Applications and Analytics ou
• Oracle GoldenGate for Big Data (mais pas les cibles Oracle GoldenGate for Big Data)

Puis-je migrer ma place de marché GoldenGate vers OCI GoldenGate ?

• La migration de GoldenGate (GoldenGate on-premise ou GoldenGate Marketplace) vers OCI GoldenGate n'est pas automatisée.
• OCI GoldenGate s'appuie sur l'architecture de microservices GoldenGate. Par conséquent, si le client utilise déjà GoldenGate (sur site, sur Compute ou sur OCI Marketplace), il s'agit d'une migration technique très simple. Pour plus d'informations, reportez-vous à la section Migration vers Oracle Cloud Infrastructure GoldenGate.
• Si le client utilise l'architecture classique GoldenGate, un travail supplémentaire sera nécessaire pendant la migration. Ce parcours de migration est un parcours de migration éprouvé que de nombreux clients ont déjà réalisé avec succès pour leurs investissements sur site. Un utilitaire de migration de GoldenGate Classic vers GoldenGate Microservices est également disponible, qui peut être utilisé pour aider les clients à migrer.

Comment dimensionner correctement OCI GoldenGate ?

OCI GoldenGate utilise une architecture hub.

• Toutes les données sont acheminées via l'hôte OCI GoldenGate.
• Les données sont capturées à distance à partir de la source.
• Les données sont transmises à distance à la cible.
• Consulter les informations de mesure et de facturation
• Présentation de A propos de l'utilisation d'OCPU
• Examinez les considérations relatives au dimensionnement de votre type de déploiement dans Gestion et facturation des OCPU

Remarque :

• Il existe de nombreuses variables relatives aux performances (réseau, base de données source/cible, utilisation efficace des index, forme du schéma, etc.). Par conséquent, les tests réels sur les charges de travail de production constituent la référence en matière de dimensionnement approprié.
• Vous pouvez surveiller l'utilisation des OCPU sur la page Détails sur le déploiement d'OCI GoldenGate et dans l'explorateur de mesures de la console OCI.
• Vous pouvez définir des alarmes dans la console OCI afin de vous avertir lorsque l'utilisation des OCPU atteint certains niveaux.

Quelles sont les sources et les cibles prises en charge dans OCI GoldenGate ?

Pour obtenir des informations sur les systèmes source et cible pris en charge, reportez-vous à Exploration des connexions.

OCI GoldenGate peut-il se connecter à des adresses IP privées ou à des systèmes Oracle sur site ?

Oui. Pour plus d'informations sur la connectivité, reportez-vous à Connectivité OCI GoldenGate.

La connectivité OCI GoldenGate à la source et à la cible est activée avec la capture à distance et la distribution à distance.

Comment configurer un chemin de distribution entre OCI GoldenGate et GoldenGate exécuté sur OCI Marketplace ou sur site ?

Les LiveLabs suivants expliquent comment créer des chemins de distribution entre OCI-GG et une installation de microservices GG :

• Envoyer des données d'Oracle GoldenGate vers OCI GoldenGate
• Envoyer des données d'OCI GoldenGate vers Oracle GoldenGate

OCI GoldenGate prend-il en charge les bases de données Oracle à instance unique ?

Oui. Les instances pluggables (locatives multiples) et uniques sont prises en charge.

Les bases de données autonomes dédiées sont-elles prises en charge ?

Oui. Les environnements Autonomous AI Database on Dedicated Infrastructure sont entièrement pris en charge.

Consultez la documentation actuelle d'Autonomous AI Database et d'OCI GoldenGate pour connaître les prérequis exacts : Oracle Autonomous AI Database

Puis-je accéder à OCI GoldenGate et le surveiller à l'aide d'Oracle Management Cloud et d'Oracle Enterprise Manager (OEM) ?

Le pack de gestion pour GoldenGate prend désormais en charge OCI GoldenGate.

A quoi sert Oracle GoldenGate Foundation Suite ?

Oracle GoldenGate Foundation Suite est un ensemble de trois produits. Il s'agit des détails suivants :

• Oracle GoldenGate Veridata
• Oracle GoldenGate Management Pack (module d'extension et moniteur EM)
• Oracle GoldenGate Studio

A quoi sert Oracle GoldenGate Veridata ?

Oracle GoldenGate Veridata est une solution à grande vitesse de comparaison et de réparation des données qui identifie, signale et corrige les différences de données entre les bases de données hétérogènes sans interrompre automatiquement les processus métier en cours. Il fournit une solution facile à utiliser mais puissante pour identifier les données non synchronisées avant qu'elles n'aient un impact négatif sur l'entreprise.

Quels sont les différents composants d'Oracle GoldenGate Veridata ?

Les différents composants d'Oracle GoldenGate Veridata sont les suivants :

• Agent Veridata
• Serveur Veridata
• Base de données du référentiel Veridata
• Utilitaire Vericom - CLI

Comment la comparaison des données en temps réel est-elle effectuée avec Oracle GoldenGate Veridata ?

Oracle GoldenGate Veridata effectue une comparaison des données en temps réel en comparant les bases de données source et cible pendant l'exécution de la réplication Oracle GoldenGate.

Voici le processus général :

1. GoldenGate réplique les modifications transactionnelles de la base de données source vers la base de données cible en temps quasi réel.

2. Veridata se connecte indépendamment aux bases de données source et cible.

3. Il compare les données dans des blocs configurables ou des plages de lignes à l'aide des éléments suivants :

   • clés primaires
   • hachages/sommes de contrôle
   • validation ligne par ligne en cas de non-concordance

4. Veridata identifie :

   • lignes manquantes
   • lignes supplémentaires
   • valeurs de colonne modifiées
   • transactions non synchronisées

5. Les travaux de comparaison peuvent s'exécuter de manière répétée ou continue pendant que la réplication reste active, ce qui permet une validation continue avec un impact minimal sur les systèmes de production.

Pour éviter de verrouiller des tables ou d'interrompre la réplication, Veridata utilise des techniques de comparaison optimisées telles que :

• comparaison basée sur le checksum
• traitement parallèle
• balayages de table partitionnés
• découpage par bloc de la plage de clés

Les organisations peuvent ainsi vérifier que les données répliquées restent synchronisées pendant :

• Migrations
• mises à niveau
• Coupures sans temps d'arrêt
• réplication active-active
• opérations de récupération après sinistre

Veridata lui-même ne réplique pas les données, il valide l'exactitude de la réplication GoldenGate en temps quasi réel.

Pour plus d'informations sur la comparaison de données en temps réel à l'aide d'Oracle GoldenGate Veridata, reportez-vous à Oracle GoldenGate Veridata 26c : Comment fonctionne-t-il ?

Comment dimensionner Oracle GoldenGate Veridata ?

Pour plus d'informations sur le dimensionnement d'Oracle GoldenGate Veridata, reportez-vous à Dimensionnement d'Oracle GoldenGate Veridata.

A quoi sert la base de données du référentiel Veridata ?

Toutes les informations sur les métadonnées (c'est-à-dire toutes les configurations de Veridata) seront stockées dans la base de données du référentiel Veridata.

Veridata 26c est fourni avec une base de données MySQL intégrée en tant que référentiel.

Toutefois, le client peut utiliser cette base de données MySQL intégrée ou sa propre base de données MySQL pour le référentiel.

Quelle serait la taille de la base de données du référentiel Veridata ?

Toutes les informations de métadonnées de Veridata seront stockées dans cette base de données de référentiel.

Donc, il ne serait pas d'une grande taille. Un maximum de 5 Go correspond à la taille du référentiel.

Oracle GoldenGate Veridata peut-il être utilisé pour comparer des données entre des bases de données hétérogènes ?

Oui. Oracle GoldenGate Veridata est une solution de comparaison et de réparation de données hétérogènes.

Vérifiez la matrice de certification suivante liée :

https://www.oracle.com/in/a/ocom/docs/ogg-veridata-23c-cert-matrix.xlsx

Pouvons-nous comparer les instructions LDD de la table à l'aide d'Oracle GoldenGate Veridata ?

Non, Oracle GoldenGate Veridata est un outil de comparaison de données qui ne peut comparer que des données entre des tables. Cependant, cela figure dans notre feuille de route.

Oracle GoldenGate Veridata peut-il surveiller la réplication de données entre les sources et les cibles en temps réel ?

Oui. Oracle GoldenGate Veridata peut surveiller et valider la réplication de données entre les bases de données source et cible en temps quasi réel. Il compare en permanence les données pendant l'exécution de la réplication GoldenGate et identifie les divergences telles que les lignes manquantes, les lignes supplémentaires ou les non-concordances de données.

Cela garantit que les bases de données répliquées restent synchronisées pendant les migrations, les mises à niveau et les opérations de réplication en cours, avec un impact minimal sur les systèmes de production.

Faut-il installer Veridata Server pour chaque base de données source et cible ?

Non, une seule installation de Veridata est suffisante pour comparer les données entre plusieurs sources et cibles.

Vous n'avez pas besoin d'installer des serveurs Veridata dédiés à chaque base de données source et cible.

Qu'est-ce que l'agent Veridata ? Comment doit-il être configuré ?

L'agent Veridata est un programme Java léger qui est chargé d'extraire les données des tables de base de données source et cible.

Vous devez configurer un agent dédié pour chaque base de données.

Par exemple, si vous disposez de 5 sources et cibles, vous devez configurer 5 agents Veridata pour 5 sources et 5 agents Veridata pour 5 cibles.

Où devons-nous installer et déployer les agents Veridata ?

Les agents Veridata peuvent être déployés natifs ou distants sur les serveurs de base de données. Lorsque vous configurez des agents Veridata à distance, vous devez vous assurer d'avoir un bon réseau entre les agents Veridata et les bases de données source/cible.

Où se trouve le fichier Propriétés de l'agent Veridata ?

Elle se trouve dans le chemin < AGENT_HOME > portant le nom "agent.properties".

Où se trouve le fichier de configuration du serveur Veridata ?

Le fichier de configuration du serveur Veridata se trouve dans le chemin suivant :

/config/veridata/veridata.cfg

Où se trouve le fichier oggvdt_cainput.properties ?

Le fichier oggvdt_cainput.properties se trouve dans le chemin suivant :

/config/oggvdt_cainput.properties

Où puis-je trouver les rapports Veridata ?

Les rapports Oracle GoldenGate Veridata sont généralement générés et stockés sur l'hôte Veridata Server sous le répertoire d'installation Veridata.

Les emplacements par défaut sont généralement les suivants :

• Linux ou UNIX :
  • <VERIDATA_HOME>/reports
  • <VERIDATA_HOME>/veridata/reports
• Windows : <VERIDATA_HOME>\reports

Vous pouvez également accéder aux états à partir de l'interface utilisateur Web de Veridata :

1. Connectez-vous à la console Veridata.
2. Ouvrez le travail de comparaison.
3. Accédez à Rapports ou Détails du travail → Rapports.
4. Téléchargez les sorties HTML, XML ou PDF, selon la configuration.

Les types de rapport courants sont les suivants :

• Rapports récapitulatifs de comparaison
• Rapports sur les lignes non synchronisées
• Rapports de réparation
• Rapports d'audit et de conformité

Si vous utilisez Veridata avec des microservices OGG ou des déploiements OCI, les rapports peuvent être écrits dans :

• un volume monté
• stockage partagé
• OCI Object Storage, selon la configuration du déploiement

Vous pouvez vérifier le chemin exact du rapport dans :

<VERIDATA_HOME>/cfg/veridata.cfg

ou les propriétés de démarrage/configuration du serveur.

Pouvons-nous avoir plusieurs agents Veridata pour une base de données ?

Oui, mais nous recommandons 1 agent pour 1 base de données.

Combien de paires de comparaison puis-je créer dans un groupe ?

Il n'y a aucune restriction sur le nombre de paires de comparaison qui peuvent être créées. Tout nombre est correct.

Combien de paires de comparaison puis-je exécuter en parallèle dans Veridata ?

La valeur par défaut maximale est 100.

Mais il peut être mis à jour à partir du fichier veridata.cfg en modifiant la valeur de maxconcurrentjobs.

Seules les données incrémentielles ou modifiées peuvent-elles être comparées quotidiennement dans Veridata ?

Oui, Veridata a une fonctionnalité appelée comparaison delta.

Une fois cette fonctionnalité activée, seules les données modifiées seront comparées.

Qu'est-ce que la comparaison Delta à Veridata ?

Les paires de comparaison peuvent être configurées pour utiliser le traitement delta, une fonctionnalité de performances qui compare uniquement les blocs de données qui ont été modifiés depuis la dernière exécution, au lieu d'analyser la table entière.

Cela empêche de comparer encore et encore toutes les données historiques et ne compare que les données modifiées.

Comment activer la comparaison Delta à Veridata ?

Dans Oracle GoldenGate Veridata 26c, la comparaison delta est plus alignée sur le modèle moderne de "validation continue des données" que sur les anciennes explications de traitement delta de style classique de la documentation héritée. La fonctionnalité est conçue pour réduire la surcharge de comparaison en se concentrant uniquement sur les données modifiées entre les cycles de comparaison, ce qui est particulièrement important pour la validation continue dans les environnements de réplication actif-actif, de cloud hybride et à grande échelle.

Dans Veridata 26c, la comparaison delta est activée via l'interface utilisateur Web Veridata modernisée lors de la configuration des paires de comparaison et des travaux. Au lieu de s'appuyer fortement sur des workflows de ligne de commande hérités, les administrateurs configurent le comportement de comparaison directement dans l'interface utilisateur ou via des API REST. Le traitement implique généralement l'activation de la validation basée sur des deltas dans la configuration de la paire de comparaison, de sorte que Veridata effectue le suivi des modifications entre les exécutions et limite les comparaisons futures aux jeux de données modifiés. Cela réduit l'impact sur la base de données et améliore les performances de comparaison pour les cas d'utilisation de validation continue.

L'architecture 26c met également l'accent sur :

• workflows de validation continue
• travaux planifiés
• Automatisation d'API REST
• opérations natives du cloud
• traitement de comparaison évolutif basé sur les microservices

au lieu d'anciens modèles d'exécution de comparaison autonomes.

En outre, Veridata 26c introduit la planification native et des fonctionnalités d'automatisation améliorées directement dans l'interface utilisateur et les API, ce qui rend Delta Comparison plus opérationnellement intégrée à la validation de l'état de la réplication en cours plutôt que d'être traitée comme une fonctionnalité d'optimisation manuelle.

Quelle est la version du module d'extension Oracle Enterprise Manager certifiée pour la surveillance des déploiements de microservices Oracle GoldenGate 26ai ?

La surveillance et le repérage des microservices Oracle GoldenGate 26ai dans Enterprise Manager 24ai sont certifiés avec le module d'extension EM Oracle GoldenGate version 13.5.2.0.6.

Pourquoi les niveaux de patches recommandés pour Oracle AI Database et GoldenGate sont-ils importants pour la stabilité et la prise en charge ?

Oracle recommande vivement d'exécuter Oracle GoldenGate avec les mises à jour de version (RU) Oracle Database et les packages de patches GoldenGate actuellement recommandés.

Les anciens niveaux de patch de base de données peuvent exposer les clients à :

• bogues de capture intégrés,
• LogMiner instabilité,
• combinaisons non prises en charge,
• vulnérabilités de sécurité,
• et les défauts de réplication sont déjà corrigés dans les nouvelles RU.

Pratique recommandée :

Suivez le dernier :

• GoldenGate notes de recommandation de patch,
• recommandations RU de base de données,
• et des matrices d'interopérabilité certifiées.

Validez les correctifs avant de supposer des défauts de produit sur des niveaux de correctifs plus anciens.

Remarque principale sur les ensembles de patches de produit de base Oracle GoldenGate (KB159960)

Oracle GoldenGate et OCI GoldenGate prennent-ils en charge la capture des données de modification à partir de MongoDB ?

Oracle GoldenGate et OCI GoldenGate prennent en charge la capture des données de modification à partir de MongoDB et de MongoDB Atlas. Il prend en charge la réplication bidirectionnelle entre différentes bases de données MongoDB.

Puis-je utiliser Oracle GoldenGate et OCI GoldenGate pour les migrations MongoDB vers Oracle AI Database ?

Oui, Oracle GoldenGate ne prend pas en charge les migrations de temps d'arrêt de MongoDB vers Oracle AI Database. Pour plus de détails, reportez-vous à la documentation Oracle GoldenGate.

Comment configurer les migrations Oracle GoldenGate pour migrer de MongoDB vers Oracle AI Database ?

Vérifiez que les prérequis suivants sont remplis.

• La version source de MongoDB est supérieure ou égale à 5.
• Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA) 23.7 ou version ultérieure est installé et configuré pour les instances de base de données source MongoDB et cible.
• Les outils de base de données MongoDB (y compris mongodump et mongorestore) sont installés et les chemins de répertoire respectifs sont ajoutés à la variable d'environnement de chemin.

Pour migrer MongoDB vers Oracle AI Database pour Oracle GoldenGate, procédez comme suit :

1. Exécutez l'utilitaire de vidage MongoDB. Exécutez la commande mongodump avec l'option --oplog pour créer un cliché de la base de données MongoDB source :

   $ ./bin/mongodump --uri="mongodb://localhost:27021" --oplog -v

2. Exécutez le script OplogLSN.sh pour extraire les horodatages de la première et de la dernière opération du fichier oplog.bson en indiquant le chemin d'accès au fichier oplog.bson comme argument, comme suit :

   $./oplogLSN.sh /path/to/dump/oplog.bson

   La sortie fournit les horodatages de la première et de la dernière opération (ou de la première opération noop si aucune opération n'a eu lieu au cours du processus de vidage).

   Sortie :

   2025-02-27T13:53:00.885+0000 1 objects found First LSN: 1740663867.1 Last LSN: 1740663946.211 3

3. Inspecter les entrées Oplog : s'il y avait des opérations entrantes pendant le vidage, le fichier oplog.bson contient des entrées pour ces opérations, chacune avec un horodatage. Vous pouvez utiliser OplogLSN.sh pour capturer les horodatages de la première et de la dernière opération ou le convertir en fichier JSON pour inspection manuelle, comme indiqué à l'étape précédente.

4. Exécutez l'utilitaire de restauration MongoDB : une fois que vous disposez des horodatages nécessaires, utilisez l'utilitaire mongorestore pour restaurer les collections sélectionnées à partir du vidage vers l'instance MongoDB cible :

   $ ./mongorestore --uri="mongodb://localhost:27021" --nsInclude=testDB.coll1 --nsInclude=testDB.coll2 /path/to/dump -v

5. Démarrer l'extraction CDC MongoDB : démarrez le processus d'extraction CDC MongoDB à partir de l'horodatage de la première opération (position LLSN) extrait du fichier oplog.bson. Cela garantit que l'extraction CDC commence à capturer les opérations qui se produisent après le démarrage du processus de vidage.

6. Configurez la réplication MongoDB avec le fichier trace CDC généré et définissez la propriété oplogReplayLastLsn sur l'horodatage de la dernière opération à partir du fichier oplog.bson. Ainsi, le processus Replicat s'exécute en mode oplog-replay, ce qui évite les collisions. Une fois le dernier horodatage traité, il continue en mode normal. Cette configuration garantit un lancement précis, sans perte de données ni duplication, et élimine le besoin d'un traitement coûteux des collisions dans le processus Replicat.

Comment exécuter les chargements initiaux de Snowflake vers Oracle AI Database ?

1. Créez une extraction de capture de données de modification (à partir de la source Oracle AI Database).

2. Obtenir le numéro SCN de la base de données source.

3. Créez une extraction de chargement initial (à partir de la source Oracle AI Database).

4. Créez un chemin de distribution pour l'extraction CDC.

5. Créez un chemin de distribution pour le chargement initial de l'extraction.

6. Créez une réplication pour le chargement initial (ciblage Snowflake).

7. Créez une réplication pour la réplication de capture des données de modification (ciblage de Snowflake).

Que dois-je faire pour corriger "Exception : net.snowflake.client.jdbc.SnowflakeReauthenticationRequest : Le jeton d'authentification a expiré. L'utilisateur doit s'authentifier à nouveau." erreur dans la réplication Snowflake d'Oracle GoldenGate ?

Cette erreur se produit lorsqu'il y a de longues périodes d'inactivité. Pour résoudre ce problème, vous pouvez définir le paramètre JDBC CLIENT_SESSION_KEEP_ALIVE afin de forcer l'utilisateur de base de données à se connecter après une période d'inactivité.

snowflakecomputing.com/?warehouse=<warehouse-name>&db=<database-name>&CLIENT_SESSION_KEEP_ALIVE=true

Oracle GoldenGate et OCI GoldenGate prennent-ils en charge la réplication DDL vers Snowflake ?

Oracle GoldenGate peut être configuré pour propager les modifications LDD source vers les tables Snowflake cible. L'évolution automatique des schémas permet de détecter, de gérer et d'appliquer des modifications à un schéma de base de données, telles que des tables, des colonnes, des index ou des relations, sans intervention manuelle. L'évolution automatique des schémas prend en charge la détection des nouveaux objets et des modifications de métadonnées, puis la génération automatique de DDL cible pour l'évolution des schémas.

Pour le chargement initial, il peut créer ou remplacer des tables cible.

Pour le processus Replicat CDC, il peut créer ou modifier des tables cible lors de l'application en cours. Pour plus d'informations, reportez-vous à la documentation Oracle GoldenGate.

Puis-je utiliser Oracle GoldenGate et OCI GoldenGate pour la réplication Apache Iceberg ?

Oui. Oracle GoldenGate prend en charge la réplication de données en temps réel dans Apache Iceberg. Oracle GoldenGate utilise l'API Java Apache Iceberg pour ouvrir Apache Iceberg Lakehouses. Oracle GoldenGate prend en charge les catalogues Oracle AI Data Catalog, Amazon Glue, Polaris, Nesti, Hadoop et REST.

Puis-je utiliser Oracle GoldenGate et OCI GoldenGate pour la réplication des données en temps réel vers les tables Apache Iceberg sur OCI Object Storage ?

Oui. Oracle GoldenGate et OCI GoldenGate peuvent être configurés pour la réplication de données en temps réel vers les tables Apache Iceberg stockées sur OCI Object Storage via l'adresse d'API OCI Object Storage S3. Pour plus de détails, reportez-vous à Création d'un lakehouse Apache Iceberg en temps réel sur OCI Object Storage avec OCI GoldenGate.

La réplication Oracle GoldenGate et OCI GoldenGate Apache Iceberg prend-elle en charge la fusion en écriture ?

Oui, Oracle GoldenGate et OCI GoldenGate prennent en charge la fusion lors de l'écriture pour les tables Iceberg gérées par Snowflake, Google BigQuery et Databricks. Sur ces plates-formes, GoldenGate utilise les ressources de calcul de la plate-forme cible pour le compactage.

Comment Oracle GoldenGate et OCI GoldenGate peuvent-ils gérer les mises à jour de clé primaire dans les tables de parquet sur OCI Object Storage ?

Oracle GoldenGate et OCI GoldenGate gèrent les mises à jour de clé primaire en trois modes. Ce comportement est contrôlé par l'ajout de gg.handler.name.format.pkUpdateHandling au fichier de propriétés de réplication. Les valeurs prises en charge incluent Abend, Update et delete-insert. Abend est le comportement par défaut. Le processus Replicat échoue lorsqu'une mise à jour de clé primaire est détectée et consigne l'erreur dans le fichier de rapport. Update traite la mise à jour de la clé primaire comme toute autre opération de mise à jour. Utilisez ce paramètre uniquement si vous pouvez garantir que la clé primaire n'est pas utilisée comme critère de sélection.

Delete-insert réplique la mise à jour de la clé primaire en deux enregistrements : un avec l'image avant, marquée comme suppression, et un avec l'image après, marquée comme insertion.

Pour utiliser delete-insert, le processus Extract doit capturer les enregistrements de données de modification non compressés, ce qui signifie que toutes les colonnes sont écrites dans le fichier trace.

Pour générer des enregistrements non compressés, utilisez LOGALLSUPCOLS pour les sources Oracle AI Database et COMPRESSUPDATES | NOCOMPRESSUPDATES pour les bases de données non Oracle.

Par exemple, lors de la réplication vers OCI Object Storage, définissez gg.handler.<gg.target value>.format.pkUpdateHandling=delete-insert pour répliquer les mises à jour de clé primaire sous la forme d'un enregistrement de suppression avec l'image avant et d'un enregistrement d'insertion avec l'image après.

Comment répliquer les colonnes Oracle DATE et TIMESTAMP dans des tables de parquet stockées sur OCI Object Storage avec Oracle GoldenGate ?

Les colonnes Oracle DATE et TIMESTAMP sont répliquées en tant que chaînes par défaut lorsqu'aucune mise en correspondance explicite n'est configurée. Sans mapping approprié, les moteurs en aval ne reconnaîtront pas ces colonnes en tant que types date/time, rendant impossible l'arithmétique des dates, le filtrage des plages et le partitionnement basé sur le temps sans conversion explicite. La propriété enableTimestampLogicalType permet de mettre en correspondance les colonnes Oracle DATE et TIMESTAMP avec le type logique Avro timestamp-micros, qui représente les valeurs en microsecondes depuis l'époque, la représentation correcte pour les charges globales analytiques et de lac de données.

Dans la réplication Oracle GoldenGate Cloud Object Storage, les types source DATE et TIMESTAMP sont mis en correspondance par défaut avec les fichiers Avro (parquet, iceberg et delta compris) en tant que STRING.

Pour répliquer les types source DATE et TIMESTAMP en tant que type logique timestamp-micros vers les fichiers Avro (y compris Parquet, Iceberg et Delta), définissez gg.handler.<gg.target value>.format.enableTimestampLogicalType sur true.

Lorsque le type logique d'horodatage est activé, gg.format.timestamp est également requis. Par exemple : gg.handler.oci.format.enableTimestampLogicalType= truegg.format.timestamp=yyyy-MM-dd HH:mm:ss.SSSSSS

Comment améliorer les performances de réplication Oracle GoldenGate OCI Object Storage ?

Les performances de la réplication Oracle GoldenGate Cloud Object Storage peuvent être réglées à l'aide de deux fonctionnalités clés : le type de réplication et le paramètre GROUPTRANSOPS. Outre le type de réplication et le regroupement de transactions, la taille des fichiers générés par le processus affecte directement le débit et doit être réglée en même temps que les autres paramètres. Oracle GoldenGate Distributed Applications and Analytics offre deux modes de réplication différents : la réplication classique et la réplication coordonnée.

La réplication classique est un processus monothread qui applique les messages aux services de stockage cloud cible. Le processus Replicat coordonné est un processus multithread dans lequel plusieurs threads lisent le fichier trace OGG indépendamment et appliquent les transactions en parallèle. Le processus de réplication Oracle GoldenGate Cloud Object Storage optimise le traitement avec le regroupement des transactions. Le paramètre GROUPTRANSOPS regroupe plusieurs petites transactions en une seule transaction plus importante appliquée aux cibles de stockage cloud. GROUPTRANSOPS est configuré dans le fichier de paramètres. Par défaut, GROUPTRANSOPS est défini sur 1000. Vous pouvez augmenter jusqu'en 20000 pour de meilleures performances.

Par exemple : GROUPTRANSOPS 20000

Comment définir la taille de fichier dans la réplication Google Cloud Storage d'Oracle GoldenGate et d'OCI GoldenGate ?

Le processus de réplication Oracle GoldenGate crée un fichier dans le système de fichiers local et le conserve ouvert jusqu'à ce qu'une condition de report soit remplie ou déclenchée par un événement de modification de métadonnées à partir de la source (comme une modification LDD). Les utilisateurs peuvent contrôler la reconduction des fichiers à l'aide des propriétés de réplication. La taille maximale des fichiers contrôle les tailles des fichiers. Par défaut, la taille des fichiers est configurée sur 1 Go, mais elle peut être configurée si nécessaire. Lorsque la taille maximale est atteinte, le fichier est fermé et un nouveau fichier est généré. Pour plus d'informations, reportez-vous à la section Configuration du gestionnaire File Writer dans la documentation Oracle GoldenGate pour DAA.

Oracle GoldenGate et OCI GoldenGate prennent-ils en charge le partitionnement avec la réplication de fichier parquet vers Google Cloud Storage ?

Oracle GoldenGate et OCI GoldenGate prennent en charge la création de fichiers partitionnés dans des buckets de stockage d'objet cible. Le partitionnement améliore les performances d'élagage et de requête en aval, mais le sur-partitionnement augmente le nombre de répertoires/fichiers et amplifie le problème des petits fichiers.

Pour utiliser le partitionnement, les données doivent être partitionnées par la table au niveau le plus élevé. Pour ce faire, utilisez la propriété pathMappingTemplate. Elle doit être définie sur le nom de table qualifié complet.

Il créera des répertoires dans le conteneur/bucket en fonction du nom de table source qualifié complet. Par exemple : gg.eventhandler.<gg.target value>.pathMappingTemplate=${fullyQualifiedTableName}

Pour créer des partitions, gg.handler.<gg.target value>.partitioner.<fully_qualified_table_name> est utilisé. Cette propriété peut être utilisée avec un mot-clé de modèle tel que ${columnValue[column_name]} ou des valeurs de chaîne constante pour définir la structure de chemin de partition.

Oracle GoldenGate et OCI GoldenGate prennent-ils en charge la réplication LDD vers des fichiers parquet sur Azure Data Lake Storage (ADLS) ?

La réplication ADLS Oracle GoldenGate et OCI GoldenGate propage automatiquement les modifications LDD source vers les fichiers générés. Vous pouvez également utiliser EVENTACTIONS pour contrôler le comportement d'extraction/de réplication en cas d'opération LDD dans la base de données source.

Si l'extraction Oracle GoldenGate capture un événement Créer une table à partir de la base de données source, le processus de réplication crée un fichier avec le nom de la table à partir de l'événement Créer une table dans le bucket/conteneur de stockage d'objet cloud cible.

Si l'extraction Oracle GoldenGate capture un événement Modifier la colonne/Supprimer la colonne à partir de la base de données source, le processus Replicat crée un nouveau fichier reflétant la définition de table source mise à jour.

Si l'extraction d'Oracle GoldenGate capture un événement Truncate à partir de la base de données source, vous pouvez configurer le processus Replicat pour que le fichier de données soit déplacé sur l'événement Truncate en définissant les paramètres suivants :

gg.eventhandler.<gg.target value>.rollOnTruncate=true

Cette propriété est définie sur False par défaut et le processus Replicat n'exécute pas le fichier dans l'événement Truncate. L'extraction Oracle GoldenGate capture un événement de suppression de table à partir de la base de données source, ce qui n'a aucun impact sur le système de fichiers cible.

Comment Oracle GoldenGate et OCI GoldenGate gèrent-ils le type de données source Oracle NUMBER lors de la réplication vers des fichiers parquet sur Azure Data Lake Storage (ADLS) ?

Oracle NUMBER est un type de données décimales de précision variable qui peut représenter des entiers et des valeurs décimales à virgule fixe avec une précision maximale de 38 chiffres.

Si une colonne est définie sans précision et échelle explicites (par exemple, NUMBER), Oracle peut stocker des valeurs avec une échelle variable d'une ligne à l'autre, et dans certains scénarios de réplication/génération de schéma, le formateur peut ne pas être en mesure de dériver de manière déterministe une seule précision/échelle pour le schéma cible. Par conséquent, les mappings avec Avro/Parquet utilisent souvent une représentation décimale conservatrice, sauf si vous configurez explicitement la précision et l'échelle pour qu'elles correspondent aux définitions de colonne source.

gg.handler.<gg.target value>.enableDecimalLogicalType est le commutateur maître pour le mapping de type logique décimal. Lorsque la valeur est définie sur True, le formateur Avro demande de mettre en correspondance les colonnes Oracle NUMBER avec le type logique décimal Avro (octets avec logicalType : decimal) au lieu du mapping par défaut qui écrit les nombres en tant que primitives ou chaînes numériques Avro simples.

Lorsque la précision/l'échelle ne peut pas être déduite de manière déterministe, le formateur choisit généralement une définition décimale Avro conservatrice (haute précision et échelle) pour éviter la perte de précision. Cela peut amener les consommateurs en aval à voir des valeurs exprimées à une échelle inutilement grande (par exemple, des chiffres fractionnaires de fin apparents).

Pour aligner le schéma cible sur des définitions de source connues et cohérentes, en particulier pour les données financières (soldes, prix, montants) :

set gg.handler.<gg.target value>.maxPrecision et gg.handler.<gg.target value>.oracleNumberScale.

Quelles sont les méthodes d'authentification ADLS prises en charge par Oracle GoldenGate et OCI GoldenGate ?

Oracle GoldenGate et OCI GoldenGate prennent en charge les clés d'accès, la signature d'accès partagé et l'ID Azure Entra.

Oracle GoldenGate prend en charge les tables Amazon S3 ?

Oui. Oracle GoldenGate prend en charge la réplication Iceberg Apache en temps réel vers des tables Amazon S3 via des catalogues REST de table Amazon S3.

Oracle GoldenGate et OCI GoldenGate prennent-ils en charge les téléchargements multipart vers Amazon S3 ?

Oui, l'activation de la fonctionnalité de téléchargement multipart d'Amazon S3 permet de télécharger les fichiers volumineux vers Amazon S3 en les divisant en petites parties qui peuvent être téléchargées indépendamment et en parallèle. Cette fonctionnalité résout les limitations déjà connues d'Amazon S3, telles que le téléchargement unique d'objets de taille supérieure à 5 Go. Une fois que toutes les parties du fichier ont été téléchargées, une demande est adressée à Amazon S3 pour les assembler en un seul objet. Pour utiliser cette fonctionnalité, vous devez activer gg.eventhandler.s3.multipartEnabled=true dans la réplication Amazon S3.

Oracle GoldenGate et OCI GoldenGate prennent-ils en charge le partitionnement avec la réplication de fichier parquet vers Google Cloud Storage ?

Oracle GoldenGate et OCI GoldenGate prennent en charge la création de fichiers partitionnés dans des buckets de stockage d'objet cible. Le partitionnement améliore les performances d'élagage et de requête en aval, mais le sur-partitionnement augmente le nombre de répertoires/fichiers et amplifie le problème des petits fichiers.

Pour utiliser le partitionnement, les données doivent être partitionnées par la table au niveau le plus élevé. Pour ce faire, utilisez la propriété pathMappingTemplate. Elle doit être définie sur le nom de table qualifié complet. Il créera des répertoires dans le conteneur/bucket en fonction du nom de table source qualifié complet. Par exemple : gg.eventhandler.<gg.target value>.pathMappingTemplate=${fullyQualifiedTableName}. Pour créer des partitions, gg.handler.<gg.target value>.partitioner.<fully_qualified_table_name> est utilisé.

Cette propriété peut être utilisée avec un mot-clé de modèle tel que ${columnValue[column_name]} ou des valeurs de chaîne constante pour définir la structure de chemin de partition.

Comment fonctionne la tarification d'OCI Database Migration Service ? (Factuel)

Les 183 premiers jours (6 mois) d'une migration sont fournis gratuitement, sauf dans les cas où la migration dure plus de 60 jours sans transfert de données.

Quelles sont les sources et les cibles prises en charge par OCI Database Migration Service ? (Factuel)

Actuellement, les migrations homogènes Oracle et MySQL sont prises en charge. Les sources peuvent être sur site, sur d'autres clouds ou dans OCI. Les cibles doivent se trouver dans OCI. Oracle est pris en charge à partir des versions 11g (11.2.0.4), 12c (12.1.0.2,12.2.0.1),19c,21c et toutes les versions ultérieures d'Oracle Database. MySQL : versions 5.7 et 8. Vous trouverez plus de détails dans l'URL suivante.

Quels sont les types de migration pris en charge par OCI Database Migration Service ?

Migration logique hors ligne : copie unique de la base de données, les applications doivent être hors ligne pendant le processus de migration. Migration logique en ligne : copie initiale de la base de données suivie de la capture des données de modification lors de la migration. Les applications peuvent rester en ligne pendant le processus de migration.

Lors d'une migration oracle, quels objets et schémas sont exclus par défaut ?

Les types d'objet suivants sont toujours exclus :

• Administrateurs GoldenGate identifiés dans DBA_GOLDENGATE_PRIVILEGES, y compris des utilisateurs ggadmin et c##ggadmin.
• Si la cible est une Infrastructure partagée Autonomous Data Warehouse : CLUSTER, DB_LINK, INDEXTYPE, STATISTICS.
• Si la cible est une infrastructure dédiée d'Autonomous Data Warehouse, une infrastructure partagée ou dédiée Autonomous Transaction Processing : CLUSTER, DB_LINK, STATISTICS
• Toutes les autres cibles : STATISTICS

Les schémas suivants sont exclus par défaut :

• Schéma marqué comme ORACLE_MAINTAINED dans SYS.DBA_USERS sur la base de donnée source ou cible
• Schéma marqué comme exclu de l'export dans SYS.KU_NOEXP_VIEW sur la base de données source
• Schéma GGADMIN et C##GGADMIN

Quelles sont les ressources OCI requises pour une migration ?

• Coffre et clé permettant de stocker les clés secrètes de connexion.
• Selon le support de transfert sélectionné Object Storage ou le système de fichiers
• Connexion par source et cible. Certains scénarios peuvent nécessiter plusieurs connexions par source.
• Une évaluation pour préparer la migration.
• L'évaluation s'occupe de la création de la migration
• Pour les migrations en ligne, un déploiement OCI GoldenGate est requis, mais il est entièrement géré par le service.
• Une cible OCI

Où OCI GoldenGate est-il disponible ?

• Oracle Cloud : OCI GoldenGate est disponible dans toutes les régions cloud publiques, gouvernementales et dédiées d'OCI. Pour plus d'informations, reportez-vous à https://www.oracle.com/cloud/distributed-cloud/service-availability/.
• Azure : OCI GoldenGate est disponible sur Azure sur Oracle AI Database@Azure. Pour plus d'informations, reportez-vous à https://docs.oracle.com/en-us/iaas/Content/database-at-azure/oaa_regions.htm.
• Google Cloud : OCI GoldenGate est disponible sur Google Cloud sur Oracle AI Database@Google Cloud. Pour plus d'informations, reportez-vous à https://docs.oracle.com/en-us/iaas/Content/database-at-gcp/get-started-regions.htm.