Domande frequenti su Oracle GoldenGate

Ottieni risposte alle domande più frequenti sull'implementazione di Oracle GoldenGate AI.

Perché Oracle GoldenGate è importante per l'AI aziendale?

Oracle GoldenGate è importante per l'AI aziendale perché l'AI dipende dai dati aziendali attuali e affidabili. I modelli, i sistemi RAG e gli agenti AI non possono ragionare o agire in modo affidabile quando si lavora da snapshot batch non più validi o da copie incomplete di dati operativi. GoldenGate trasmette gli eventi aziendali man mano che si verificano, offrendo AI sistemi AI l'accesso a una nuova realtà operativa, preservando al contempo governance, coerenza e verificabilità.

In che modo Oracle GoldenGate supporta gli agenti RAG e AI?

Oracle GoldenGate supporta gli agenti RAG e AI fornendo continuamente dati operativi in database vettoriali, pipeline RAG, knowledge base AI, lakehouse e sistemi basati sugli eventi. Utilizzando le funzionalità AI di GoldenGate, i record modificati possono essere arricchiti, incorporati, riepilogati, classificati o instradati come parte della pipeline, in modo che i sistemi AI operino sul contesto aziendale corrente anziché su snapshot non più validi.

Come supporta GoldenGate i dati vettoriali?

Può replicare i vettori esistenti, spostare i vettori in Oracle AI Database, eseguire lo streaming delle modifiche vettoriali e generare integrazioni durante la replica.

Quando dovrei usare @AISERVICE?

Utilizzare @AISERVICE quando l'incorporamento o l'arricchimento devono essere eseguiti in un servizio AI esterno, ad esempio un endpoint gestito o supportato dalla GPU. Vedere Integrazione dell'AI esterna con @AISERVICE

Quando dovrei usare @DBFUNCTION?

Utilizzare @DBFUNCTION quando la logica di incorporamento deve essere eseguita nel database di destinazione nell'ambito dell'elaborazione dell'applicazione. Vedere Integrazione del database nativo con @DBFUNCTION

Come devono essere gestiti i carichi vettoriali storici?

Utilizzare la creazione di istanze di massa o il caricamento nativo del database per i dati cronologici, quindi consentire a GoldenGate di elaborare le modifiche incrementali.

Quali sono i principali casi d'uso per Oracle GoldenGate?

Oracle GoldenGate viene utilizzato per l'alta disponibilità e il disaster recovery mission-critical, le migrazioni senza tempi di inattività, gli analytics in tempo reale, l'ingestione del lakehouse, le architetture basate sugli eventi, le pipeline AI e RAG, le architetture di data fabric e la sincronizzazione dei dati governata in ambienti ibridi e multicloud.

Oracle GoldenGate supporta la migrazione del database Oracle E-Business Suite (EBS) e le informazioni sulla certificazione Oracle per EBS sono ancora valide?

Oracle EBS non certifica alcun prodotto di replica logica per le migrazioni, ma si concentra sui metodi di database tradizionali (importazione/esportazione, Oracle Data Pump).

Sebbene GoldenGate possa essere utilizzato per sostituire parte del lavoro svolto da questi metodi di database tradizionali per ridurre i tempi di inattività complessivi associati a una migrazione, non deve essere utilizzato su tutti gli oggetti.

Gli oggetti non supportati da GoldenGate o correlati al lavoro temporaneo devono essere migrati utilizzando i metodi tradizionali durante una finestra di inattività.

L'architettura di riferimento AWS per GoldenGate con EFS supporta scenari DR tra più aree?

Consulta il blog AWS High Availability for Oracle GoldenGate Microservices Architecture in AWS, che descrive una progettazione ad alta disponibilità nell'area.

In tale contesto, procedere come segue.

• Le caratteristiche di replica EFS sono quasi in tempo reale all'interno di un'area e
• L'architettura è progettata per scenari di failover locali

Per gli scenari DR tra più aree, il comportamento è notevolmente diverso:

• La replica EFS è asincrona (con RPO superiore, ad esempio minuti) , e questo può portare alla mancanza di file di trail dopo il failover
• La promozione del database in tutte le aree può introdurre RESETLOGS / nuovi limiti di incarnazione

A causa di questi fattori, i modelli di progettazione in-region delineati nel blog AWS non si estendono direttamente al DR cross-region senza ulteriori considerazioni.

Suggerimento:

Per le architetture tra più aree, utilizzare lo spostamento attivo dei dati (ad esempio, il percorso di distribuzione GoldenGate) anziché fare affidamento sullo storage condiviso replicato in modo asincrono per i file trail.

Quali sono le versioni supportate di Oracle Database GoldenGate?

• GoldenGate 19c e 21c supportano i database Oracle da 11.2.0.4 a 21c
• GoldenGate 26ai supporta i database Oracle da 19c a 26ai+

Per ulteriori informazioni, vedere https://www.oracle.com/integration/goldengate/certifications/.

Quali sono i diversi tipi di configurazioni e casi d'uso GoldenGate?

• Unidirezionale: i dati passano da un'origine all'altra.
• Bidirezionale: i dati fluiscono in entrambi i modi tra origine e destinazione.
• Multidirezionale: flussi di dati tra più origini e destinazioni.
• Data warehousing in tempo reale: Mantieni il tuo data warehouse aggiornato con i dati transazionali attivi.
• Disaster recovery: mantenere una copia sincronizzata del database a scopo di failover.
• Migrazioni senza tempi di inattività: sposta i database su nuove piattaforme o versioni con interruzioni minime.
• Integrazione delle applicazioni: condivisione dei dati tra diverse applicazioni in tempo reale.
• Cascata: invece della replica diretta da origine a destinazione, le modifiche vengono prima replicate in un'istanza GoldenGate intermedia (o più istanze), che quindi propaga le modifiche a valle.
• Distribuzione: denominata topologia uno-a-molti, è un pattern di architettura e progettazione utilizzato per spostare i dati su più database, ambienti cloud e code di messaggi in tempo reale.
• Consolidamento: consente alle aziende di centralizzare i dati provenienti da più fonti in un unico repository, noto anche come ODS (Operation Data Store), un database integrato in tempo reale che consolida i dati provenienti da più sistemi transazionali per supportare il reporting operativo e il processo decisionale.
• Streaming dei messaggi in tempo reale: GoldenGate consente agli utenti di pubblicare messaggi in OCI Streaming, Apache Kafka, Confluent e altre piattaforme di streaming di messaggi basate su Kafka certificate GoldenGate.
• Data lake in tempo reale: replica in tempo reale ai servizi di storage cloud (OCI Object Storage, ADLS, Amazon S3, Google Cloud Storage) in vari formati, tra cui JSON, ORC, Parquet e altro ancora.
• Migrazioni MongoDB senza tempi di inattività: GoldenGate supporta migrazioni senza tempi di inattività da MongoDB a Oracle AI Database che consentono ai clienti di eseguire le proprie migrazioni senza interruzioni aziendali.
• Cloud Warehouse Ingestions: GoldenGate consente agli utenti di inviare grandi quantità di dati a servizi di data warehouse e lake house cloud nativi come Autonomous Database, Snowflake, Databricks e altro ancora.
• Flussi di dati con standard AsyncAPI: GoldenGate consente agli sviluppatori di sottoscrivere facilmente i flussi di dati GoldenGate per integrare direttamente le loro applicazioni con GoldenGate ricevendo JSON formattato nelle loro applicazioni.

Quali sono i componenti chiave di GoldenGate?

• File trail: i file che hanno acquisito le modifiche vengono memorizzati.
• Estrai: acquisisce le modifiche dai redo log/transaction log del database di origine e le scrive nel file trail.
• Percorso di distribuzione: consente di leggere dal file trail e ulteriori processi al sistema di destinazione in cui Replicat legge e si applica al database o alla destinazione BigData.
• Replicat: applica le modifiche acquisite al database di destinazione.

Che cos'è Oracle GoldenGate e quali sono i suoi casi d'uso principali?

Oracle GoldenGate è una soluzione di integrazione e replica dei dati che acquisisce, trasforma e offre modifiche transazionali su più sistemi eterogenei in tempo reale.

Di seguito sono riportati i casi d'uso principali per Oracle GoldenGate.

• Migrazioni di database senza tempi di inattività e scenari di rollback
• Analisi e reporting in tempo reale
• Disaster recovery e alta disponibilità
• Aree/data center master multipli attivi/attivi
• Integrazione dei dati tra piattaforme on-premise e cloud
• Streaming dei messaggi in tempo reale
• Lakehouse in tempo reale
• Migrazioni MongoDB senza tempi di inattività
• Inclusioni warehouse cloud
• Flussi di dati con standard AsyncAPI

Quali database e piattaforme supporta Oracle GoldenGate?

Oracle GoldenGate supporta un'ampia gamma di database e destinazioni, tra cui:

• Oracle AI Database
• MySQL
• PostgreSQL
• SQL Server
• Db2 LUW, Db2 z/OS, Db2 per i
• Amazon RDS, Aurora, Google GCP, database Azure
• Piattaforme di Big Data come Kafka e Hadoop
• Snowflake
• Apache Iceberg
• Vari formati come JSON, Parquet, Avro, Delimited Text, ecc.
• NoSQL archivi di dati come MongoDB, Cassandra, ecc.
• Piattaforme di streaming di messaggi come Apache Kafka, Azure Event Hubs, Confluent, ecc.

Oracle GoldenGate può acquisire dalle applicazioni SaaS Oracle Fusion e SaaS OTM in esecuzione in OCI.

Oracle GoldenGate non può essere acquisito da Salesforce.com/SFDC.

Oracle GoldenGate può replicare le modifiche in Teradata e TimesTen, ma non può essere acquisito da nessuno dei due.

Si consiglia di esaminare le metriche di certificazione GoldenGate per il supporto di database e target specifici. Per ulteriori informazioni, vedere https://www.oracle.com/integration/goldengate/certifications/.

Quali sono le differenze tra l'architettura Oracle GoldenGate Classic e l'architettura dei microservizi?

• Architettura classica: modello più vecchio e monolitico con GGSCI per l'amministrazione. De-supportato in 26ai.
• Architettura dei microservizi (MA): design modulare moderno basato su REST con singoli servizi (ad esempio, Service Manager, Admin Service). MA offre una migliore scalabilità, sicurezza e facilità d'uso.

Per ulteriori informazioni su MA, vedere Architettura dei microservizi Oracle GoldenGate.

Qual è il confronto tra Oracle GoldenGate e altri strumenti di replica?

Oracle GoldenGate è la soluzione ideale per l'integrazione dei dati, la replica del database, lo spostamento dei dati, le migrazioni dei database e l'inclusione dei dati in tempo reale per i motivi riportati di seguito.

• Supporta testo in grassetto centinaia di origini e destinazioni (https://www.oracle.com/integration/goldengate/certifications/)

• Ha una comunità di supporto incredibile su molti canali diversi, tra cui
  • 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 è considerato il gold standard per la replica del database. Tutti i concorrenti si sforzano di essere più simili a GoldenGate e supportano le numerose funzionalità che supporta.

• GoldenGate ha molti vantaggi unici, tra cui la possibilità di creare sottoscrizioni ai suoi file trail. Vedere Informazioni sui flussi di dati, Replica attiva-attiva e Analytics di streaming per i dettagli su un servizio completamente gestito in OCI GoldenGate disponibile nei hyperscaler OCI, Google Cloud e Azure.

• GoldenGate è fondamentale tanto quanto i database che replica e ci sono numerose topologie che possono essere utilizzate per fornire disaster recovery e alta disponibilità per GoldenGate stesso, inclusa l'automazione completa con soluzioni di disaster recovery del database. https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/maa-platinum-and-oracle-goldengate-best-practices.html

• Ulteriori motivi per cui GoldenGate è il migliore sono disponibili qui: https://www.oracle.com/a/ocom/docs/techpaper-goldengate-advantages.pdf.

Quali sono i prerequisiti per l'installazione di Oracle GoldenGate sul database XYZ?

Piattaforma e compatibilità

• Versione microservizi GoldenGate supportata
• Versioni del database supportate (origine e destinazione)
• Sistema operativo supportato (consigliato per Linux)
• Sistema operativo e database a 64 bit

Modello di distribuzione

• Tipo di distribuzione definito (a nodo singolo o a più nodi)
• Destinazione di distribuzione (VM, Bare Metal o Kubernetes)
• Tutti i componenti di microservizi pianificati (amministrazione, distribuzione, ricevitore e così via)

Configurazione database

• Database in modalità ARCHIVELOG/registrazione delle transazioni
• Log supplementare abilitata
• Utente del database GoldenGate con privilegi richiesti
• Mantenimento del redo log/registro delle transazioni adeguato
• Chiavi primarie o identificativi univoci nelle tabelle

Infrastruttura e risorse di sistema

• CPU e memoria sufficienti per Extract, Replicat e servizi
• Spazio su disco sufficiente per file trail, checkpoint e log
• Prestazioni di I/O elevate per lo storage dei file trail

Storage

• File system dedicato per distribuzione, trail e log
• Storage condiviso se è richiesta l'HA (ad esempio, ACFS o cloud filestore)
• Strategia per il cleanup e la conservazione dei file trail

Rete e porte

• Connettività di rete affidabile tra sistemi
• Porte richieste aperte per server di amministrazione, distribuzione e ricevente
• Risoluzione corretta del nome host (file DNS o hosts)
• Bassa latenza per la replica in tempo reale

Impostazione sistema operativo e utente

• Utente del sistema operativo dedicato (ad es. ogg)
• Correggere le autorizzazioni per tutte le directory
• Variabili di ambiente obbligatorie configurate
• Limiti del sistema operativo configurati (ulimiti per file/processi)

Connettività al database

• Stringhe di connessione/TNS/endpoint configurati
• Test della connettività riuscito

Requisiti specifici per microservizi

• Distribuzione gestita tramite Service Manager
• Area di memorizzazione delle credenziali configurata
• Configurazione HTTPS (consigliata)
• Proxy inverso o load balancer facoltativo
• Accesso browser per interfaccia utente amministrazione

Sicurezza

• Storage delle credenziali sicuro
• Configurazione TLS/SSL (se necessario)
• Regole del firewall allineate con le porte di servizio
• Accesso basato su ruolo per l'amministrazione

High Availability (facoltativo)

• Progettazione della distribuzione multi-nodo
• Configurazione condivisa o replicata
• Load balancer per i servizi
• Strategia di failover definita

Disponibilità operativa

• Sincronizzazione dell'ora (NTP)
• Impostazione del monitoraggio e degli avvisi
• Approccio alla gestione dei log
• Backup prima di abilitare la replica
• Pianificazione della capacità per il carico di lavoro

Per ulteriori informazioni sulla preparazione dei database per Oracle GoldenGate, vedere Prepara database.

Quali sono le differenze tra implementazioni sicure e non sicure?

• Distribuzione sicura: utilizza TLS/SSL per la comunicazione cifrata, OAuth per l'autenticazione e garantisce la sicurezza end-to-end. Per ulteriori informazioni sulle distribuzioni sicure, vedere Distribuzioni sicure.
• Distribuzione non sicura: si basa sulla comunicazione HTTP/non cifrata in chiaro. Consigliato solo per ambienti interni/di test.

Come faccio a configurare i microservizi Oracle GoldenGate utilizzando OGGCA?

• Eseguire oggca.sh (Linux) o oggca.bat (Windows).
• Configurare Service Manager e distribuzione, specificando porte, percorsi e certificati, se necessario.
• oggca.sh può essere eseguito anche in modalità silenziosa fornendo un file di risposta.

Per ulteriori informazioni, vedere Aggiungere una distribuzione e Aggiungere una distribuzione in modalità silenziosa utilizzando OGGCA.

Quali sono le best practice per ottimizzare le prestazioni di Oracle GoldenGate?

Per le distribuzioni Oracle GoldenGate moderne, l'approccio consigliato consiste nell'utilizzare Integrated Extract insieme a Parallel Replicat, poiché Parallel Replicat è ora il metodo di replica strategico e preferito per le operazioni di applicazione delle destinazioni ad alte prestazioni.

Integrated Replicat viene dismesso a favore di Parallel Replicat perché Parallel Replicat offre una migliore scalabilità, prestazioni di applicazione delle transazioni migliorate e un'elaborazione parallela più efficiente per carichi di lavoro aziendali ad alto volume.

Un'architettura GoldenGate ben ottimizzata dovrebbe separare le fasi di acquisizione, trasporto e applicazione utilizzando file trail locali e remoti, il che migliora la resilienza e isola la replica dalle interruzioni di rete. Le prestazioni dipendono anche molto dall'infrastruttura di base, tra cui storage rapido, memoria del database di dimensioni adeguate, configurazione efficiente dei redo log e connettività di rete stabile.

Il monitoraggio continuo del ritardo Extract, del ritardo Replicat, del throughput e dell'attività dei checkpoint è essenziale per identificare in modo proattivo i colli di bottiglia prima che abbiano un impatto sulla latenza di replica.

In generale, le migliori prestazioni GoldenGate vengono ottenute attraverso una combinazione di progettazione scalabile dell'architettura, distribuzione appropriata del carico di lavoro, ottimizzazione del database e parallelismo gestito con cura, consentendo alle organizzazioni di mantenere bassa latenza e replica affidabile anche sotto carichi di lavoro transazionali di grandi dimensioni.

Come monitorare i ritardi e risolvere i problemi relativi alle prestazioni?

• Utilizzare il servizio Metriche prestazioni in MA.
• Utilizza comandi di ritardo e stato nel client di amministrazione e nell'API REST
• Controllare i colli di bottiglia come la latenza di rete o l'I/O su disco.
• Abilita tabella heartbeat
• Plugin OEM utente GoldenGate
• Esporta metriche con StatsD
• Visualizza lo stato corrente in WebUI

Quali strumenti o comandi posso utilizzare per monitorare i processi di Oracle GoldenGate?

Nell'architettura dei microservizi Oracle GoldenGate, il monitoraggio viene eseguito principalmente tramite il servizio di amministrazione basato sul Web, le API REST e il servizio Metriche delle prestazioni anziché gli strumenti di architettura classici tradizionali come GGSCI. Il servizio di amministrazione fornisce dashboard centralizzati che consentono agli amministratori di monitorare in tempo reale lo stato dei processi Extract, Distribution, Receiver e Parallel Replicat. Attraverso l'interfaccia Web, gli utenti possono tenere traccia del ritardo di replica, dello stato di avanzamento dei checkpoint, delle velocità di throughput, dello stato del percorso e delle prestazioni dei processi nell'intera distribuzione. Le API REST forniscono anche l'accesso programmatico ai dati di monitoraggio, consentendo l'integrazione con i framework di automazione e le piattaforme di osservabilità aziendali.

Un componente di monitoraggio chiave nell'architettura dei microservizi è il servizio metriche delle prestazioni (PMSRVR), che raccoglie ed espone le metriche operative per i processi di replica e i percorsi di distribuzione. Queste metriche possono essere integrate con soluzioni di monitoraggio come Oracle Enterprise Manager, OCI Monitoring, Prometheus e Grafana per fornire dashboard centralizzati, avvisi e analisi delle prestazioni a lungo termine. Gli amministratori si basano anche su log di distribuzione, file di report e informazioni di diagnostica disponibili tramite le interfacce Service Manager e Administration Service per risolvere gli errori, monitorare il comportamento dei processi e analizzare i problemi di latenza.

Per le distribuzioni OCI GoldenGate, sono disponibili funzionalità di monitoraggio aggiuntive tramite OCI Console, OCI Logging, OCI Monitoring e OCI Alarms, fornendo visibilità cloud-native sullo stato della distribuzione, sul comportamento di scalabilità, sui ritardi di replica e sugli eventi operativi. Nel complesso, il monitoraggio in GoldenGate Microservices Architecture si concentra sull'osservabilità centralizzata, sulla gestione basata su API e sull'integrazione con le piattaforme di monitoraggio aziendali per fornire insight in tempo reale sulle prestazioni di replica e sullo stato del sistema.

Gli utenti possono creare dashboard e applicazioni di monitoraggio personalizzati accedendo alle esportazioni e alle chiamate API StatsD.

Che cosa sono i file trail e come vengono utilizzati da Oracle GoldenGate nella replica?

I file trail memorizzano le modifiche ai dati acquisite dal processo Extract in un formato indipendente dalla piattaforma.

• Agiscono come intermediario tra i processi Extract e Replicat.

• Fornire la tolleranza agli errori consentendo la ripetizione delle modifiche acquisite.

• Separa il componente Extract e Replicat per consentire una maggiore flessibilità delle architetture GoldenGate, ad esempio da 1 a molti per la distribuzione dei dati, nonché la replica a cascata. Inoltre, rende la replica multipiattaforma più efficiente.

• È in formato binario proprietario che può essere interpretato dalla utility Logdump, solitamente necessaria durante le sessioni di risoluzione dei problemi. Per i dettagli, vedere la guida Riferimento dump log.

• Per gli utenti che desiderano utilizzare i dati direttamente dal file trail GoldenGate, l'opzione migliore è utilizzare i flussi di dati GoldenGate, che consentiranno all'utente di eseguire la sottoscrizione a un canale gestito da GoldenGate Data Streams leggendo i file trail GoldenGate e inserendo ogni record del file trail come evento in tale canale.

Qual è il tipo di Replicat consigliato migliore?

Inizia con Parallel Replicat: per la maggior parte dei casi d'uso, in particolare quelli che coinvolgono carichi di lavoro transazionali ad alto volume, Parallel Non-Integrated Replicat offre le migliori prestazioni e flessibilità.

GoldenGate Le applicazioni e gli analytics distribuiti supportano il Replicat classico e coordinato.

Per GoldenGate per Distributed Applications and Analytics, a seconda della destinazione, Coordinated Replicat fornirà prestazioni migliori.

Come si imposta TLS/SSL per la replica sicura dei dati?

• Oracle GoldenGate supporta la cifratura TLS/SSL sia nella connessione al data store che nel percorso di distribuzione tra le distribuzioni GoldenGate.

• Per il percorso di distribuzione che utilizza TLS/SSL, i certificati vengono gestiti tramite l'endpoint RestAPI di Service Manager. L'uso può anche eseguire il task di gestione dei certificati tramite WebUI di Service Manager.

• Il percorso di distribuzione può essere creato nel servizio di distribuzione o nel servizio ricevente (percorso avviato dalla destinazione).

• Aggiornare i file dei parametri con le direttive ENCRYPTION.

• Per proteggere il percorso di distribuzione utilizzando TLS/SSL, la distribuzione deve essere impostata come "distribuzione non protetta + NGINX" o "distribuzione protetta". Per ulteriori informazioni, vedere Secure Data in Transit e How to Convert Non Secure Deployment Into Secure Deployment with SSL/TLS.

  • Quando si utilizza NGINX, il TLS termina con NGINX. Solo la porta di ascolto NGINX deve essere esposta al traffico in entrata.
  • Quando si utilizza una distribuzione protetta, tutte le porte di ascolto dei servizi GoldenGate devono essere esposte al traffico in entrata. Il protocollo TLS termina alle porte del servizio.

Quali sono le opzioni per la cifratura dei file trail?

• Oracle GoldenGate attualmente supporta i tre metodi di cifratura riportati di seguito. Quando si comunica con Oracle GoldenGate in esecuzione su HP NSK, è supportato anche il metodo ENCKEYS. Tuttavia, questo è fortemente scoraggiato se non è coinvolta alcuna build HP NSK. Tutti i metodi di cui sopra supportano l'algoritmo di crittografia AES.
  • Utilizzo della chiave di cifratura primaria all'interno del wallet
  • Oracle OKV per il vault in locale
  • KMS OCI per il servizio vault
• Configura la crittografia tramite il parametro ENCRYPTTRAIL.

Per ulteriori informazioni sulla protezione dei dati, vedere Secure Data at Rest nella documentazione sui microservizi Oracle GoldenGate.

In che modo è possibile integrare Oracle GoldenGate con provider di identità esterni (ad esempio, IAM, OAM) per l'autenticazione di GoldenGate?

• L'architettura dei microservizi Oracle GoldenGate supporta l'integrazione con provider di identità esterni come Oracle Identity and Access Management (IAM), Oracle Access Manager (OAM) e Azure Entra ID per fornire l'autenticazione centralizzata, Single Sign-On (SSO) e il controllo dell'accesso basato sui ruoli per i servizi di amministrazione e monitoraggio GoldenGate. Questa integrazione è particolarmente importante negli ambienti aziendali e cloud in cui sono necessarie la governance centralizzata delle identità, la conformità alla sicurezza e l'autenticazione federata.

• In GoldenGate Microservices Architecture, l'autenticazione viene gestita tramite i servizi Service Manager e Administration Services, che supportano l'integrazione con i provider di identità aziendali utilizzando standard quali OAuth 2.0, OpenID Connect (OIDC), SAML e autenticazione basata su LDAP a seconda del modello di distribuzione e delle funzionalità del provider. Per le distribuzioni OCI GoldenGate, l'integrazione viene in genere eseguita tramite Oracle Cloud Infrastructure Identity and Access Management (OCI IAM), consentendo agli amministratori di utilizzare utenti, gruppi, criteri e servizi federativi OCI centralizzati per l'accesso sicuro alle distribuzioni GoldenGate e alle API REST.

• Quando si esegue l'integrazione con le soluzioni OAM (Oracle Access Manager) o SSO enterprise, GoldenGate viene in genere configurato dietro un proxy inverso o un gateway Web che gestisce l'autenticazione e la convalida dei token. Dopo aver eseguito correttamente l'autenticazione, le informazioni sull'identità utente e sull'autorizzazione vengono inoltrate ai servizi GoldenGate. Questo approccio consente criteri di login centralizzati, applicazione MFA, gestione delle sessioni e federazione delle identità aziendali senza richiedere credenziali separate specifiche GoldenGate.

• Per le integrazioni Azure Entra ID, GoldenGate può utilizzare i servizi di directory esterni forniti da Entra ID per l'autenticazione degli utenti e il mapping dei ruoli, consentendo alle organizzazioni di gestire l'accesso amministrativo tramite i gruppi di utenti enterprise esistenti e i criteri di sicurezza. Il controllo dell'accesso basato sui ruoli può quindi essere applicato per controllare le autorizzazioni per l'amministrazione, la gestione della distribuzione, il monitoraggio e l'accesso API all'interno dell'ambiente GoldenGate.

• GoldenGate Le API REST possono anche essere protette utilizzando meccanismi di autenticazione aziendali, consentendo alle piattaforme di automazione esterne, alle pipeline CI/CD e agli strumenti di monitoraggio di eseguire l'autenticazione utilizzando token di identità centralizzati anziché account di servizio locali. Nelle implementazioni cloud native e ibride, questa integrazione migliora la coerenza della sicurezza tra le piattaforme aziendali, semplificando al contempo la gestione del ciclo di vita degli utenti e la compliance degli audit.

• Nel complesso, l'integrazione di Oracle GoldenGate con provider di identità esterni consente l'autenticazione centralizzata, SSO, la gestione federata delle identità e i controlli di sicurezza di livello enterprise, rendendo le distribuzioni GoldenGate più facili da proteggere e gestire in ambienti aziendali e OCI su larga scala.

• Ogni provider di ID ha un'implementazione leggermente diversa sull'endpoint per la richiesta di token, anche con gli standard OIDC e OAuth 2.0. GoldenGate dovrà creare un profilo specifico per l'integrazione di tale provider ID con GoldenGate. Pertanto, se il provider di ID non è presente nell'elenco supportato, è possibile generare una richiesta di miglioramento.

Come faccio a eseguire la migrazione dei database senza tempi di inattività utilizzando Oracle GoldenGate?

Oracle GoldenGate consente migrazioni del database quasi senza tempi di inattività replicando continuamente le modifiche transazionali dal database di origine al database di destinazione, mentre entrambi i sistemi rimangono online. Invece di richiedere una lunga finestra di interruzione per le attività di esportazione, importazione e cutover, GoldenGate consente alle organizzazioni di sincronizzare i dati in tempo reale in modo che il cutover finale della migrazione possa essere completato con una minima interruzione dell'applicazione.

In un'architettura di migrazione tipica senza tempi di inattività, GoldenGate acquisisce le modifiche dal database di origine utilizzando Integrated Extract e le scrive in file trail. Le modifiche vengono quindi trasmesse tramite i servizi di distribuzione e applicate al database di destinazione utilizzando Parallel Replicat. Durante la migrazione del caricamento dati iniziale tramite backup/ripristino, Data Pump, duplicazione RMAN o altri metodi di caricamento di massa, GoldenGate replica continuamente le transazioni in corso in modo che la destinazione rimanga sincronizzata con l'origine durante tutto il processo di migrazione.

Il flusso di lavoro di migrazione di solito segue diverse fasi:

• preparazione e configurazione dell'ambiente
• caricamento dati iniziali
• replica in continuo cambiamento
• convalida e sincronizzazione
• cutover controllato

Durante la fase di caricamento iniziale, una copia completa del database viene trasferita all'ambiente di destinazione. Una volta caricati i dati della baseline, GoldenGate applica tutte le modifiche transazionali in corso acquisite dal database di origine. Questa replica continua riduce notevolmente la finestra di indisponibilità perché il database di destinazione è già quasi sincronizzato prima dell'inizio del cutover.

La convalida dei dati è una parte fondamentale delle migrazioni senza tempi di inattività. Oracle GoldenGate Veridata viene in genere utilizzato per confrontare i database di origine e di destinazione durante la replica per garantire la coerenza dei dati prima dello switchover di produzione. La convalida continua aiuta a identificare le discrepanze in anticipo e riduce i rischi di migrazione.

Al momento del cutover, l'attività dell'applicazione viene brevemente sospesa, le transazioni rimanenti possono essere replicate e gli amministratori verificano che il ritardo di replica raggiunga lo zero. Una volta confermata la sincronizzazione, le applicazioni vengono reindirizzate al database di destinazione e l'ambiente di destinazione diventa il nuovo sistema di produzione. Poiché la maggior parte dello spostamento dei dati si è verificato mentre i sistemi erano online, la finestra di indisponibilità effettiva è in genere ridotta solo al processo di sincronizzazione e reindirizzamento dell'applicazione finale.

GoldenGate supporta migrazioni senza tempi di inattività tra:

• Migrazioni Oracle-Oracle
• aggiornamenti tra versioni
• migrazioni della piattaforma
• migrazioni da on-premise a OCI
• migrazioni di database eterogenee
• transizioni multicloud e cloud ibrido

Nella moderna architettura dei microservizi GoldenGate e nelle implementazioni OCI GoldenGate, la gestione della migrazione è ulteriormente semplificata attraverso interfacce Web centralizzate, API REST, servizi di distribuzione automatizzati e funzionalità di monitoraggio integrate. I servizi di replica parallela, acquisizione integrata e distribuzione scalabile aiutano a gestire in modo efficiente carichi di lavoro transazionali di grandi dimensioni durante le attività di migrazione.

Nel complesso, Oracle GoldenGate consente migrazioni senza tempi di inattività combinando replica in tempo reale continua, elaborazione parallela scalabile, convalida continua e procedure di cutover controllate, consentendo alle organizzazioni di eseguire la migrazione dei database critici con interruzioni aziendali minime e rischi operativi ridotti.

Quali sono le best practice per la configurazione della replica bidirezionale?

Le best practice per la configurazione della replica bidirezionale con Oracle GoldenGate includono:

• Definisci un'architettura di replica attiva e attiva chiara e regole di proprietà dei dati.
• Evita i conflitti di aggiornamento garantendo che gli stessi dati non vengano modificati contemporaneamente su entrambi i sistemi quando possibile.
• Configura in modo appropriato i criteri di rilevamento e risoluzione dei conflitti (CDR).
• Utilizzare chiavi primarie o chiavi univoche in tutte le tabelle replicate.
• Assicurarsi che le tabelle di origine e di destinazione abbiano strutture identiche e tipi di dati compatibili.
• Escludi dalla replica le tabelle non necessarie, gli oggetti temporanei e le operazioni non supportate.
• Utilizzare i meccanismi di prevenzione del loop per evitare che le transazioni replicate vengano rispedite al sistema di origine.
• Gestisce i set di caratteri, i fusi orari e le definizioni dello schema del database sincronizzati.
• Monitora continuamente i ritardi di replica, lo stato dei processi e gli eventi di conflitto.
• Eseguire regolarmente il test delle procedure di failover, switchover e recupero.
• Configura il checkpoint appropriato e la gestione dei trail.
• Separa i carichi di lavoro e ridimensiona l'infrastruttura in modo appropriato per il traffico attivo-attivo.
• Utilizzare log supplementari e configurazioni di log delle transazioni appropriate.
• Implementa solide procedure di monitoraggio, avviso e audit.
• Convalida regolarmente la coerenza dei dati utilizzando strumenti come Oracle GoldenGate Veridata.
• Pianificare attentamente la replica DDL e le modifiche allo schema.
• Documentare chiaramente le regole di gestione dei conflitti e le procedure operative.

Gli ambienti di replica bidirezionale richiedono un'attenta pianificazione perché sono più complessi della replica unidirezionale e possono presentare problemi come:

• aggiorna conflitti
• loop di replica
• divergenza dati
• sensibilità alla latenza
• complessità operativa.

Cosa significa quando Replicat mostra transazioni "bloccate" e come posso risolverle?

Quando Replicat mostra le transazioni "bloccate", in genere significa che il processo Replicat non è in grado di applicare una o più transazioni sul database di destinazione e l'avanzamento della replica si interrompe o viene ritardato.

Le cause comuni includono:

• blocchi del database o sessioni di blocco nella destinazione
• record mancanti o in conflitto
• violazioni dei vincoli
• errori chiave duplicati
• operazioni non supportate
• transazioni con tempi di esecuzione lunghi
• tipo di dati non corrispondente
• problemi di rete o connettività
• risorse del sistema insufficiente

I passaggi tipici per la risoluzione dei problemi includono:

• esaminare il file del report Replicat ed eliminare il file per individuare eventuali errori
• controllare i log degli errori GoldenGate
• identificare la transazione o la tabella che causa il blocco
• verifica la disponibilità e lo stato del database di destinazione
• controllare gli oggetti bloccati o le sessioni di blocco
• risolvere conflitti di dati o problemi di vincolo
• conferma che i file trail sono accessibili e intatti
• verifica l'avanzamento del checkpoint
• riavviare Replicat dopo aver corretto il problema, se necessario

In alcuni casi, potrebbe essere necessario che gli amministratori:

• saltare le transazioni problematiche,
• riposizionare Replicat,
• o risincronizza le tabelle interessate

a seconda del caso, della gravità e dei requisiti aziendali.

Come gestire lo spazio su disco e rimuovere i vecchi file trail in Microservizi?

Nell'architettura dei microservizi Oracle GoldenGate, la gestione dello spazio su disco e la rimozione dei file trail sono importanti per evitare l'esaurimento dello storage e mantenere ambienti di replica in buono stato.

I file trail vengono in genere gestiti utilizzando criteri di rimozione automatici che rimuovono i vecchi file trail dopo che non sono più necessari dai processi a valle.

Le procedure comuni includono:

• configurazione della rimozione automatica dei file trail
• monitoraggio regolare dell'uso dei dischi
• separazione dello storage trail dallo storage del sistema operativo
• utilizzo di file system o volumi dedicati
• impostazione dei criteri di conservazione in base ai requisiti di recupero

I file trail possono in genere essere rimossi quando:

• tutti i processi Extract e Replicat li hanno elaborati
• i checkpoint sono avanzati oltre i file
• i file non sono per il recupero o la risincronizzazione

Nei microservizi, la gestione dei trail viene comunemente gestita tramite:

• il server di amministrazione;
• Servizio di distribuzione
• Servizio di ricezione
• strumenti di amministrazione della riga di comando
• o interfacce API REST

Di seguito sono riportate alcune raccomandazioni aggiuntive.

• abilitazione del monitoraggio e degli avvisi dello spazio su disco
• archiviazione dei trail, se necessario per l'audit
• utilizzo dello storage esterno per lunghi periodi di conservazione
• revisione periodica dei criteri di rimozione e dei trend di crescita dello storage

Una corretta gestione dei trail aiuta a evitare:

• interruzioni della replica
• condizioni complete del disco
• Deterioramento delle prestazioni
• complicazioni di recupero.

Come si configura l'avvio e il riavvio automatici nei microservizi?

Nell'architettura dei microservizi Oracle GoldenGate, è possibile configurare l'avvio e il riavvio automatici per avviare e recuperare automaticamente i servizi di distribuzione e i processi di replica dopo gli errori o il riavvio del server.

Questo in genere è configurato da:

• abilitazione dei profili di avvio automatico per i processi Extract e Replicat
• abilitazione dei criteri di riavvio automatico con intervalli di nuovi tentativi e conteggi nuovi tentativi
• configurazione del comportamento di avvio di Service Manager
• integrazione della distribuzione con i servizi del sistema operativo o le piattaforme di orchestrazione dei container

Le impostazioni di riavvio automatico garantiscono l'alta disponibilità riavviando automaticamente i processi non riusciti senza intervento manuale.

Le opzioni di configurazione comuni includono:

• ritardo avvio
• conteggio nuovi tentativi
• intervallo tra nuovi tentativi
• ordinazione delle dipendenze
• soglie di errore

Queste impostazioni possono in genere essere gestite tramite:

• l'interfaccia Web GoldenGate Microservices
• API REST
• o strumenti di amministrazione della riga di comando

L'avvio e il riavvio automatici sono comunemente utilizzati in:

• ambienti HA di produzione
• implementazioni cloud
• ambienti containerizzati
• architetture di disaster recovery
• sistemi di replica non assistiti.

Quali sono i passi di risoluzione dei problemi relativi al ritardo della replica?

I passi comuni di risoluzione dei problemi per il ritardo della replica di Oracle GoldenGate includono:

• Controllare lo stato di ritardo utilizzando i comandi o i dashboard di monitoraggio GoldenGate.
• Verificare se i processi Extract, Pump o Replicat sono in esecuzione normalmente.
• Esaminare i file di report GoldenGate e i log degli errori per individuare avvertenze o errori.
• Controllare le transazioni con tempi di esecuzione lunghi nel database di origine.
• Monitorare la latenza e la larghezza di banda di rete tra i sistemi di origine e di destinazione.
• Verificare che i file trail vengano generati e utilizzati correttamente.
• Controllare l'utilizzo di CPU, memoria, I/O su disco e storage sia sui server di origine che su quelli di destinazione.
• Assicurarsi che i progressi dei checkpoint procedano normalmente.
• Esaminare i problemi delle prestazioni del database, ad esempio i blocchi, le query lente o i conflitti di risorse.
• Verificare che i log di archivio o i log delle transazioni siano disponibili e non mancanti.
• Verificare la presenza di operazioni batch di grandi dimensioni o picchi nel volume delle transazioni.
• Ottimizzare le prestazioni Replicat utilizzando il parallelismo o il batch, se necessario.
• Verificare che le posizioni del disco del file trail dispongano di spazio sufficiente.
• Convalida le configurazioni dei parametri per i processi Extract, Pump e Replicat.
• Riavviare i processi interessati, se necessario, dopo aver risolto la causa principale.

L'analisi del ritardo di replica di solito si concentra sull'identificazione del collo di bottiglia causato da:

• attività del database di origine,
• ritardi nella rete,
• GoldenGate elaborazione,
• o prestazioni del database di destinazione.

Come posso utilizzare GoldenGate per flussi di dati distribuiti e dualità relazionale JSON?

• Oracle Database 23ai JSON Relational Duality Views consente agli sviluppatori di utilizzare facilmente i dati relazionali come modelli di documenti JSON. Ciò combina i vantaggi dei documenti JSON con quelli del modello relazionale, evitando al contempo i limiti di ciascuno. La vista di dualità relazionale JSON di Oracle è essenzialmente una vista SQL che presenta i dati JSON in un formato strutturato e relazionale.
• La replica dei business object con Oracle JSON Relational Duality e GoldenGate Data Streams dà la priorità ai prodotti dati e diventa l'unica fonte di dati per applicazioni, fabric transazionali, mesh di dati/eventi e data fabric garantendo l'univocità degli oggetti dati.
• Puoi fare riferimento a Oracle LiveLabs per scoprire come configurare GoldenGate Data Streams con JSON Relational Duality.

Quali sono le opzioni avanzate per la trasformazione dei dati in GoldenGate?

• Utilizzare le funzioni di mapping, filtro e trasformazione delle colonne nei file dei parametri.
• Integra SQLEXEC per query o procedure personalizzate.

È possibile eseguire GoldenGate su z/OS per acquisire le modifiche da o consegnare le modifiche a Db2 per zOS?

• GoldenGate non esegue Extract/Replicat direttamente su z/OS. Invece, Extract/Replicat verrà eseguito in remoto nella piattaforma di supporto come AIX/Linux/zLinux e si connetterà a Db2 z/OS per l'acquisizione remota e la consegna remota.
• GoldenGate deve installare un piccolo pacchetto in Db2 z/OS per chiamare determinate API per acquisire le modifiche dai file di log Db2. I dettagli sono disponibili in Installa componenti di estrazione in Db2 z/OS.

Se si esegue Replicat solo su Db2 z/OS, il pacchetto non è necessario.

GoldenGate per Db2 per i e Db2 LUW dispone di architettura per microservizi?

• Sì, a partire da GoldenGate 26ai, GoldenGate ha aggiunto l'architettura dei microservizi e solo l'architettura dei microservizi per queste due build.
• Prima del 26ai, sono disponibili solo architetture classiche per entrambe le build.

GoldenGate fornisce driver ODBC in Db2 per i/Db2 per l'installazione della build LUW/Db2 z/OS?

No, l'utente finale dovrà installare i driver ODBC appropriati utilizzando il proprio contratto di licenza con IBM per quei driver ODBC se non sono già installati sul server in cui è installato GoldenGate. Fare riferimento alla guida utente del driver ODBC di IBM su come scaricare i driver ODBC appropriati.

Come si esegue GoldenGate nel contenitore Docker?

Oracle GoldenGate può essere eseguito nei container Docker distribuendo il software GoldenGate come servizio containerizzato. Oracle fornisce immagini contenitore GoldenGate tramite Oracle Container Registry (OCR), consentendo agli utenti di estrarre e distribuire immagini predefinite per un'impostazione più rapida e ambienti standardizzati.

L'esecuzione di GoldenGate nei container offre vantaggi quali:

• implementazione e aggiornamenti semplificati
• portabilità tra gli ambienti
• scalabilità più semplice
• migliore integrazione con le piattaforme cloud native

GoldenGate L'architettura dei microservizi è in genere preferita per le distribuzioni di container perché è progettata per ambienti distribuiti moderni e funziona bene con le piattaforme di orchestrazione Docker e Kubernetes.

Le distribuzioni GoldenGate containerizzate vengono comunemente utilizzate in:

• ambienti cloud
• Pipeline CI/CD
• Piattaforme Kubernetes
• architetture ibride e multi-cloud
• moderne soluzioni di replica e streaming dei dati

Lo storage persistente viene in genere configurato esternamente per conservare trail, checkpoint e dati di configurazione al di fuori del ciclo di vita del contenitore.

Che cos'è OCI GoldenGate?

Oracle Cloud Infrastructure (OCI) GoldenGate è una piattaforma Fabric di dati completamente gestita e cloud nativa che consente lo spostamento, l'integrazione e lo streaming dei dati in tempo reale in ambienti eterogenei su scala aziendale. Acquisisce e offre modifiche ai dati transazionali con bassa latenza tra database, data warehouse, piattaforme di analisi, sistemi di messaggistica e servizi cloud.

Come componente di base di una moderna strategia Data Fabric, OCI GoldenGate aiuta le organizzazioni a connettere, sincronizzare e rendere operativi i dati distribuiti in ambienti on-premise, ibridi e multicloud. Supporta una vasta gamma di casi d'uso, tra cui la replica dei dati in tempo reale, le migrazioni senza tempi di inattività, il reporting operativo, le architetture basate sugli eventi, gli analytics in streaming, le pipeline di dati AI/ML e la sincronizzazione dei dati.

OCI GoldenGate offre anche funzionalità integrate per progettare, orchestrare, monitorare, trasformare, convalidare e confrontare le pipeline di dati attraverso un'esperienza utente unificata e intuitiva.

In quali aree geografiche è disponibile OCI GoldenGate?

Controllare qui le aree correnti su cui è distribuito OCI GoldenGate - https://www.oracle.com/cloud/data-regions/

Dove posso trovare la documentazione di OCI GoldenGate?

La documentazione di OCI GoldenGate è disponibile all'indirizzo: https://docs.oracle.com/en/cloud/paas/goldengate-service/index.html

Quali sono i casi d'uso principali per OCI GoldenGate?

I principali casi d'uso per OCI GoldenGate includono:

• Replica dei dati: migrazione, CDC, reporting offline, data warehousing in tempo reale, integrazione con origini e destinazioni non Oracle e inclusione e distribuzione di Big Data
• Pipeline di dati: correlare eventi di dati e dati ETL in microbatch
• Analisi dei dati in streaming: serie temporali, ML integrato e geospaziale
• Verifica dei dati: confronta i dati ad alta velocità
• User experience semplice per spostare i dati on-premise in Autonomous AI Database, Cloud at Customer e Object Storage
• Semplice configurazione HA/DR e multi-attiva per le distribuzioni region-to-region OCI, ibride, on-premise-to-OCI e multicloud I casi d'uso continueranno a evolversi man mano che verranno aggiunti nuovi tipi e nuove funzioni di distribuzione.

Quali sono le differenze tra OCI GoldenGate e GoldenGate su OCI Marketplace?

Ecco un paio di differenze tra le due offerte:

• OCI GoldenGate è un servizio completamente gestito in cui Oracle gestisce le operazioni dell'infrastruttura come backup, applicazione di patch e upgrade. GoldenGate su OCI Marketplace è gestito dal cliente.
• OCI GoldenGate utilizza costrutti di servizi OCI come distribuzioni, connessioni, endpoint privati e scalabilità gestita
• OCI GoldenGate è basato su microservizi e non supporta l'architettura classica
• Prezzi: OCI GoldenGate utilizza crediti universali ed è disponibile un percorso BYOL per gli utenti on-premise. GoldenGate su OCI Marketplace richiede licenze on-premise.
• Connettività semplificata AI database AI autonomi in OCI GoldenGate con gestione automatica del wallet e supporto degli endpoint privati rispetto a un'impostazione più manuale in GoldenGate su OCI Marketplace.
• Scalabilità: OCI GoldenGate ridimensiona automaticamente fino a 3 volte il numero di OCPU selezionate durante la creazione di un'istanza (limite massimo di 24 OCPU per distribuzione). Il ridimensionamento di un'istanza è manuale con GoldenGate su OCI Marketplace.

Dove posso trovare gli Obiettivi del Livello di Servizio (SLO) e gli Accordi del Livello di Servizio (SLA)?

Utilizza il documento pillar PaaS e IaaS del servizio cloud pubblico corrente di Oracle e la pagina SLA di Oracle Cloud corrente:

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

Quanto costa OCI GoldenGate?

Il prezzo di OCI GoldenGate viene calcolato in base alle OCPU utilizzate dall'host GoldenGate OCI. La metrica OCPU all'ora segue la definizione standard:

• OCPU all'ora viene definito come il numero di ore Oracle Compute Unit (OCPU) utilizzate nell'ambito di Oracle Cloud Service. Una OCPU fornisce la capacità della CPU equivalente a quella di una memoria centrale fisica di Un processore con hyperthreading abilitato. Ogni OCPU corrisponde a due thread di esecuzione hardware, noti come vCPU. Ogni OCPU dispone di una quantità di memoria predefinita. Ogni frazione d'ora consumata dell'OCPU parziale verrà fatturata come ora intera.

• Non sono previsti minimi OCPU.
• Prezzo per OCPU all'ora: $1.3441
• Conteggi OCPU di distribuzione OCI GoldenGate: tra 1 e 24 OCPU
• Criterio scala automatica:
  • I clienti possono abilitare o disabilitare la scala automatica.
  • I clienti scelgono una dimensione di base (minima) da 1‚ 24 OCPU (tra 1 e 8 OCPU di base se la scala automatica è abilitata).
  • La scala automatica è 3x, la dimensione di base selezionata è la seguente:
    • Scalabilità automatica di OCI GG:
      • Scelta utente: Abilita o disabilita scala automatica: l'utente può scegliere se si desidera ridimensionare automaticamente
        • Scegli dimensione base: l'utente sceglie la dimensione base nelle OCPU. Ai fini della fatturazione, questa sarà la dimensione minima.
        • Scalabilità automatica: lo scale-up/down verrà eseguito automaticamente e in modo trasparente
      • Monitoraggio: OCI GoldenGate emette telemetria sul numero di OCPU utilizzate in un determinato momento
      • Ore parziali: seguire le stesse regole di Autonomous Database, Exadata Cloud Service: "Ai fini di Oracle Autonomous Data Warehouse e Oracle Autonomous Transaction Processing, le ore OCPU parziali consumate vengono fatturate come ore parziali con un minimo di un minuto".
      • Utilizzo di picco: seguire le stesse regole di Autonomous Database ed Exadata Cloud Service: "Se la scala automatica è abilitata, Cloud Service fornirà sempre la capacità per il numero di OCPU specificate quando sono state create o scalate in modo esplicito. il servizio, ma il Cloud Service potrebbe anche fornire OCPU aggiuntive (fino a un totale di 3x del numero di OCPU specificate durante la creazione o il ridimensionamento esplicito del servizio) in base alle esigenze in base al carico di lavoro. Il consumo di OCPU all'ora verrà calcolato come segue: al massimo (il numero di OCPU per il servizio, le OCPU effettive consumate dal servizio). L'uso effettivo della OCPU si basa sul consumo al minuto, in media su un'ora".

Puoi anche fare riferimento a Cloud Estimator che include OCI GoldenGate nella categoria Data Integration: https://www.oracle.com/cloud/costestimator.html

Come viene concesso in licenza BYOL?

Rapporti conversione:

• Per ogni licenza con processore 8, è possibile attivare fino a 1 OCPU di OCI GoldenGate.
• Per ogni 400 licenze Named User Plus supportate, è possibile attivare fino a 1 OCPU ora di OCI GoldenGate.

Ciascuna delle seguenti licenze di programma supportate può essere aggregata per raggiungere il rapporto di conversione indicato sopra:

• Oracle GoldenGate o
• Oracle GoldenGate per non Oracle AI Database o
• Oracle GoldenGate for Distributed Applications and Analytics o
• Oracle GoldenGate for Big Data (ma non Oracle GoldenGate for Big Data Targets)

Posso eseguire la migrazione del Marketplace GoldenGate a OCI GoldenGate?

• La migrazione da GoldenGate (GoldenGate on-premise o GoldenGate Marketplace) a OCI GoldenGate non è automatizzata.
• OCI GoldenGate si basa sull'architettura dei microservizi GoldenGate. Quindi, se il cliente sta già utilizzando GoldenGate (on-premise, su Compute o in OCI Marketplace), questa è una migrazione tecnica molto semplice. Per ulteriori informazioni, vedere Migrazione a Oracle Cloud Infrastructure GoldenGate.
• Se il cliente utilizza l'architettura classica GoldenGate, durante la migrazione sarà necessario eseguire ulteriori operazioni. Questo percorso di migrazione è un percorso di migrazione comprovato che molti clienti hanno già completato con successo per i loro investimenti on-premise. È disponibile anche una utility di migrazione da GoldenGate Classic a GoldenGate Microservizi, che può essere utilizzata per aiutare i clienti a eseguire la migrazione.

Come dimensionare in modo appropriato OCI GoldenGate?

OCI GoldenGate utilizza un'architettura hub.

• Tutti i dati vengono instradati tramite l'host GoldenGate OCI.
• I dati vengono acquisiti in remoto dall'origine.
• I dati vengono consegnati in remoto alla destinazione.
• Rivedere le informazioni su misurazione e fatturazione
• Rivedere Informazioni sull'utilizzo della OCPU
• Esaminare le considerazioni sul dimensionamento per il tipo di distribuzione in Gestione e fatturazione OCPU

Nota:

• Esistono molte variabili relative alle prestazioni (rete, database di origine/destinazione, uso efficace degli indici, forma dello schema e così via). Pertanto, i test del mondo reale sui carichi di lavoro di produzione sono il gold standard per il dimensionamento appropriato.
• È possibile monitorare l'utilizzo della OCPU nella pagina Dettagli distribuzione GoldenGate OCI e in Esplora metriche nella console OCI.
• È possibile impostare allarmi nella console OCI per ricevere una notifica quando l'utilizzo della OCPU raggiunge determinati livelli.

Quali origini e destinazioni sono supportate in OCI GoldenGate?

Per informazioni sui sistemi di origine e di destinazione supportati, vedere Esplora connessioni.

OCI GoldenGate può connettersi a IP privati o a sistemi Oracle on premise?

Sì. Per ulteriori informazioni sulla connettività, vedere Connettività OCI GoldenGate.

La connettività OCI GoldenGate all'origine e alla destinazione è abilitata con l'acquisizione remota e la consegna remota.

Come faccio a impostare un percorso di distribuzione tra OCI GoldenGate e GoldenGate in esecuzione su OCI Marketplace o on-premise?

Il seguente LiveLabs descrive come creare percorsi di distribuzione tra OCI-GG e un'installazione di microservizi GG:

• Inviare i dati da Oracle GoldenGate a OCI GoldenGate
• Invia dati da OCI GoldenGate a Oracle GoldenGate

OCI GoldenGate supporta i database Oracle a istanza singola?

Sì, sono supportate entrambe le istanze collegabili (multi-tenant) e singole.

I database autonomi dedicati sono supportati?

Sì, gli ambienti Autonomous AI Database on Dedicated Infrastructure sono completamente supportati.

Consulta la documentazione corrente di Autonomous AI Database e OCI GoldenGate per conoscere i prerequisiti esatti: Oracle Autonomous AI Database

Posso accedere a OCI GoldenGate e monitorarlo utilizzando Oracle Management Cloud e Oracle Enterprise Manager (OEM)?

Management Pack per GoldenGate ora supporta OCI GoldenGate.

Che cos'è Oracle GoldenGate Foundation Suite?

Oracle GoldenGate Foundation Suite è un bundle di tre prodotti. Sono inclusi:

• Oracle GoldenGate Veridata
• Oracle GoldenGate Management Pack (plugin e monitor EM)
• Oracle GoldenGate Studio

Descrizione di Oracle GoldenGate Veridata

Oracle GoldenGate Veridata è una soluzione di riparazione e confronto dei dati ad alta velocità che identifica, riporta e corregge le discrepanze dei dati tra database eterogenei senza interrompere automaticamente i processi aziendali in corso. Fornisce una soluzione facile da usare ma potente per identificare i dati non sincronizzati prima che abbiano un impatto negativo sull'azienda.

Quali sono i vari componenti di Oracle GoldenGate Veridata?

Di seguito sono riportati i vari componenti di Oracle GoldenGate Veridata.

• Veridata Agent
• Server Veridata
• Database repository Veridata
• Utility Vericom - CLI

Come viene eseguito il confronto dei dati in tempo reale con Oracle GoldenGate Veridata?

Oracle GoldenGate Veridata esegue il confronto dei dati in tempo reale confrontando i database di origine e di destinazione mentre è in esecuzione la replica di Oracle GoldenGate.

Ecco il processo generale:

1. GoldenGate replica quasi in tempo reale le modifiche transazionali dal database di origine al database di destinazione.

2. Veridata si connette in modo indipendente sia ai database di origine che a quelli di destinazione.

3. Confronta i dati in chunk o intervalli di righe configurabili utilizzando:

   • chiavi primarie
   • hash/checksum
   • convalida riga per riga quando vengono rilevate corrispondenze errate

4. Veridata identifica:

   • righe mancanti
   • righe extra
   • valori colonna modificati
   • transazioni non sincronizzate

5. I job di confronto possono essere eseguiti ripetutamente o continuamente mentre la replica rimane attiva, consentendo la convalida continua con un impatto minimo sui sistemi di produzione.

Per evitare il blocco delle tabelle o l'interruzione della replica, Veridata utilizza tecniche di confronto ottimizzate quali:

• confronto basato su checksum
• elaborazione parallela
• scansioni di tabelle partizionate
• chunk di gamma di chiavi

Ciò consente alle organizzazioni di verificare che i dati replicati rimangano sincronizzati durante:

• migrazioni
• aggiornamenti
• cutover senza tempi di inattività
• replica attiva-attiva
• operazioni di disaster recovery

Veridata stessa non replica i dati,convalida l'accuratezza della replica GoldenGate quasi in tempo reale.

Per informazioni sul confronto dei dati in tempo reale mediante Oracle GoldenGate Veridata, vedere Oracle GoldenGate Veridata 26c: come funziona?

Qual è la dimensione di Oracle GoldenGate Veridata?

Per informazioni sul dimensionamento di Oracle GoldenGate Veridata, vedere Come dimensionare Oracle GoldenGate Veridata?.

A cosa serve il database repository Veridata?

Tutte le informazioni sui metadati (ovvero tutte le configurazioni di Veridata) verranno memorizzate nel database del repository Veridata.

Veridata 26c viene fornito con un database MySQL incorporato come repository.

Tuttavia, il cliente ha la possibilità di utilizzare questo MySQL integrato o il proprio database MySQL per il repository.

Quali sarebbero le dimensioni del database del repository Veridata?

Tutte le informazioni sui metadati di Veridata verranno memorizzate in questo database del repository.

Quindi, non sarebbe di grandi dimensioni. Un massimo di 5 GB corrisponde alla dimensione del repository.

È possibile utilizzare Oracle GoldenGate Veridata per confrontare i dati tra database eterogenei?

Sì, Oracle GoldenGate Veridata è una soluzione di confronto e riparazione dei dati eterogenea.

Controllare la seguente matrice di certificazione collegata:

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

È possibile confrontare le DDL della tabella utilizzando Oracle GoldenGate Veridata?

No, Oracle GoldenGate Veridata è uno strumento di confronto dei dati e può solo confrontare i dati tra le tabelle. Tuttavia, abbiamo questo nella nostra roadmap.

Oracle GoldenGate Veridata può monitorare la replica dei dati tra origini e destinazioni in tempo reale?

Sì, Oracle GoldenGate Veridata può monitorare e convalidare la replica dei dati tra i database di origine e di destinazione quasi in tempo reale. Confronta continuamente i dati durante l'esecuzione della replica GoldenGate e identifica le discrepanze, ad esempio righe mancanti, righe aggiuntive o mancata corrispondenza dei dati.

Ciò garantisce che i database replicati rimangano sincronizzati durante le migrazioni, gli upgrade e le operazioni di replica in corso, con un impatto minimo sui sistemi di produzione.

È necessario installare il server Veridata per ogni database di origine e destinazione?

No, un'installazione di Veridata è sufficiente per confrontare i dati tra più origini e destinazioni.

Non è necessario installare server Veridata dedicati a ciascun database di origine e di destinazione.

Cos'è l'agente Veridata? Come deve essere configurato?

Veridata Agent è un programma Java leggero responsabile del recupero dei dati dalle tabelle di database di origine e di destinazione.

È necessario configurare un agente dedicato per ogni database.

Ad esempio, se si dispone di 5 origini e destinazioni, è necessario configurare 5 agenti Veridata per 5 origini e 5 agenti Veridata per 5 destinazioni.

Dove è necessario installare e distribuire gli agenti Veridata?

Gli agenti Veridata possono essere distribuiti in modo nativo o remoto nei database server. Quando si configurano gli agenti Veridata in remoto, è necessario assicurarsi di avere una buona rete tra gli agenti Veridata e i database di origine/destinazione.

Dove si trova il file Veridata Agent Properties?

Questo può essere trovato nel percorso < AGENT_HOME > con il nome "agent.properties".

Dove è presente il file di configurazione del server Veridata?

Il file di configurazione del server Veridata è presente nel seguente percorso:

/config/veridata/veridata.cfg

Dove è presente il file oggvdt_cainput.properties?

Il file oggvdt_cainput.properties è presente nel seguente percorso:

/config/oggvdt_cainput.properties

Dove posso trovare i report Veridata?

I report Oracle GoldenGate Veridata vengono in genere generati e memorizzati sull'host del server Veridata nella directory di installazione Veridata.

Le posizioni predefinite sono in genere le seguenti:

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

È inoltre possibile accedere ai report dall'interfaccia utente Web Veridata:

1. Eseguire il login alla console Veridata.
2. Aprire il job di confronto.
3. Andare a Report o Dettagli job → Report.
4. Scarica output HTML, XML o PDF, a seconda della configurazione.

I tipi di report comuni includono:

• Report sintetici confronto
• Report righe non sincronizzate
• Rapporti riparazione
• Report audit/conformità

Se si utilizza Veridata con i microservizi OGG o le distribuzioni OCI, i report possono invece essere scritti in:

• un volume attivato
• storage condiviso
• Storage degli oggetti OCI, a seconda della modalità di configurazione della distribuzione

È possibile verificare il percorso esatto del report in:

<VERIDATA_HOME>/cfg/veridata.cfg

o le proprietà di avvio/configurazione del server.

Possiamo avere più agenti Veridata per un database?

Sì, ma si consiglia 1 agente per 1 database.

Quante coppie di confronto posso creare in un gruppo?

Il numero di coppie di confronto che è possibile creare non è limitato. Qualsiasi numero va bene.

Quante coppie di confronto posso eseguire in parallelo in Veridata?

Il valore predefinito massimo è 100.

Ma può essere aggiornato dal file veridata.cfg modificando il valore di maxconcurrentjobs.

I dati incrementali o modificati possono essere confrontati su base giornaliera in Veridata?

Sì, Veridata ha una funzione chiamata Delta Comparison.

Dopo aver abilitato questa funzione, verranno confrontati solo i dati modificati.

Che cosa è Delta Comparation in Veridata?

Le coppie di confronto possono essere configurate per utilizzare l'elaborazione delta, una funzione delle prestazioni che confronta solo i blocchi di dati modificati dall'ultima esecuzione, invece di eseguire la scansione dell'intera tabella.

Ciò impedisce di confrontare ripetutamente tutti i dati cronologici e di confrontare solo i dati modificati.

Come posso abilitare Delta Comparison in Veridata?

In Oracle GoldenGate Veridata 26c, Delta Comparison è più allineato al modello moderno di "convalida continua dei dati" piuttosto che alle spiegazioni dell'elaborazione delta in stile classico della documentazione precedente. La funzione è progettata per ridurre il sovraccarico di confronto concentrandosi solo sui dati modificati tra i cicli di confronto, che è particolarmente importante per la convalida continua in ambienti di replica attivi-attivi, ibridi e su larga scala.

In Veridata 26c, Delta Comparison viene abilitato tramite l'interfaccia utente Web Veridata modernizzata durante la configurazione delle coppie di confronto e dei job. Invece di affidarsi molto ai flussi di lavoro della riga di comando legacy, gli amministratori configurano il comportamento di confronto direttamente nell'interfaccia utente o tramite le API REST. Il processo in genere prevede l'abilitazione della convalida basata sul delta all'interno della configurazione Confronta coppia in modo che Veridata tenga traccia delle modifiche tra le esecuzioni e limiti i confronti futuri ai set di dati modificati. Ciò riduce l'impatto del database e migliora le prestazioni di confronto per casi d'uso di convalida continua.

L'architettura 26c sottolinea inoltre:

• flussi di lavoro di convalida continua
• job pianificati
• Automazione API REST
• operazioni cloud native
• elaborazione di confronto scalabile basata su microservizi

piuttosto che i modelli di esecuzione del confronto standalone meno recenti.

Inoltre, Veridata 26c introduce la pianificazione nativa e funzionalità di automazione avanzate direttamente nell'interfaccia utente e nelle API, rendendo Delta Comparison più integrato a livello operativo nella convalida continua dello stato di replica piuttosto che essere trattato come una funzione di ottimizzazione manuale.

Quale versione del plugin Oracle Enterprise Manager è certificata per il monitoraggio delle distribuzioni dei microservizi Oracle GoldenGate 26ai?

Il monitoraggio e la ricerca automatica dei microservizi Oracle GoldenGate 26ai in Enterprise Manager 24ai è certificato con il plugin Oracle GoldenGate EM versione 13.5.2.0.6.

Perché i livelli di patch consigliati di Oracle AI Database e GoldenGate sono importanti per la stabilità e la supportabilità?

Oracle consiglia di eseguire Oracle GoldenGate con gli aggiornamenti della release di Oracle Database (RU) e le patch del bundle GoldenGate attualmente consigliate.

I livelli di patch del database precedenti possono esporre i clienti a:

• bug di acquisizione integrati,
• instabilità di LogMiner,
• combinazioni non supportate,
• vulnerabilità della sicurezza,
• e difetti di replica già corretti nelle RU più recenti.

Pratica consigliata:

Segui le ultime novità:

• GoldenGate note sulle patch consigliate,
• suggerimenti RU del database,
• e matrici di interoperabilità certificate.

Convalidare le correzioni prima di assumere difetti del prodotto su livelli di patch precedenti.

Nota primaria per i set di patch del prodotto di base di Oracle GoldenGate (KB159960)

Oracle GoldenGate e OCI GoldenGate supportano l'acquisizione dei dati di modifica da MongoDB?

Oracle GoldenGate e OCI GoldenGate supportano l'acquisizione dei dati di modifica da MongoDB e MongoDB Atlas. Supporta la replica bidirezionale tra database MongoDB diversi.

Posso utilizzare Oracle GoldenGate e OCI GoldenGate per le migrazioni da MongoDB a Oracle AI Database?

Sì, Oracle GoldenGate non supporta migrazioni senza tempi di inattività da MongoDB a Oracle AI Database. Per i dettagli, è possibile consultare la documentazione di Oracle GoldenGate.

Come posso configurare le migrazioni di Oracle GoldenGate per eseguire la migrazione da MongoDB a Oracle AI Database?

Assicurarsi di essere soddisfatti i prerequisiti riportati di seguito:

• La versione di origine MongoDB è 5 o successiva.
• Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA) 23.7 o versioni successive viene installato e configurato sia per le istanze di database di origine MongoDB che per quelle di destinazione.
• Vengono installati gli strumenti di database MongoDB (compresi mongodump e mongorestore) e i rispettivi percorsi di directory vengono aggiunti alla variabile di ambiente del percorso.

Per eseguire la migrazione di MongoDB a Oracle AI Database for Oracle GoldenGate, effettuare le operazioni riportate di seguito.

1. Eseguire la utility di dump MongoDB. Eseguire il comando mongodump con l'opzione --oplog per creare uno snapshot del database MongoDB di origine:

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

2. Eseguire lo script OplogLSN.sh per estrarre gli indicatori orari della prima e dell'ultima operazione dal file oplog.bson fornendo il percorso al file oplog.bson come argomento come indicato di seguito.

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

   L'output fornisce gli indicatori orari della prima e dell'ultima operazione (o il primo noop se non si è verificata alcuna operazione durante il processo di dump).

   Output:

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

3. Ispezionare le voci Oplog: se durante il dump sono state eseguite operazioni in entrata, il file oplog.bson contiene voci per tali operazioni, ognuna con un indicatore orario. È possibile utilizzare OplogLSN.sh per acquisire gli indicatori orari della prima e dell'ultima operazione oppure convertirli in file JSON per l'ispezione manuale, come mostrato nel passo precedente.

4. Eseguire la utility di ripristino MongoDB: dopo aver ottenuto gli indicatori orari necessari, utilizzare la utility mongorestore per ripristinare le raccolte selezionate dal dump nell'istanza MongoDB di destinazione:

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

5. Avviare l'estrazione CDC MongoDB: avviare il processo di estrazione CDC MongoDB dal primo indicatore orario operazione (posizione LSN) estratto dal file oplog.bson. Ciò garantisce che CDC Extract inizi ad acquisire le operazioni che si verificano dopo l'avvio del processo di dump.

6. Configurare il Replicat MongoDB con il file trail CDC generato e impostare la proprietà oplogReplayLastLsn sull'indicatore orario dell'ultima operazione dal file oplog.bson. Ciò garantisce che Replicat venga eseguito in modalità oplog-replay, evitando collisioni. Una volta elaborato l'ultimo indicatore orario, continua in modalità normale. Questa configurazione garantisce un avvio preciso, senza perdita o duplicazione dei dati, ed elimina la necessità di una costosa gestione delle collisioni in Replicat.

Come posso eseguire i caricamenti iniziali da Snowflake a Oracle AI Database?

1. Crea un'estrazione di acquisizione dati delle modifiche (da Oracle AI Database di origine).

2. Recupera SCN dal database di origine.

3. Creare un'estrazione del carico iniziale (da Oracle AI Database di origine).

4. Creare un percorso di distribuzione per CDC Extract.

5. Creare un percorso di distribuzione per l'estrazione del carico iniziale.

6. Creare un Replicat per il carico iniziale (targeting Snowflake).

7. Creare un Replicat per la replica di acquisizione dati di modifica (targeting di Snowflake).

Cosa devo fare per correggere "Eccezione: net.snowflake.client.jdbc.SnowflakeReauthenticationRequest: token di autenticazione scaduto. L'utente deve eseguire di nuovo l'autenticazione." errore nella replica Snowflake di Oracle GoldenGate?

Questo errore si verifica quando sono presenti periodi di inattività prolungati. Per risolvere questo problema, è possibile impostare il parametro JDBC CLIENT_SESSION_KEEP_ALIVE in modo che l'utente del database possa eseguire il login dopo un periodo di inattività.

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

Oracle GoldenGate e OCI GoldenGate supportano la replica DDL su Snowflake?

Oracle GoldenGate può essere configurato per propagare le modifiche DDL di origine alle tabelle Snowflake di destinazione. L'evoluzione automatica dello schema è la capacità di rilevare, gestire e applicare modifiche a uno schema di database, ad esempio tabelle, colonne, indici o relazioni, senza richiedere l'intervento manuale. L'evoluzione automatica dello schema supporta il rilevamento di nuovi oggetti e modifiche ai metadati, quindi genera automaticamente DDL di destinazione per l'evoluzione dello schema.

Per il caricamento iniziale, può creare o sostituire le tabelle di destinazione.

Per CDC Replicat, può creare o modificare le tabelle di destinazione durante l'applicazione in corso. Per ulteriori dettagli, consultare la documentazione di Oracle GoldenGate.

Posso utilizzare Oracle GoldenGate e OCI GoldenGate per la replica di Apache Iceberg?

Sì, Oracle GoldenGate supporta la replica dei dati in tempo reale in Apache Iceberg. Oracle GoldenGate utilizza l'API Java Apache Iceberg per le Apache Iceberg Lakehouse aperte. Oracle GoldenGate supporta i cataloghi Oracle AI Data Catalog, Amazon Glue, Polaris, Nesti, Hadoop e REST.

Posso utilizzare Oracle GoldenGate e OCI GoldenGate per la replica dei dati in tempo reale nelle tabelle Apache Iceberg su OCI Object Storage?

Sì, Oracle GoldenGate e OCI GoldenGate possono essere configurati per la replica dei dati in tempo reale nelle tabelle Apache Iceberg memorizzate nello storage degli oggetti OCI tramite l'endpoint API S3 dello storage degli oggetti OCI. Per ulteriori dettagli, consulta la sezione relativa alla creazione di un Apache Iceberg Lakehouse in tempo reale nello storage degli oggetti OCI con OCI GoldenGate.

La replica Apache Iceberg di Oracle GoldenGate e OCI GoldenGate supporta l'unione in scrittura?

Sì, Oracle GoldenGate e OCI GoldenGate supportano l'unione in scrittura per le tabelle Iceberg gestite da Snowflake, Google BigQuery e Databricks. Su queste piattaforme, GoldenGate utilizza le risorse di computazione della piattaforma di destinazione per il calcolo.

In che modo Oracle GoldenGate e OCI GoldenGate possono gestire gli aggiornamenti delle chiavi primarie nelle tabelle parquet nello storage degli oggetti OCI?

Oracle GoldenGate e OCI GoldenGate gestiscono gli aggiornamenti delle chiavi primarie in tre modalità. Questo comportamento è controllato aggiungendo gg.handler.name.format.pkUpdateHandling al file delle proprietà Replicat. I valori supportati includono abend, update e delete-insert. Abend è il comportamento predefinito. Replicat non riesce quando viene rilevato un aggiornamento della chiave primaria e registra l'errore nel file di report. L'aggiornamento tratta l'aggiornamento della chiave primaria come qualsiasi altra operazione di aggiornamento. Utilizzare questa impostazione solo se è possibile garantire che la chiave primaria non venga utilizzata come criterio di selezione.

Delete-insert replica l'aggiornamento della chiave primaria come due record: uno con l'immagine precedente, contrassegnata come eliminazione e uno con l'immagine successiva, contrassegnata come inserimento.

Per utilizzare delete-insert, il processo Extract deve acquisire record di dati di modifica non compressi, il che significa che tutte le colonne vengono scritte nel file trail.

Per generare record non compressi, utilizzare LOGALLSUPCOLS per le origini di Oracle AI Database e COMPRESSUPDATES | NOCOMPRESSUPDATES per i database non Oracle.

Ad esempio, quando si esegue la replica nello storage degli oggetti OCI, impostare gg.handler.<gg.target value>.format.pkUpdateHandling=delete-insert per replicare gli aggiornamenti della chiave primaria come un solo record di eliminazione con l'immagine precedente e un record di inserimento con l'immagine successiva.

Come posso replicare le colonne Oracle DATE e TIMESTAMP nelle tabelle parquet memorizzate nello storage degli oggetti OCI con Oracle GoldenGate?

Le colonne DATE e TIMESTAMP di Oracle vengono replicate come stringhe per impostazione predefinita quando non è configurato alcun mapping esplicito. Senza un mapping adeguato, i motori a valle non riconosceranno queste colonne come tipi date/time, rendendo impossibile l'aritmetica della data, il filtraggio dell'intervallo e il partizionamento basato sul tempo senza un casting esplicito. La proprietà enableTimestampLogicalType consente di mappare le colonne DATE e TIMESTAMP di Oracle al tipo logico Avro timestamp-micros, che rappresenta i valori come microsecondi dall'epoca, la rappresentazione corretta per i carichi di lavoro analitici e di data lake.

Nella replica dello storage degli oggetti cloud di Oracle GoldenGate, i tipi DATE e TIMESTAMP di origine vengono mappati ai file Avro (inclusi Parquet, Iceberg e Delta) come STRING per impostazione predefinita.

Per replicare i tipi DATE e TIMESTAMP di origine come tipo logico timestamp-micros in file Avro (inclusi Parquet, Iceberg e Delta), impostare gg.handler.<gg.target value>.format.enableTimestampLogicalType su true.

Quando il tipo logico di indicatore orario è abilitato, è necessario specificare anche gg.format.timestamp. Ad esempio: gg.handler.oci.format.enableTimestampLogicalType= truegg.format.timestamp=yyyy-MM-dd HH:mm:ss.SSSSSS

Come posso migliorare le prestazioni della replica dello storage degli oggetti OCI di Oracle GoldenGate?

È possibile eseguire il tuning delle prestazioni della replica di storage degli oggetti Oracle GoldenGate Cloud utilizzando due funzioni chiave: il tipo Replicat e il parametro GROUPTRANSOPS. Oltre al tipo Replicat e al raggruppamento delle transazioni, la dimensione dei file prodotti da Replicat influisce direttamente sul throughput e deve essere ottimizzata insieme alle altre impostazioni. Oracle GoldenGate Distributed Applications and Analytics offre due modalità di replica diverse: Replicat classico e Replicat coordinato.

Classic Replicat è un processo a thread singolo che applica i messaggi ai servizi di storage cloud di destinazione. Coordinato Replicat è un processo multi-threaded in cui più thread leggere il file trail OGG in modo indipendente e applicare le transazioni in parallelo. Il processo di replica dello storage degli oggetti di Oracle GoldenGate Cloud ottimizza l'elaborazione con il raggruppamento delle transazioni. Il parametro GROUPTRANSOPS raggruppa più transazioni di piccole dimensioni in un'unica transazione più grande applicata alle destinazioni di storage cloud. GROUPTRANSOPS è configurato nel file dei parametri. Per impostazione predefinita, GROUPTRANSOPS è impostato su 1000. È possibile aumentare fino a 20000 per ottenere prestazioni migliori.

Ad esempio: GROUPTRANSOPS 20000

Come si imposta la dimensione del file nella replica di Google Cloud Storage di Oracle GoldenGate e OCI GoldenGate?

Replicat di Oracle GoldenGate crea un file nel file system locale e lo mantiene aperto finché una condizione di rollover non viene soddisfatta o attivata da un evento di modifica dei metadati dall'origine, ad esempio la modifica DDL. Gli utenti possono controllare il rollover dei file utilizzando le proprietà di replica. Dimensione massima file controlla le dimensioni dei file. Per impostazione predefinita, le dimensioni dei file sono configurate a 1 GB, ma possono essere configurate in base alle esigenze. Quando viene raggiunta la dimensione massima, il file viene chiuso e viene generato un nuovo file. Per ulteriori dettagli, vedere Configurazione dell'handler di scrittura file in Oracle GoldenGate per la documentazione DAA.

Oracle GoldenGate e OCI GoldenGate supportano il partizionamento con replica di file parquet in Google Cloud Storage?

Oracle GoldenGate e OCI GoldenGate supportano la creazione di file partizionati nei bucket di storage degli oggetti di destinazione. Il partizionamento migliora la potatura a valle e le prestazioni delle query, ma il partizionamento eccessivo aumenta il conteggio di directory/file e amplifica il problema dei file di piccole dimensioni.

Per utilizzare il partizionamento, i dati devono essere partizionati dalla tabella al livello più alto. Questa operazione viene eseguita utilizzando la proprietà pathMappingTemplate e deve essere impostata sul nome della tabella completamente qualificato.

Creerà directory all'interno del container/bucket in base al nome della tabella di origine completamente qualificato. Ad esempio: gg.eventhandler.<gg.target value>.pathMappingTemplate=${fullyQualifiedTableName}

Per la creazione delle partizioni, viene utilizzato gg.handler.<gg.target value>.partitioner.<fully_qualified_table_name>. Questa proprietà può essere utilizzata con la parola chiave del modello, ad esempio ${columnValue[column_name]}, o con valori stringa costanti per definire la struttura del percorso della partizione.

Oracle GoldenGate e OCI GoldenGate supportano la replica DDL nei file parquet in Azure Data Lake Storage (ADLS)?

La replica ADLS di Oracle GoldenGate e OCI GoldenGate propaga automaticamente le modifiche DDL di origine ai file generati. In alternativa, è possibile utilizzare EVENTACTIONS per controllare il comportamento Extract/Replicat in caso di un'operazione DDL nel database di origine.

Se l'estrazione di Oracle GoldenGate acquisisce un evento Crea tabella dal database di origine, Replicat creerà un nuovo file con il nome della tabella dall'evento Crea tabella nel bucket/container di storage degli oggetti cloud di destinazione.

Se l'estrazione di Oracle GoldenGate acquisisce un evento Modifica colonna/Elimina colonna dal database di origine, Replicat creerà un nuovo file che riflette la definizione della tabella di origine aggiornata.

Se l'estrazione di Oracle GoldenGate acquisisce un evento Tronca dal database di origine, è possibile configurare Replicat per eseguire il rollback del file di dati sull'evento Tronca impostando le opzioni riportate di seguito.

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

Questa proprietà è impostata su false per impostazione predefinita e Replicat non esegue il rollback del file nell'evento Tronca. L'estrazione di Oracle GoldenGate acquisisce un evento Drop Table dal database di origine. Questa operazione non ha alcun impatto sul file system di destinazione.

In che modo Oracle GoldenGate e OCI GoldenGate gestiscono il tipo di dati Oracle NUMBER di origine durante la replica in file parquet su Azure Data Lake Storage (ADLS)?

Oracle NUMBER è un tipo di dati decimali di precisione variabile che può rappresentare numeri interi e valori decimali a virgola fissa con un massimo di 38 cifre di precisione.

Se una colonna viene definita senza precisione esplicita e scala (ad esempio, NUMBER), Oracle può memorizzare valori con scala variabile tra le righe e in alcuni scenari di replica/generazione di schemi il formatter potrebbe non essere in grado di derivare deterministicamente una singola precisione/scala per lo schema di destinazione. Di conseguenza, i mapping ad Avro/Parquet spesso utilizzano una rappresentazione decimale conservativa a meno che non si configuri esplicitamente precisione e scala per corrispondere alle definizioni delle colonne di origine.

gg.handler.<gg.target value>.enableDecimalLogicalType è lo switch principale per il mapping del tipo logico decimale. Se impostato su true, indica al formatter Avro di mappare le colonne NUMBER Oracle al tipo logico decimale Avro (byte con logicalType: decimal) anziché al mapping predefinito che scrive i numeri come primitive o stringhe numeriche Avro normali.

Quando la precisione/scala non può essere dedotta in modo deterministico, il formatter in genere sceglie una definizione decimale Avro conservativa (alta precisione e scala) per evitare perdite di precisione. Ciò può portare i consumatori a valle a vedere valori espressi su larga scala inutilmente (ad esempio, cifre frazionarie apparenti finali).

Per allineare lo schema di destinazione a definizioni di origine note e coerenti, in particolare per i dati finanziari (saldo, prezzi, importi):

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

Quali metodi di autenticazione ADLS sono supportati da Oracle GoldenGate e da OCI GoldenGate?

Oracle GoldenGate e OCI GoldenGate supportano le chiavi di accesso, la firma di accesso condiviso e l'ID Azure Entra.

Oracle GoldenGate supporta le tabelle Amazon S3?

Sì, Oracle GoldenGate supporta la replica Apache Iceberg in tempo reale sulle tabelle Amazon S3 tramite i cataloghi REST delle tabelle Amazon S3.

Oracle GoldenGate e OCI GoldenGate supportano il caricamento multiparte su Amazon S3?

Sì, l'abilitazione della funzione di caricamento multiparte di Amazon S3 consente di caricare i file di grandi dimensioni su Amazon S3 suddividendoli in piccole parti che possono essere caricate in modo indipendente e parallelo. Questa funzione risolve le limitazioni di Amazon S3 già note, come il singolo caricamento di oggetti di dimensioni superiori a 5 GB. Una volta che tutte le parti del file sono state caricate con successo, viene fatta una richiesta ad Amazon S3 per assemblarle in un unico oggetto. Per utilizzare questa funzione è necessario abilitare gg.eventhandler.s3.multipartEnabled=true nella replica Amazon S3.

Oracle GoldenGate e OCI GoldenGate supportano il partizionamento con replica di file parquet in Google Cloud Storage?

Oracle GoldenGate e OCI GoldenGate supportano la creazione di file partizionati nei bucket di storage degli oggetti di destinazione. Il partizionamento migliora la potatura a valle e le prestazioni delle query, ma il partizionamento eccessivo aumenta il conteggio di directory/file e amplifica il problema dei file di piccole dimensioni.

Per utilizzare il partizionamento, i dati devono essere partizionati dalla tabella al livello più alto. Questa operazione viene eseguita utilizzando la proprietà pathMappingTemplate e deve essere impostata sul nome della tabella completamente qualificato. Creerà directory all'interno del container/bucket in base al nome della tabella di origine completamente qualificato. Ad esempio: gg.eventhandler.<gg.target value>.pathMappingTemplate=${fullyQualifiedTableName}. Per la creazione delle partizioni, viene utilizzato gg.handler.<gg.target value>.partitioner.<fully_qualified_table_name>.

Questa proprietà può essere utilizzata con la parola chiave del modello, ad esempio ${columnValue[column_name]}, o con valori stringa costanti per definire la struttura del percorso della partizione.

Come viene calcolato il prezzo di OCI Database Migration Service? (Fattuale)

I primi 183 giorni (6 mesi) di una migrazione sono forniti gratuitamente, tranne nei casi in cui la migrazione viene eseguita per più di 60 giorni senza alcun trasferimento di dati.

Quali origini e destinazioni supporta OCI Database Migration Service? (Fattuale)

Attualmente sono supportate migrazioni omogenee di Oracle e MySQL. Le origini possono essere on-premise, su altri cloud o in OCI. Le destinazioni devono essere in OCI. Oracle è supportato da 11g (11.2.0.4), 12c (12.1.0.2,12.2.0.1),19c,21c e da tutte le release successive di Oracle Database. MySQL: 5.7 e 8 versioni. Ulteriori dettagli sono disponibili nell'URL successivo.

Quali sono i tipi di migrazione supportati da OCI Database Migration Service?

Migrazione logica offline: una copia occasionale del database richiede che le applicazioni siano offline durante il processo di migrazione. Migrazione logica online: copia iniziale del database seguita dall'acquisizione dei dati di modifica durante la migrazione. Le applicazioni possono rimanere online durante il processo di migrazione.

Durante una migrazione oracle, quali oggetti e schemi vengono esclusi per impostazione predefinita?

I tipi di oggetto riportati di seguito sono sempre esclusi.

• GoldenGate amministratori identificati in DBA_GOLDENGATE_PRIVILEGES, inclusi gli utenti ggadmin e c##ggadmin.
• Se la destinazione è Autonomous Data Warehouse Shared Infrastructure: CLUSTER, DB_LINK, INDEXTYPE, STATISTICS.
• Se la destinazione è Autonomous Data Warehouse Dedicated Infrastructure, Autonomous Transaction Processing Shared o Dedicated Infrastructure: CLUSTER, DB_LINK, STATISTICS
• Tutti gli altri obiettivi: STATISTICHE

Per impostazione predefinita, gli schemi riportati di seguito sono esclusi.

• Lo schema è contrassegnato come ORACLE_MAINTAINED in SYS.DBA_USERS nel database di origine o di destinazione
• Lo schema è contrassegnato come escluso dall'esportazione in SYS.KU_NOEXP_VIEW nel database di origine
• Schema GGADMIN e C##GGADMIN

Quali risorse OCI sono necessarie per una migrazione?

• Vault e chiave per memorizzare i segreti di connessione.
• A seconda del supporto di trasferimento selezionato Storage degli oggetti o file system
• Una connessione per origine e destinazione, alcuni scenari potrebbero richiedere più di una connessione per origine.
• Una valutazione come preparazione alla migrazione.
• La valutazione si occupa della creazione della migrazione
• Per le migrazioni online è necessaria una distribuzione OCI GoldenGate, ma questa è interamente gestita dal servizio.
• Una destinazione OCI

Dove è disponibile OCI GoldenGate?

• Oracle Cloud: OCI GoldenGate è disponibile in tutte le cloud region pubbliche, governative e dedicate in OCI. Per ulteriori informazioni, vedere https://www.oracle.com/cloud/distributed-cloud/service-availability/.
• Azure: OCI GoldenGate è disponibile su Azure su Oracle AI Database@Azure. Per ulteriori informazioni, vedere https://docs.oracle.com/en-us/iaas/Content/database-at-azure/oaa_regions.htm.
• Google Cloud: OCI GoldenGate è disponibile su Google Cloud in Oracle AI Database@Google Cloud. Per ulteriori informazioni, vedere https://docs.oracle.com/en-us/iaas/Content/database-at-gcp/get-started-regions.htm.