Häufig gestellte Fragen zu Oracle GoldenGate

Erhalten Sie Antworten auf die am häufigsten gestellten Fragen zur Oracle GoldenGate AI-Implementierung.

Warum ist Oracle GoldenGate für Unternehmens-KI wichtig?

Oracle GoldenGate ist für Unternehmens-KI von Bedeutung, da KI von aktuellen, vertrauenswürdigen Geschäftsdaten abhängt. Modelle, RAG-Systeme und KI-Agents können bei der Arbeit mit veralteten Batch-Snapshots oder unvollständigen Kopien von Betriebsdaten nicht zuverlässig argumentieren oder handeln. GoldenGate überträgt Geschäftsereignisse, während sie stattfinden, und gibt KI-Systemen Zugriff auf neue betriebliche Realität, während gleichzeitig Governance, Konsistenz und Auditierbarkeit erhalten bleiben.

Wie unterstützt Oracle GoldenGate RAG- und KI-Agents?

Oracle GoldenGate unterstützt RAG- und KI-Agents, indem es kontinuierlich Betriebsdaten in Vektordatenbanken, RAG-Pipelines, KI-Wissensdatenbanken, Lakehouses und ereignisgesteuerten Systemen bereitstellt. Mit den KI-Funktionen von GoldenGate können geänderte Datensätze als Teil der Pipeline angereichert, eingebettet, zusammengefasst, klassifiziert oder weitergeleitet werden. Daher funktionieren KI-Systeme im aktuellen Geschäftskontext und nicht in veralteten Snapshots.

Wie unterstützt GoldenGate Vektordaten?

Es kann vorhandene Vektoren replizieren, Vektoren in Oracle AI Database verschieben, Vektoränderungen streamen und während der Replikation Einbettungen generieren.

Wann sollte ich @AISERVICE verwenden?

Verwenden Sie @AISERVICE, wenn die Einbettung oder Anreicherung in einem externen AI-Service ausgeführt werden soll, wie einem verwalteten oder GPU-gestützten Endpunkt. Siehe Externe KI mit @AISERVICE einbetten

Wann sollte ich @DBFUNCTION verwenden?

Verwenden Sie @DBFUNCTION, wenn die Einbettungslogik im Rahmen der Apply-Verarbeitung in der Zieldatenbank ausgeführt werden soll. Siehe Native Datenbankeinbettung mit @DBFUNCTION

Wie sollen historische Vektorladungen behandelt werden?

Verwenden Sie Bulkinstanziierung oder datenbanknatives Laden für historische Daten, und lassen Sie GoldenGate inkrementelle Änderungen verarbeiten.

Was sind die wichtigsten Anwendungsfälle für Oracle GoldenGate?

Oracle GoldenGate wird für geschäftskritische High Availability und Disaster Recovery, Zero-Downtime-Migrationen, Echtzeitanalysen, Lakehouse-Aufnahme, ereignisgesteuerte Architekturen, KI- und RAG-Pipelines, Datenstrukturarchitekturen und gesteuerte Datensynchronisierung in Hybrid- und Multicloud-Umgebungen verwendet.

Unterstützt Oracle GoldenGate die Oracle E-Business Suite-(EBS-)Datenbankmigration und sind die Oracle-Zertifizierungsinformationen für EBS noch gültig?

Oracle EBS zertifiziert kein logisches Replikationsprodukt für Migrationen, sondern konzentriert sich auf traditionelle Datenbankmethoden (Import/Export, Oracle Data Pump).

Während GoldenGate verwendet werden kann, um einen Teil der Arbeit zu ersetzen, die diese herkömmlichen Datenbankmethoden ausführen, um die mit einer Migration verknüpfte allgemeine Ausfallzeit zu reduzieren, sollte sie nicht für alle Objekte verwendet werden.

Bjects, die nicht von GoldenGate unterstützt werden oder sich auf temporäre Arbeit beziehen, sollten während eines Stillstandzeitfensters mit herkömmlichen Methoden migriert werden.

Unterstützt die AWS-Referenzarchitektur für GoldenGate mit EFS regionsübergreifende DR-Szenarien?

Lesen Sie den AWS-Blog High Availability for Oracle GoldenGate Microservices Architecture in AWS, in dem ein regionsinternes High Availability-Design beschrieben wird.

In diesem Kontext:

• EFS-Replikationseigenschaften sind nahezu in Echtzeit innerhalb einer Region und
• Die Architektur ist für lokale Failover-Szenarios konzipiert

Bei regionsübergreifenden DR-Szenarios unterscheidet sich das Verhalten erheblich:

• Die EFS-Replikation ist asynchron (mit einem höheren RPO, z. B. Minuten), was nach dem Failover zu fehlenden Traildateien führen kann
• Datenbankpromotion über Regionen hinweg kann RESETLOGS/neue Inkarnationsgrenzen einführen

Aufgrund dieser Faktoren erstrecken sich die im AWS-Blog beschriebenen in-regionalen Designmuster nicht ohne zusätzliche Überlegungen direkt auf die regionsübergreifende DR.

Empfehlung:

Verwenden Sie bei regionsübergreifenden Architekturen eine aktive Datenverschiebung (z.B. GoldenGate-Verteilungspfad), anstatt sich auf asynchron replizierten Shared Storage für Traildateien zu verlassen.

Welche Oracle Database-Versionen werden von GoldenGate unterstützt?

• GoldenGate 19c und 21c unterstützen Oracle-Datenbanken von 11.2.0.4 bis 21c
• GoldenGate 26ai unterstützt Oracle-Datenbanken von 19c bis 26ai+

Weitere Informationen finden Sie unter https://www.oracle.com/integration/goldengate/certifications/.

Welche verschiedenen Typen von GoldenGate-Konfigurationen und -Anwendungsfällen gibt es?

• Unidirektional: Daten fließen in eine Richtung von Quelle zu Ziel.
• Bidirektional: Daten fließen in beide Richtungen zwischen Quelle und Ziel.
• Multidirektional: Datenflüsse zwischen mehreren Quellen und Zielen.
• Echtzeit-Data Warehousing: Halten Sie Ihr Data Warehouse mit Live-Transaktionsdaten auf dem neuesten Stand.
• Disaster Recovery: Verwalten Sie eine synchronisierte Kopie Ihrer Datenbank zu Failover-Zwecken.
• Migrationen ohne Ausfallzeiten: Verschieben Sie Datenbanken auf neue Plattformen oder Versionen mit minimaler Unterbrechung.
• Anwendungsintegration: Teilen Sie Daten zwischen verschiedenen Anwendungen in Echtzeit.
• Kaskadieren: Anstelle der direkten Quell-zu-Ziel-Replikation werden Änderungen zuerst in einer GoldenGate-Zwischeninstanz (oder mehreren Instanzen) repliziert, die dann die Änderungen nachgelagert propagiert.
• Verteilung: Als Eins-zu-Viele-Topologie bezeichnet, handelt es sich um ein Architektur- und Designmuster, das zum Verschieben von Daten über mehrere Datenbanken, Cloud-Umgebungen und Nachrichtenwarteschlangen in Echtzeit verwendet wird.
• Konsolidierung: Es ermöglicht Unternehmen, Daten aus mehreren Quellen in einem einzigen Repository zu zentralisieren, das auch als ODS (Operation Data Store) bezeichnet wird. Dies ist eine integrierte Echtzeitdatenbank, die Daten aus mehreren Transaktionssystemen konsolidiert, um betriebliches Reporting und Entscheidungsfindung zu unterstützen.
• Echtzeitnachrichten-Streaming: Mit GoldenGate können Benutzer Nachrichten in OCI Streaming, Apache Kafka, Confluent und anderen GoldenGate-zertifizierten Kafka-basierten Nachrichten-Streaming-Plattformen veröffentlichen.
• Echtzeit-Data Lakes: Echtzeitreplikation auf Cloud-Speicherservices (OCI Object Storage, ADLS, Amazon S3, Google Cloud Storage) in verschiedenen Formaten, einschließlich JSON, ORC, Parquet und mehr.
• MongoDB-Migrationen ohne Ausfallzeiten: GoldenGate unterstützt Migrationen ohne Ausfallzeiten von MongoDB zu Oracle AI Database, mit denen Kunden ihre Migrationen ohne Geschäftsunterbrechung ausführen können.
• Cloud Warehouse-Aufnahmen: Mit GoldenGate können Benutzer große Datenmengen an Cloud-native Data Warehouse- und Lake-House-Services wie Autonomous Database, Snowflake, Databricks und mehr übermitteln.
• Datenstreams mit AsyncAPI-Standards: Mit GoldenGate können Entwickler problemlos GoldenGate-Datenstreams abonnieren, um ihre Anwendungen direkt in GoldenGate zu integrieren, indem sie JSON-Format in ihre Anwendungen erhalten.

Was sind die Schlüsselkomponenten von GoldenGate?

• Traildateien: Die Dateien, die Änderungen erfasst haben, werden gespeichert.
• Extract: Erfasst Änderungen aus den Redo-/Transaktionslogs der Quelldatenbank und schreibt in die Traildatei.
• Verteilungspfad: Liest aus der Traildatei und weiteren Prozessen in das Zielsystem, in dem Replicat liest und auf die Datenbank oder das Ziel BigData angewendet wird.
• Replicat: Wendet die erfassten Änderungen auf die Zieldatenbank an.

Was ist Oracle GoldenGate und was sind die wichtigsten Anwendungsfälle?

Oracle GoldenGate ist eine Datenintegrations- und -replikationslösung, mit der Transaktionsänderungen über mehrere heterogene Systeme hinweg in Echtzeit erfasst, transformiert und bereitgestellt werden.

Die wichtigsten Anwendungsfälle für Oracle GoldenGate sind:

• Datenbankmigrationen ohne Ausfallzeiten und Rollback-Szenarien
• Echtzeitanalysen und -berichte
• Disaster Recovery und High Availability
• Aktive/aktive Multi-Master-Regionen/Data-Center
• Datenintegration über On-Premise- und Cloud-Plattformen hinweg
• Nachrichten-Streaming in Echtzeit
• Seehäuser in Echtzeit
• Migrationen ohne Ausfallzeiten MongoDB
• Cloud Warehouse-Aufnahmen
• Datenstreams mit AsyncAPI-Standards

Welche Datenbanken und Plattformen werden von Oracle GoldenGate unterstützt?

Oracle GoldenGate unterstützt eine Vielzahl von Datenbanken und Zielen, darunter:

• Oracle AI Database
• MySQL
• PostgreSQL
• SQL Server
• Db2 LUW, Db2 z/OS, Db2 für i
• Amazon RDS, Aurora, Google GCP, Azure-Datenbank
• Big Data-Plattformen wie Kafka und Hadoop
• Snowflake
• Apache Iceberg
• Verschiedene Formate wie JSON, Parquet, Avro, Text mit Trennzeichen usw.
• NoSQL-Datenspeicher wie MongoDB, Cassandra usw.
• Nachrichten-Streaming-Plattformen wie Apache Kafka, Azure Event Hubs, Confluent usw.

Oracle GoldenGate kann von Oracle Fusion SaaS- und OTM SaaS-Anwendungen erfasst werden, die in OCI ausgeführt werden.

Oracle GoldenGate kann nicht aus Salesforce.com/SFDC erfassen.

Oracle GoldenGate kann Änderungen in Teradata und TimesTen replizieren, jedoch nicht aus beiden erfassen.

Es wird empfohlen, die GoldenGate-Zertifizierungsmetriken für bestimmte Datenbank- und Zielunterstützung zu prüfen. Weitere Informationen finden Sie unter https://www.oracle.com/integration/goldengate/certifications/.

Was sind die Unterschiede zwischen Oracle GoldenGate Classic Architecture und Microservices Architecture?

• Klassische Architektur: Älteres, monolithisches Modell mit GGSCI für die Verwaltung. In 26ai nicht unterstützt.
• Microservices Architecture (MA): Modernes, REST-basiertes modulares Design mit individuellen Services (z.B. Service Manager, Admin-Service). MA bietet bessere Skalierbarkeit, Sicherheit und Benutzerfreundlichkeit.

Weitere Informationen zu MA finden Sie unter Oracle GoldenGate Microservices Architecture.

Wie wird Oracle GoldenGate mit anderen Replikationstools verglichen?

Oracle GoldenGate ist aus folgenden Gründen ideal für Datenintegration, Datenbankreplikation, Datenverschiebung, Datenbankmigrationen und Datenaufnahme in Echtzeit:

• Es unterstützt fettgedruckten Text mit Hunderten von Quellen und Zielen (https://www.oracle.com/integration/goldengate/certifications/)

• Es hat eine unglaubliche Support-Community über viele verschiedene Kanäle, einschließlich
  • 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 gilt als Goldstandard bei der Datenbankreplikation. Alle Wettbewerber streben danach, mehr wie GoldenGate zu sein und die vielen Funktionen zu unterstützen, die es unterstützt.

• GoldenGate bietet viele einzigartige Vorteile, einschließlich der Möglichkeit, Abonnements für seine Traildateien zu erstellen. Weitere Informationen zu einem vollständig verwalteten Service in OCI GoldenGate, der in OCI-, Google Cloud- und Azure-Hyperscalern verfügbar ist, finden Sie unter Info zu Datenstreams, Aktiv-Aktive Replikation und Streaminganalysen.

• GoldenGate ist genauso geschäftskritisch wie die von ihm replizierten Datenbanken. Es gibt zahlreiche Topologien, mit denen Disaster Recovery und High Availability für GoldenGate selbst bereitgestellt werden können, einschließlich vollständiger Automatisierung mit Disaster-Recovery-Lösungen für Datenbanken. https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/maa-platinum-and-oracle-goldengate-best-practices.html

• Weitere Gründe, warum GoldenGate die beste ist, finden Sie hier: https://www.oracle.com/a/ocom/docs/techpaper-goldengate-advantages.pdf.

Welche Voraussetzungen sind für die Installation von Oracle GoldenGate in Datenbank XYZ erforderlich?

Plattform & Kompatibilität

• Unterstützte GoldenGate Microservices-Version
• Unterstützte Datenbankversionen (Quelle und Ziel)
• Unterstütztes Betriebssystem (Linux empfohlen)
• 64-Bit-Betriebssystem und Datenbank

Deployment-Modell

• Definierter Deployment-Typ (Einzel- oder Mehrknoten)
• Deployment-Ziel (VM, Bare Metal oder Kubernetes)
• Alle geplanten Microservices-Komponenten (Admin, Distribution, Receiver usw.)

Datenbankkonfiguration

• Datenbank im ARCHIVELOG-/Transaktionsloggingmodus
• Zusätzliches Logging aktivieren
• GoldenGate-Datenbankbenutzer mit erforderlichen Berechtigungen
• Angemessene Aufbewahrung von Redo-/Transaktionslogs
• Primärschlüssel oder eindeutige IDs in Tabellen

Infrastruktur- und Systemressourcen

• Ausreichend CPU und Speicher für Extract, Replicat und Services
• Ausreichend Speicherplatz für Traildateien, Checkpoints und Logs
• Hohe I/O-Performance für Traildateispeicher

Speicher

• Dediziertes Dateisystem für Deployment, Trails und Logs
• Shared Storage, wenn HA erforderlich ist (z.B. ACFS oder Cloud-Filestore)
• Strategie für die Bereinigung und Aufbewahrung von Traildateien

Netzwerk und Ports

• Zuverlässige Netzwerkkonnektivität zwischen Systemen
• Erforderliche Ports für Admin Server, Distribution und Receiver geöffnet
• Richtige Hostnamenauflösung (DNS- oder Hosts-Datei)
• Geringe Latenz für Echtzeitreplikation

Betriebssystem und Benutzer einrichten

• Dedizierter Betriebssystembenutzer (z.B. ogg)
• Korrekte Berechtigungen für alle Verzeichnisse
• Erforderliche Umgebungsvariablen konfiguriert
• Konfigurierte BS-Grenzwerte (Limits für Dateien/Prozesse)

Datenbank-Konnektivität

• Verbindungszeichenfolgen / TNS / Endpunkte konfiguriert
• Konnektivität erfolgreich getestet

Microservices-spezifische Anforderungen

• Deployment verwaltet über Service Manager
• Zugangsdatenspeicher konfiguriert
• HTTPS-Konfiguration (empfohlen)
• Optionaler Reverse Proxy oder Load Balancer
• Browserzugriff für Admin-UI

Sicherheit

• Sicherer Zugangsdatenspeicher
• TLS/SSL-Konfiguration (falls erforderlich)
• Firewallregeln, die auf Serviceports ausgerichtet sind
• Rollenbasierter Zugriff für die Verwaltung

High Availability (optional)

• Deployment-Design mit mehreren Knoten
• Gemeinsame oder replizierte Konfiguration
• Load Balancer für Services
• Definierte Failover-Strategie

Einsatzbereitschaft

• Zeitsynchronisation (NTP)
• Setup für Überwachung und Alerts
• Logmanagementansatz
• Backup vor Aktivierung der Replikation
• Kapazitätsplanung für Auslastung

Weitere Informationen zum Vorbereiten von Datenbanken für Oracle GoldenGate finden Sie unter Datenbanken vorbereiten.

Was sind die Unterschiede zwischen sicheren und unsicheren Bereitstellungen?

• Sichere Bereitstellung: Verwendet TLS/SSL für die verschlüsselte Kommunikation, OAuth für die Authentifizierung und stellt End-to-End-Sicherheit sicher. Weitere Informationen zu sicheren Deployments finden Sie unter Sichere Deployments.
• Non-Secure Deployment: Basiert auf Klartext-HTTP/unverschlüsselter Kommunikation. Nur für interne/Testumgebungen empfohlen.

Wie konfiguriere ich Oracle GoldenGate-Microservices mit OGGCA?

• Führen Sie oggca.sh (Linux) oder oggca.bat (Windows) aus.
• Konfigurieren Sie Service Manager und Deployment, und geben Sie bei Bedarf Ports, Pfade und Zertifikate an.
• oggca.sh kann auch im Silent-Modus ausgeführt werden, indem eine Antwortdatei angegeben wird.

Weitere Informationen finden Sie unter Deployment hinzufügen und Deployment im Silent-Modus mit OGGCA hinzufügen.

Was sind die Best Practices zur Optimierung der Oracle GoldenGate-Performance?

Bei modernen Oracle GoldenGate-Deployments wird empfohlen, Integrated Extract zusammen mit Parallel Replicat zu verwenden, da Parallel Replicat jetzt die strategische und bevorzugte Replikationsmethode für leistungsstarke Ziel-Apply-Vorgänge ist.

Das integrierte Replicat wird zugunsten von Parallel Replicat schrittweise eingestellt, da Paralleles Replicat eine bessere Skalierbarkeit, eine verbesserte Transaktionsanwendungsperformance und eine effizientere parallele Verarbeitung für große Unternehmens-Workloads bietet.

Eine gut optimierte GoldenGate-Architektur sollte Capture-, Transport- und Apply-Phasen trennen, indem lokale und Remotetraildateien verwendet werden. Dadurch wird die Resilienz verbessert und die Replikation von Netzwerkunterbrechungen isoliert. Die Performance hängt auch stark von der zugrunde liegenden Infrastruktur ab, einschließlich schnellem Speicher, ordnungsgemäßem Datenbankspeicher, effizienter Redo-Logkonfiguration und stabiler Netzwerkkonnektivität.

Die kontinuierliche Überwachung von Extract-Lag, Replicat-Lag, Durchsatz und Checkpoint-Aktivitäten ist unerlässlich, um Engpässe proaktiv zu identifizieren, bevor sie sich auf die Replikationslatenz auswirken.

Im Allgemeinen wird die beste GoldenGate-Performance durch eine Kombination aus skalierbarem Architekturdesign, korrekter Workload-Verteilung, Datenbankoptimierung und sorgfältig verwalteter Parallelität erreicht, sodass Unternehmen auch bei großen Transaktions-Workloads eine geringe Latenz und zuverlässige Replikation aufrechterhalten können.

Wie kann ich Verzögerungen überwachen und Performanceprobleme beheben?

• Performance Metrics Service in MA verwenden
• Lag- und Statusbefehle in Admin-Client und REST-API verwenden
• Prüfen Sie auf Engpässe wie Netzwerklatenz oder Datenträger-I/O.
• Taktüberwachungstabelle aktivieren
• Benutzer GoldenGate OEM-Plug-in
• Metriken mit StatsD exportieren
• Zeigen Sie den aktuellen Status in WebUI an

Mit welchen Tools oder Befehlen kann ich Oracle GoldenGate-Prozesse überwachen?

In Oracle GoldenGate Microservices Architecture wird das Monitoring hauptsächlich über den webbasierten Administrationsservice, REST-APIs und den Performancemetrikservice und nicht über herkömmliche klassische Architekturtools wie GGSCI durchgeführt. Der Administrationsservice bietet zentrale Dashboards, mit denen Administratoren den Zustand und Status von Extract-, Distribution-, Receiver- und Parallel Replicat-Prozessen in Echtzeit überwachen können. Über die Weboberfläche können Benutzer Replikationsverzögerungen, Checkpointfortschritt, Durchsatzraten, Pfadstatus und Prozessperformance im gesamten Deployment verfolgen. REST-APIs bieten außerdem programmgesteuerten Zugriff auf Überwachungsdaten und ermöglichen die Integration mit Automatisierungs-Frameworks und Enterprise Observability-Plattformen.

Eine wichtige Überwachungskomponente in der Microservices-Architektur ist der Performance Metrics Service (PMSRVR), der operative Metriken für Replikationsprozesse und Verteilungspfade sammelt und bereitstellt. Diese Metriken können in Überwachungslösungen wie Oracle Enterprise Manager, OCI Monitoring, Prometheus und Grafana integriert werden, um zentralisierte Dashboards, Warnmeldungen und langfristige Performanceanalysen bereitzustellen. Administratoren verlassen sich außerdem auf Deployment-Logs, Berichtsdateien und Diagnoseinformationen, die über die Service Manager- und Administration Service-Schnittstellen verfügbar sind, um Fehler zu beheben, das Prozessverhalten zu überwachen und Latenzprobleme zu untersuchen.

Für OCI GoldenGate-Deployments sind zusätzliche Überwachungsfunktionen über die OCI-Konsole, OCI Logging, OCI Monitoring und OCI-Alarme verfügbar. So erhalten Sie einen cloudnativen Einblick in den Deployment-Zustand, das Skalierungsverhalten, die Replikationsverzögerung und Betriebsereignisse. Insgesamt konzentriert sich das Monitoring in der GoldenGate Microservices-Architektur auf zentralisierte Beobachtbarkeit, API-gesteuertes Management und die Integration mit Unternehmensüberwachungsplattformen, um Echtzeiteinblicke in die Replikationsleistung und den Systemzustand zu erhalten.

Benutzer können ihre eigenen Dashboards erstellen und die Anwendung überwachen, indem sie auf StatsD-Exporte und API-Aufrufe zugreifen.

Was sind Traildateien, und wie werden sie von Oracle GoldenGate bei der Replikation verwendet?

Traildateien speichern Datenänderungen, die vom Extract-Prozess erfasst wurden, in einem plattformunabhängigen Format.

• Sie fungieren als Vermittler zwischen Extract- und Replicat-Prozessen.

• Geben Sie Fehlertoleranz an, indem Sie die Wiedergabe erfasster Änderungen zulassen.

• Die Extract- und Replicat-Komponente wird entkoppelt, um mehr Flexibilität bei GoldenGate-Architekturen zu ermöglichen, wie z. B. 1 bis viele für die Datenverteilung und die kaskadierende Replikation. Außerdem wird die plattformübergreifende Replikation effizienter.

• Es handelt sich um ein proprietäres Binärformat, das vom Logdump-Utility interpretiert werden kann, das normalerweise bei der Fehlerbehebung benötigt wird. Weitere Informationen finden Sie in der Logdump-Referenz.

• Für Benutzer, die Daten direkt aus der Traildatei GoldenGate konsumieren möchten, ist es die beste Option, GoldenGate Data Streams zu verwenden, mit der der Benutzer abonnieren können. in einen Kanal, der von GoldenGate Data Streams verwaltet wird, indem aus den Traildateien GoldenGate gelesen und jeder Datensatz aus der Traildatei als Ereignis in diesen Kanal eingefügt wird.

Was ist der am besten empfohlene Replicat-Typ?

Beginnen Sie mit Parallel Replicat: In den meisten Anwendungsfällen, insbesondere bei Transaktions-Workloads mit hohem Volumen, bietet Parallel Non-Integrated Replicat die beste Performance und Flexibilität.

GoldenGate Verteilte Anwendungen und Analysen unterstützen Classic und Coordinated Replicat.

Für GoldenGate für verteilte Anwendungen und Analysen bietet Coordinated Replicat je nach Ziel eine bessere Performance.

Wie richte ich TLS/SSL für die sichere Datenreplikation ein?

• Oracle GoldenGate unterstützt die TLS/SSL-Verschlüsselung sowohl in der Datenspeicherverbindung als auch im Verteilungspfad zwischen GoldenGate-Deployments.

• Bei Verteilungspfaden mit TLS/SSL werden die Zertifikate über den Endpunkt RestAPI des Service Managers verwaltet. Die Verwendung kann auch die Zertifikatsverwaltungsaufgabe über WebUI des Service Managers ausführen.

• Der Verteilungspfad kann unter "Verteilungsservice" oder "Empfängerdienst" (Ziel-initiierter Pfad) erstellt werden.

• Parameterdateien mit ENCRYPTION-Anweisungen aktualisieren

• Um den Distributionspfad mit TLS/SSL zu sichern, muss das Deployment entweder als "ungesichertes Deployment + NGINX" oder "gesichertes Deployment" eingerichtet werden. Weitere Informationen finden Sie unter Sichere Daten in Transit und So konvertieren Sie nicht sicheres Deployment in sicheres Deployment mit SSL/TLS.

  • Wenn Sie NGINX verwenden, wird die TLS bei NGINX beendet. Nur der NGINX-Listening-Port muss eingehenden Datenverkehr ausgesetzt werden.
  • Wenn Sie ein gesichertes Deployment verwenden, müssen alle Listening-Ports der GoldenGate-Services eingehenden Traffic ausgesetzt werden. Die TLS wird an den Serviceports beendet.

Welche Optionen gibt es zum Verschlüsseln von Traildateien?

• Oracle GoldenGate unterstützt derzeit die folgenden drei Verschlüsselungsmethoden: Bei der Kommunikation mit Oracle GoldenGate, die auf HP NSK ausgeführt wird, wird auch die ENCKEYS-Methode unterstützt. Dies wird jedoch dringend empfohlen, wenn kein HP NSK-Build beteiligt ist. Alle oben genannten Methoden unterstützen den AES-Verschlüsselungsalgorithmus.
  • Masterverschlüsselungsschlüssel im Wallet verwenden
  • Oracle OKV für On-Premise-Vault
  • OCI KMS für Vault-Service
• Konfigurieren Sie die Verschlüsselung über den Parameter ENCRYPTTRAIL.

Weitere Informationen zum Sichern von Daten finden Sie unter Sichere Daten im Ruhezustand in der Dokumentation zu Oracle GoldenGate Microservices.

Wie kann ich Oracle GoldenGate mit externen Identitätsprovidern (z.B. IAM, OAM) für die eigene GoldenGate-Authentifizierung integrieren?

• Oracle GoldenGate Microservices Architecture unterstützt die Integration mit externen Identitätsprovidern wie Oracle Identity and Access Management (IAM), Oracle Access Manager (OAM) und Azure Entra ID, um eine zentralisierte Authentifizierung, Single Sign-On (SSO) und rollenbasierte Zugriffskontrolle für GoldenGate-Administrations- und -Überwachungsservices bereitzustellen. Diese Integration ist besonders wichtig in Unternehmens- und Cloud-Umgebungen, in denen eine zentralisierte Identity Governance, Sicherheitscompliance und föderierte Authentifizierung erforderlich sind.

• In der GoldenGate Microservices-Architektur wird die Authentifizierung über den Service Manager und Administration Services verwaltet, die je nach Deployment-Modell und Providerfunktionen die Integration mit Enterprise-Identitätsprovidern unterstützen, indem Standards wie OAuth 2.0, OpenID Connect (OIDC), SAML und LDAP-basierte Authentifizierung verwendet werden. Bei OCI GoldenGate-Deployments wird die Integration häufig über Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) durchgeführt. Dadurch können Administratoren zentralisierte OCI-Benutzer, -Gruppen, -Policys und -Föderationsservices für den sicheren Zugriff auf GoldenGate-Deployments und REST-APIs verwenden.

• Bei der Integration mit Oracle Access Manager-(OAM-) oder Enterprise SSO-Lösungen wird GoldenGate in der Regel hinter einem Reverse Proxy oder Webgateway konfiguriert, der die Authentifizierung und Tokenvalidierung verarbeitet. Nach erfolgreicher Authentifizierung werden Informationen zur Benutzeridentität und Autorisierung an GoldenGate-Services weitergeleitet. Dieser Ansatz ermöglicht zentralisierte Anmelde-Policys, MFA-Durchsetzung, Sessionmanagement und Corporate Identity Federation, ohne dass separate GoldenGate-spezifische Zugangsdaten erforderlich sind.

• Bei Azure Entra ID-Integrationen kann GoldenGate externe Directory-Services verwenden, die von Entra ID für die Benutzerauthentifizierung und Rollenzuordnung bereitgestellt werden. So können Organisationen den administrativen Zugriff über vorhandene Unternehmensbenutzergruppen und Sicherheits-Policys verwalten. Rollenbasierte Zugriffskontrolle kann dann angewendet werden, um Berechtigungen für Administration, Deployment-Verwaltung, Monitoring und API-Zugriff innerhalb der GoldenGate-Umgebung zu kontrollieren.

• GoldenGate-REST-APIs können auch mithilfe von Unternehmensauthentifizierungsmechanismen gesichert werden, sodass externe Automatisierungsplattformen, CI/CD-Pipelines und Überwachungstools mit zentralisierten Identitätstoken und nicht mit lokalen Serviceaccounts authentifiziert werden können. In Cloud-nativen und hybriden Bereitstellungen verbessert diese Integration die Sicherheitskonsistenz auf allen Unternehmensplattformen und vereinfacht gleichzeitig das Benutzerlebenszyklusmanagement und die Auditcompliance.

• Insgesamt ermöglicht die Integration von Oracle GoldenGate in externe Identitätsprovider eine zentralisierte Authentifizierung, SSO, föderiertes Identitätsmanagement und unternehmensgerechte Sicherheitskontrollen, sodass GoldenGate-Deployments einfacher in großen Unternehmens- und OCI-Umgebungen gesichert und verwaltet werden können.

• Jeder ID-Provider hat eine etwas andere Implementierung auf dem Endpunkt für die Tokenanforderung, selbst bei OIDC- und OAuth 2.0-Standards. GoldenGate muss ein bestimmtes Profil für diesen ID-Provider erstellen, um eine Integration mit GoldenGate vorzunehmen. Wenn Ihr ID-Provider nicht in der unterstützten Liste enthalten ist, können Sie eine Verbesserungsanforderung erstellen.

Wie migriere ich Datenbanken ohne Ausfallzeiten mit Oracle GoldenGate?

Oracle GoldenGate ermöglicht Datenbankmigrationen nahezu ohne Ausfallzeiten, indem Transaktionsänderungen kontinuierlich von der Quelldatenbank in die Zieldatenbank repliziert werden, während beide Systeme online bleiben. Anstatt ein langes Ausfallfenster für Export-, Import- und Cutover-Aktivitäten zu benötigen, können Unternehmen mit GoldenGate Daten in Echtzeit synchronisieren, sodass der endgültige Migrations-Cutover mit minimaler Anwendungsunterbrechung abgeschlossen werden kann.

In einer typischen Zero-Downtime-Migrationsarchitektur erfasst GoldenGate Änderungen aus der Quelldatenbank mit Integrated Extract und schreibt sie in Traildateien. Die Änderungen werden dann über Distribution Services übertragen und mit Parallel Replicat auf die Zieldatenbank angewendet. Während der anfängliche Dataload über Backup/Restore, Data Pump, RMAN-Duplizierung oder andere Bulk Load-Methoden migriert wird, repliziert GoldenGate fortlaufend laufende Transaktionen, sodass das Ziel während des gesamten Migrationsprozesses mit der Quelle synchronisiert bleibt.

Der Migrationsworkflow folgt in der Regel mehreren Phasen:

• Vorbereitung und Umgebungseinrichtung
• Erstmaliges Dataload
• kontinuierliche Änderungsreplikation
• Validierung und Synchronisierung
• kontrollierte Cutover

Während der anfänglichen Ladephase wird eine vollständige Kopie der Datenbank an die Zielumgebung übertragen. Nachdem die Basisplandaten geladen wurden, wendet GoldenGate alle laufenden Transaktionsänderungen an, die aus der Quelldatenbank erfasst wurden. Diese kontinuierliche Replikation reduziert das Ausfallfenster erheblich, da die Zieldatenbank bereits vor dem Cutover nahezu synchronisiert ist.

Die Datenvalidierung ist ein wichtiger Bestandteil von Migrationen ohne Ausfallzeiten. Oracle GoldenGate Veridata wird häufig verwendet, um Quell- und Zieldatenbanken während der Replikation zu vergleichen, um die Datenkonsistenz vor dem Produktions-Switchover sicherzustellen. Durch die kontinuierliche Validierung können Abweichungen frühzeitig erkannt und das Migrationsrisiko reduziert werden.

Zur Cutover-Zeit wird die Anwendungsaktivität kurz angehalten, die verbleibenden Transaktionen können repliziert werden, und Administratoren prüfen, ob die Replikationsverzögerung null erreicht. Nachdem die Synchronisierung bestätigt wurde, werden Anwendungen zur Zieldatenbank umgeleitet, und die Zielumgebung wird zum neuen Produktionssystem. Da die meisten Daten verschoben wurden, während Systeme online waren, wird das tatsächliche Ausfallfenster in der Regel nur auf den endgültigen Synchronisierungs- und Anwendungsumleitungsprozess reduziert.

GoldenGate unterstützt Migrationen ohne Ausfallzeiten über:

• Oracle-zu-Oracle-Migration
• Versionsübergreifende Upgrades
• Plattformmigrationen
• Migrationen von On-Premises zu OCI
• heterogene Datenbankmigrationen
• Multicloud- und Hybrid-Cloud-Übergänge

In modernen GoldenGate Microservices-Architektur- und OCI GoldenGate-Deployments wird das Migrationsmanagement durch zentralisierte Webschnittstellen, REST-APIs, automatisierte Deployment-Services und integrierte Überwachungsfunktionen weiter vereinfacht. Parallele Replicat-, integrierte Capture- und skalierbare Distributionsservices helfen bei der effizienten Verarbeitung großer Transaktions-Workloads während der Migrationsaktivitäten.

Insgesamt ermöglicht Oracle GoldenGate Migrationen ohne Ausfallzeiten, indem kontinuierliche Echtzeitreplikation, skalierbare parallele Verarbeitung, kontinuierliche Validierung und kontrollierte Cutover-Prozeduren kombiniert werden. So können Unternehmen kritische Datenbanken mit minimaler Geschäftsunterbrechung und reduziertem Betriebsrisiko migrieren.

Was sind die Best Practices für die Konfiguration der bidirektionalen Replikation?

Best Practices für die Konfiguration der bidirektionalen Replikation mit Oracle GoldenGate umfassen:

• Definieren Sie eine klare Active/Active-Replikationsarchitektur und Dateneigentumsregeln.
• Vermeiden Sie Aktualisierungskonflikte, indem Sie sicherstellen, dass dieselben Daten nach Möglichkeit nicht gleichzeitig auf beiden Systemen geändert werden.
• Konfigurieren Sie CDR-(Conflict Detection and Resolution-)Policys entsprechend.
• Verwenden Sie Primärschlüssel oder eindeutige Schlüssel für alle replizierten Tabellen.
• Stellen Sie sicher, dass sowohl Quell- als auch Zieltabellen identische Strukturen und kompatible Datentypen aufweisen.
• Schließen Sie unnötige Tabellen, temporäre Objekte und nicht unterstützte Vorgänge aus der Replikation aus.
• Verwenden Sie Schleifenverhütungsmechanismen, um zu vermeiden, dass replizierte Transaktionen an das ursprüngliche System zurückgesendet werden.
• Verwalten Sie synchronisierte Datenbankzeichensätze, Zeitzonen und Schemadefinitionen.
• Überwachen Sie kontinuierlich Replikationsverzögerungen, Prozesszustand und Konfliktereignisse.
• Testen Sie Failover-, Switchover- und Recovery-Prozeduren regelmäßig.
• Konfigurieren Sie das richtige Checkpointing und Trail-Management.
• Trennen Sie Workloads und die Größe der Infrastruktur entsprechend für aktiv-aktiven Traffic.
• Verwenden Sie zusätzliches Logging und korrekte Transaktionsloggingkonfigurationen.
• Implementieren Sie umfassende Überwachungs-, Warnungs- und Auditingpraktiken.
• Validieren Sie die Datenkonsistenz regelmäßig mit Tools wie Oracle GoldenGate Veridata.
• Planen Sie die DDL-Replikation und Schemaänderungen sorgfältig.
• Dokumentieren Sie die Regeln zur Konfliktbehandlung und die operativen Verfahren klar.

Bidirektionale Replikationsumgebungen erfordern eine sorgfältige Planung, da sie komplexer sind als die unidirektionale Replikation und Herausforderungen wie:

• Aktualisierungskonflikte
• Replikationsschleifen
• Datendivergenz
• Latenzsensibilität
• und operative Komplexität.

Was bedeutet es, wenn Replicat "hängende" Transaktionen anzeigt und wie kann ich sie beheben?

Wenn Replicat "hängende" Transaktionen anzeigt, bedeutet dies normalerweise, dass der Replicat-Prozess eine oder mehrere Transaktionen nicht auf die Zieldatenbank anwenden kann und der Replikationsfortschritt gestoppt wird oder verzögert wird.

Häufige Ursachen sind:

• Datenbanksperren oder blockieren von Sessions auf dem Ziel
• Fehlende oder widersprüchliche Datensätze
• Constraint-Verletzungen
• Duplikatschlüsselfehler
• nicht unterstützte Vorgänge
• Transaktionen mit langer Ausführungszeit
• Datentyp-Unstimmigkeiten
• Netzwerk- oder Konnektivitätsprobleme
• Nicht genügend Systemressourcen

Typische Schritte zur Fehlerbehebung sind:

• Prüfen Sie die Replicat-Berichtsdatei, und verwerfen Sie die Datei auf Fehler
• Prüfen Sie die GoldenGate-Fehlerlogs
• die Transaktion oder Tabelle identifizieren, die den Blockierungsvorgang verursacht
• Verfügbarkeit und Zustand der Zieldatenbank prüfen
• Auf gesperrte Objekte oder blockierende Sessions prüfen
• Datenkonflikte oder Constraint-Probleme lösen
• Prüfen, ob Traildateien zugänglich und intakt sind
• Checkpoint-Status prüfen
• Replicat neu starten, nachdem das Problem gegebenenfalls behoben wurde

In einigen Fällen müssen Administratoren möglicherweise:

• problematische Transaktionen überspringen,
• Replicat neu positionieren,
• oder betroffene Tabellen neu synchronisieren

je nach Fall, Schweregrad und Geschäftsanforderungen.

Wie verwalte ich Plattenspeicherplatz und lösche alte Traildateien in Microservices?

In der Oracle GoldenGate-Microservices-Architektur sind die Verwaltung des Festplattenspeichers und das Löschen von Traildateien wichtig, um eine Erschöpfung des Speichers zu verhindern und fehlerfreie Replikationsumgebungen aufrechtzuerhalten.

Traildateien werden in der Regel mit automatisierten Lösch-Policys verwaltet, die alte Traildateien entfernen, nachdem sie von Downstream-Prozessen nicht mehr benötigt werden.

Zu den gängigen Übungen gehören:

• Automatisches Löschen von Traildateien konfigurieren
• Datenträgerauslastung regelmäßig überwachen
• Trailspeicher vom Betriebssystemspeicher trennen
• Verwenden dedizierter Dateisysteme oder Volumes
• Aufbewahrungs-Policys basierend auf Recovery-Anforderungen festlegen

Traildateien können in der Regel gelöscht werden, wenn:

• Alle Extract- und Replicat-Prozesse haben sie verarbeitet
• Checkpoints wurden über die Dateien hinaus erweitert
• Dateien sind nicht für Recovery oder Resynchronisierung vorgesehen

In Microservices wird das Trail-Management in der Regel über Folgendes abgewickelt:

• der Administrationsserver
• Verteilungsservice
• Empfangsservice
• Befehlszeilen-Administrationstools
• oder REST-APIs

Weitere Empfehlungen sind:

• Festplattenspeicherüberwachung und Alerts aktivieren
• Trails archivieren, falls für Auditing erforderlich
• Verwendung von externem Speicher für lange Aufbewahrungszeiträume
• regelmäßige Überprüfung von Lösch-Policys und Speicherwachstumstrends

Die richtige Trail-Verwaltung hilft, Folgendes zu vermeiden:

• Replikationsstopps
• Datenträger mit vollständigen Bedingungen
• Performanceverminderung
• Genesungskomplikationen.

Wie konfiguriere ich den automatischen Start und Neustart in Microservices?

In Oracle GoldenGate Microservices Architecture kann der automatische Start und automatische Neustart so konfiguriert werden, dass Deployment-Services und Replikationsprozesse nach Fehlern oder Serverneustarts automatisch gestartet und wiederhergestellt werden.

Dies wird in der Regel wie folgt konfiguriert:

• Automatische Startprofile für Extract- und Replicat-Prozesse aktivieren
• Policys für den automatischen Neustart mit Wiederholungsintervallen und Wiederholungsanzahl aktivieren
• Service Manager-Startverhalten konfigurieren
• Integration des Deployments in Betriebssystemservices oder Container-Orchestrierungsplattformen

Die Einstellungen für den automatischen Neustart gewährleisten eine hohe Verfügbarkeit, indem nicht erfolgreiche Prozesse ohne manuelle Eingriffe automatisch neu gestartet werden.

Zu den allgemeinen Konfigurationsoptionen zählen:

• Startverzögerung
• Wiederholungsanzahl
• retry interval
• Abhängigkeitsreihenfolge
• Fehlerschwellenwerte

Diese Einstellungen können in der Regel folgendermaßen verwaltet werden:

• die GoldenGate Microservices-Webbenutzeroberfläche
• REST-APIs
• oder Befehlszeilen-Administrationstools

Automatischer Start und Neustart werden häufig verwendet in:

• HA-Produktionsumgebungen
• Cloud-Bereitstellungen
• Container-Umgebungen
• Disaster Recovery-Architekturen
• unbeaufsichtigte Replikationssysteme.

Was sind die Schritte zur Fehlerbehebung bei Replikationsverzögerungen?

Häufige Schritte zur Fehlerbehebung bei der Oracle GoldenGate-Replikationsverzögerung:

• Prüfen Sie den Lag-Status mit GoldenGate-Überwachungsbefehlen oder -Dashboards.
• Prüfen Sie, ob die Extract-, Pump- oder Replicat-Prozesse normal ausgeführt werden.
• Prüfen Sie die GoldenGate-Berichtsdateien und Fehlerlogs auf Warnungen oder Fehler.
• Prüfen Sie, dass Transaktionen mit langer Ausführungszeit in der Quelldatenbank vorliegen.
• Überwachen der Netzwerklatenz und -bandbreite zwischen Quell- und Zielsystemen.
• Prüfen Sie, ob Traildateien korrekt generiert und konsumiert werden.
• Prüfen Sie die CPU-, Speicher-, Datenträger-I/O- und Speicherauslastung auf Quell- und Zielservern.
• Stellen Sie sicher, dass der Fortschritt des Checkpoints normal voranschreitet.
• Prüfen Sie Probleme mit der Datenbankperformance wie Sperren, langsame Abfragen oder Ressourcenkonflikte.
• Prüfen Sie, ob Archiv- oder Transaktionslogs verfügbar sind und nicht fehlen.
• Prüfen Sie, ob große Batchvorgänge oder Spitzen im Transaktionsvolumen vorhanden sind.
• Optimieren Sie die Replicat-Performance bei Bedarf mithilfe von Parallelisierung oder Batching.
• Vergewissern Sie sich, dass die Speicherorte der Traildatei über ausreichend Speicherplatz verfügen.
• Validieren Sie Parameterkonfigurationen für Extract-, Pump- und Replicat-Prozesse.
• Starten Sie die betroffenen Prozesse bei Bedarf neu, nachdem Sie die Ursache behoben haben.

Die Analyse der Replikationsverzögerung konzentriert sich in der Regel darauf, zu ermitteln, ob der Engpass durch Folgendes verursacht wird:

• Quelldatenbankaktivität,
• Netzwerkverzögerungen,
• GoldenGate Verarbeitung,
• oder die Performance der Zieldatenbank.

Wie kann ich GoldenGate für verteilte Datenstreams und relationale JSON-Dualität verwenden?

• Mit Oracle Database 23ai JSON Relational Duality Views können Entwickler relationale Daten einfach als JSON-Dokumentmodelle verwenden. Dies kombiniert die Vorteile von JSON-Dokumenten mit denen des relationalen Modells und vermeidet dabei die Einschränkungen der einzelnen Dokumente. Die relationale Dualitätsansicht von Oracle JSON ist im Wesentlichen eine SQL-Ansicht, die JSON-Daten in einem strukturierten, relationalen Format darstellt.
• Die Replikation von Geschäftsobjekten mit Oracle JSON Relational Duality und GoldenGate Data Streams priorisiert Datenprodukte und wird zur Single Source of Truth für Anwendungen, Transaktions-Fabrics, Daten-/Ereignis-Meshes und Daten-Fabrics, indem die Eindeutigkeit der Datenobjekte sichergestellt wird.
• In Oracle LiveLabs erfahren Sie, wie Sie GoldenGate-Datenstreams mit JSON Relational Duality konfigurieren.

Welche erweiterten Optionen gibt es für die Datentransformation in GoldenGate?

• Spaltenzuordnungs-, Filter- und Transformationsfunktionen in Parameterdateien verwenden
• Integration von SQLEXEC für benutzerdefinierte Abfragen oder Prozeduren.

Kann GoldenGate auf z/OS ausgeführt werden, um Änderungen von Db2 für zOS zu erfassen oder zu übermitteln?

• GoldenGate führt Extract/Replicat nicht direkt auf z/OS aus. Stattdessen wird Extract/Replicat remote in der Supportplattform ausgeführt, wie AIX/Linux/zLinux, und eine Verbindung zu Db2 z/OS für Remote Capture und Remote Delivery wird hergestellt.
• GoldenGate muss ein kleines Package in Db2 z/OS installieren, um bestimmte API aufzurufen und Änderungen aus Db2-Logdateien zu erfassen. Die Details finden Sie unter Extract-Komponenten auf Db2 z/OS installieren.

Wenn Sie Replicat nur für Db2 z/OS ausführen, ist dieses Package nicht erforderlich.

Verfügt GoldenGate für Db2 für i und Db2 LUW über Microservices-Architektur?

• Ja, ab GoldenGate 26ai hat GoldenGate Microservices Architecture und nur Microservices Architecture für diese beiden Builds hinzugefügt.
• Vor 26ai stehen nur klassische Architekturen für beide Builds zur Verfügung.

Stellt GoldenGate ODBC-Treiber in Db2 für die i/Db2-Installation für LUW/Db2 z/OS bereit?

Nein, der Endbenutzer muss die entsprechenden ODBC-Treiber unter Verwendung einer eigenen Lizenzvereinbarung mit IBM für diese ODBC-Treiber installieren, wenn diese noch nicht auf dem Server installiert sind, auf dem GoldenGate installiert wird. Informationen zum Herunterladen geeigneter ODBC-Treiber finden Sie im IBM ODBC-Treiber-Benutzerhandbuch.

Wie kann ich GoldenGate in Docker Container ausführen?

Oracle GoldenGate kann in Docker-Containern ausgeführt werden, indem die Software GoldenGate als containerisierter Service bereitgestellt wird. Oracle stellt GoldenGate-Containerimages über Oracle Container Registry (OCR) bereit, mit denen Benutzer vordefinierte Images abrufen und bereitstellen können, um das Setup und die standardisierten Umgebungen zu beschleunigen.

Die Ausführung von GoldenGate in Containern bietet folgende Vorteile:

• vereinfachte Bereitstellung und Upgrades
• Portabilität über Umgebungen hinweg
• einfachere Skalierbarkeit
• bessere Integration mit Cloud-nativen Plattformen

GoldenGate Microservices-Architektur wird in der Regel für Container-Deployments bevorzugt, da sie für moderne verteilte Umgebungen konzipiert ist und gut mit Docker- und Kubernetes-Orchestrierungsplattformen funktioniert.

Containerisierte GoldenGate-Deployments werden häufig in folgenden Bereichen verwendet:

• Cloudumgebungen
• CI/CD-Pipelines
• Kubernetes-Plattformen
• Hybrid- und Multi-Cloud-Architekturen
• moderne Datenreplikations- und Streaming-Lösungen

Persistenter Speicher wird normalerweise extern konfiguriert, um Trails, Checkpoints und Konfigurationsdaten außerhalb des Containerlebenszyklus beizubehalten.

Was ist OCI GoldenGate?

Oracle Cloud Infrastructure (OCI) GoldenGate ist eine vollständig verwaltete, Cloud-native Data Fabric-Plattform, die Datenverschiebung, -integration und -streaming in Echtzeit über heterogene Umgebungen im Unternehmen hinweg ermöglicht. Es erfasst und liefert Transaktionsdatenänderungen mit geringer Latenz zwischen Datenbanken, Data Warehouses, Analyseplattformen, Messaging-Systemen und Cloud-Services.

Als Kernkomponente einer modernen Data Fabric-Strategie unterstützt OCI GoldenGate Unternehmen dabei, verteilte Daten über On-Premises-, Hybrid- und Multicloud-Umgebungen hinweg zu verbinden, zu synchronisieren und zu operationalisieren. Es unterstützt eine Vielzahl von Anwendungsfällen, darunter Echtzeit-Datenreplikation, Zero-Downtime-Migrationen, Betriebsberichte, ereignisgesteuerte Architekturen, Streaminganalysen, KI/ML-Datenpipelines und Datensynchronisierung.

OCI GoldenGate bietet außerdem integrierte Funktionen zum Entwerfen, Orchestrieren, Überwachen, Transformieren, Validieren und Vergleichen von Datenpipelines über eine einheitliche und intuitive Benutzererfahrung.

In welchen Regionen ist OCI GoldenGate verfügbar?

Prüfen Sie hier, ob die aktuellen Regionen, auf denen OCI GoldenGate bereitgestellt ist, https://www.oracle.com/cloud/data-regions/

Wo finde ich die Dokumentation zu OCI GoldenGate?

Die OCI GoldenGate-Dokumentation finden Sie unter: https://docs.oracle.com/en/cloud/paas/goldengate-service/index.html

Was sind die wichtigsten Anwendungsfälle für OCI GoldenGate?

Wichtige Anwendungsfälle für OCI GoldenGate:

• Datenreplikation: Migration, CDC, Offline-Reporting, Echtzeit-Data Warehousing, Integration mit Nicht-Oracle-Quellen und -Zielen sowie Big Data-Aufnahme und -Bereitstellung
• Datenpipelines: Korrelation von Datenereignissen und ETL-Daten in Mikrobatches
• Streaming-Analysen: Zeitreihen, integriertes ML und Geodaten
• Datenprüfung: Daten mit hoher Geschwindigkeit vergleichen
• Einfache Benutzererfahrung beim Verschieben von On-Premises-Daten in autonome KI-Datenbanken, Cloud at Customer und Object Storage
• Einfache HA/DR- und Multi-Active-Einrichtung für OCI-Region-to-Region-, Hybrid-, On-Premises-to-OCI- und Multicloud-Bereitstellungen Anwendungsfälle werden sich weiter entwickeln, wenn neue Bereitstellungstypen und -features hinzugefügt werden.

Welche Unterschiede bestehen zwischen OCI GoldenGate und GoldenGate im OCI Marketplace?

Hier sind ein paar Unterschiede zwischen den beiden Angeboten:

• OCI GoldenGate ist ein vollständig verwalteter Service, bei dem Oracle Infrastrukturvorgänge wie Backups, Patches und Upgrades verwaltet. GoldenGate auf OCI Marketplace wird vom Kunden verwaltet.
• OCI GoldenGate verwendet OCI-Servicekonstrukte wie Deployments, Verbindungen, private Endpunkte und verwaltete Skalierung
• OCI GoldenGate ist Microservices-basiert und unterstützt keine klassische Architektur
• Preisgestaltung: OCI GoldenGate verwendet Universal Credits, und es gibt einen BYOL-Pfad für On-Premise-Benutzer. GoldenGate auf OCI Marketplace erfordert On-Premise-Lizenzen.
• Vereinfachte Konnektivität zu autonomen KI-Datenbanken in OCI GoldenGate mit automatischer Wallet-Verarbeitung und Unterstützung für private Endpunkte im Vergleich zu manueller Einrichtung in GoldenGate im OCI Marketplace.
• Skalierung: OCI GoldenGate wird automatisch auf das bis zu 3-fache der Anzahl der beim Erstellen einer Instanz ausgewählten OCPUs skaliert (max. 24 OCPUs pro Deployment). Die Skalierung einer Instanz erfolgt manuell mit GoldenGate im OCI Marketplace.

Wo finde ich die Service Level Objectives (SLOs) und Service Level Agreements (SLAs)?

Verwenden Sie das aktuelle Public Cloud-Service-Pillar-Dokument von Oracle PaaS und IaaS sowie die aktuelle Oracle Cloud-SLA-Seite:

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

Was kostet OCI GoldenGate?

Der Preis für OCI GoldenGate wird von den OCPUs berechnet, die vom OCI GoldenGate-Host verwendet werden. Die OCPU-Metrik pro Stunde folgt der Standarddefinition:

• OCPU pro Stunde ist definiert als die Anzahl der Oracle Compute Unit-(OCPU-)Stunden, die als Teil von Oracle Cloud Service verwendet werden. Die von einer OCPU bereitgestellte CPU-Kapazität entspricht per E-Mail einem physischen Core eines Prozessors mit aktiviertem Hyperthreading. Jede OCPU entspricht zwei Hardwareausführungsthreads, die als vCPUs bezeichnet werden. Jede OCPU verfügt über eine vordefinierte Arbeitsspeichermenge. Jede angefangene Stunde, in der OCPU genutzt wird, wird als volle Stunde in Rechnung gestellt.

• Es sind keine OCPU-Mindestwerte vorhanden.
• Preis pro OCPU/Stunde: 1,3441 $
• OCPU-Anzahl für OCI GoldenGate-Deployment: Zwischen 1 und 24 OCPUs
• Policy für automatische Skalierung:
  • Kunden können die automatische Skalierung aktivieren oder deaktivieren.
  • Kunden wählen eine Basisgröße (Minimum) aus 1‚ 24 OCPUs (zwischen 1-8 Basis-OCPUs, wenn Autoscaling aktiviert ist).
  • Die automatische Skalierung entspricht 3x der ausgewählten Basisgröße wie folgt:
    • Automatische Skalierung von OCI GG:
      • Benutzerauswahl: Automatische Skalierung aktivieren oder deaktivieren: Benutzer können wählen, ob sie automatisch skalieren möchten
        • Basisgröße auswählen: Der Benutzer wählt die Basisgröße in OCPUs aus. Für die Abrechnung wäre dies die Mindestgröße
        • Automatisch skalieren: Die vertikale/horizontale Skalierung erfolgt automatisch und transparent.
      • Monitoring: OCI GoldenGate gibt Telemetrie darüber aus, wie viele OCPUs zu einem bestimmten Zeitpunkt genutzt werden
      • Teilstunden: Befolgen Sie dieselben Regeln wie Autonomous Database, Exadata Cloud Service: "Für die Zwecke von Oracle Autonomous Data Warehouse und Oracle Autonomous Transaction Processing werden die verbrauchten OCPU-Teilstunden als Teilstunden mit einem Minimum von einer Minute abgerechnet."
      • Spitzenauslastung: Befolgen Sie dieselben Regeln wie bei Autonomous Database und Exadata Cloud Service: "Wenn Autoscaling aktiviert ist, stellt Cloud Service immer die Kapazität für die Anzahl der OCPUs bereit, die Sie beim Erstellen oder explizit skalieren angegeben haben. Ihren Service, aber der Cloud Service kann je nach Workload zusätzliche OCPUs (bis zu insgesamt 3x der Anzahl der OCPUs, die Sie beim Erstellen oder expliziten Skalieren Ihres Service angegeben haben) bereitstellen. Ihre OCPU-Nutzung pro Stunde wird wie folgt berechnet: Maximum (Anzahl der OCPUs für Ihren Service, tatsächliche OCPUs, die von Ihrem Service verbraucht werden). Die tatsächliche OCPU-Nutzung basiert auf dem Verbrauch pro Minute, der stundenweise gemittelt wird."

Sie können auch auf den Cloud-Schätzer verweisen, der OCI GoldenGate in der Kategorie "Datenintegration" enthält: https://www.oracle.com/cloud/costestimator.html

Wie wird BYOL lizenziert?

Umrechnungsverhältnis:

• Für jede 8 Prozessorlizenzen können Sie bis zu 1 OCPU von OCI GoldenGate aktivieren.
• Für alle 400 unterstützten Named User Plus-Lizenzen können Sie bis zu 1 OCPU-Stunde OCI GoldenGate aktivieren.

Jede der folgenden unterstützten Programmlizenzen kann aggregiert werden, um das oben genannte Konvertierungsverhältnis zu erfüllen:

• Oracle GoldenGate oder
• Oracle GoldenGate für Nicht-Oracle AI Database oder
• Oracle GoldenGate for Distributed Applications and Analytics oder
• Oracle GoldenGate for Big Data (jedoch nicht Oracle GoldenGate for Big Data-Ziele)

Kann ich meinen GoldenGate-Marktplatz zu OCI GoldenGate migrieren?

• Die Migration von GoldenGate (entweder GoldenGate On-Premise oder GoldenGate Marketplace) zu OCI GoldenGate ist nicht automatisiert.
• OCI GoldenGate basiert auf der Microservices-Architektur GoldenGate. Wenn der Kunde also bereits GoldenGate (On Premise, auf Compute oder im OCI Marketplace) verwendet, ist dies eine sehr einfache technische Migration. Weitere Informationen finden Sie unter Zu Oracle Cloud Infrastructure GoldenGate migrieren.
• Wenn der Kunde die klassische GoldenGate-Architektur verwendet, ist während der Migration zusätzliche Arbeit erforderlich. Dieser Migrationspfad ist ein bewährter Migrationspfad, den viele Kunden bereits erfolgreich für ihre On-Premise-Investitionen abgeschlossen haben. Ein Migrationsutility von GoldenGate Classic zu GoldenGate Microservices ist ebenfalls verfügbar, mit dem Kunden bei der Migration unterstützt werden können.

Wie kann ich die Größe von OCI GoldenGate richtig festlegen?

OCI GoldenGate verwendet eine Hubarchitektur.

• Alle Daten werden über den OCI GoldenGate-Host weitergeleitet.
• Daten werden remote aus der Quelle erfasst.
• Daten werden dem Ziel remote zugestellt.
• Zähler- und Abrechnungsinformationen prüfen
• Informationen zur OCPU-Auslastung
• Prüfen Sie die Größenüberlegungen für Ihren Deployment-Typ in OCPU-Verwaltung und -Abrechnung

Hinweis:

• Es gibt viele Variablen in Bezug auf die Performance (Netzwerk, Quell-/Zieldatenbank, effektive Verwendung von Indizes, Form des Schemas usw.). Daher ist das Testen in der Praxis für Produktions-Workloads der Goldstandard für die entsprechende Dimensionierung.
• Sie können die OCPU-Auslastung in OCI GoldenGate auf der Seite "Deployment" und über den Metrik-Explorer in der OCI-Konsole überwachen.
• Sie können Alarme in der OCI-Konsole festlegen, damit Sie benachrichtigt werden, wenn eine OCPU-Auslastung bestimmte Werte erreicht.

Welche Quellen und Ziele werden in OCI GoldenGate unterstützt?

Informationen zu unterstützten Quell- und Zielsystemen finden Sie unter Verbindungen kennenlernen.

Kann OCI GoldenGate eine Verbindung zu privaten IPs oder On-Premise-Oracle-Systemen herstellen?

Ja. Weitere Informationen zur Konnektivität finden Sie unter OCI GoldenGate-Konnektivität.

Die OCI GoldenGate-Konnektivität zu Quelle und Ziel wird mit Remote Capture und Remote Delivery aktiviert.

Wie richte ich einen Verteilungspfad zwischen OCI GoldenGate und GoldenGate ein, der auf OCI Marketplace oder On-Premises ausgeführt wird?

In der folgenden LiveLabs wird beschrieben, wie Verteilungspfade zwischen OCI-GG und einer GG-Microservices-Installation erstellt werden:

• Daten von Oracle GoldenGate an OCI GoldenGate senden
• Daten von OCI GoldenGate an Oracle GoldenGate senden

Unterstützt OCI GoldenGate Oracle-Einzelinstanzdatenbanken?

Ja, sowohl integrierbare (mehrmandantenfähige) als auch einzelne Instanzen werden unterstützt.

Werden dedizierte autonome Datenbanken unterstützt?

Ja, Autonomous AI Database on Dedicated Infrastructure-Umgebungen werden vollständig unterstützt.

Prüfen Sie die aktuelle Dokumentation zu Autonomous AI Database und OCI GoldenGate auf die genauen Voraussetzungen: Oracle Autonomous AI Database

Kann ich mit Oracle Management Cloud und Oracle Enterprise Manager (OEM) auf OCI GoldenGate zugreifen und diese überwachen?

Das Management Pack für GoldenGate unterstützt jetzt OCI GoldenGate.

Was ist Oracle GoldenGate Foundation Suite?

Oracle GoldenGate Foundation Suite ist ein Paket von drei Produkten. Sie umfassen:

• Oracle GoldenGate Veridata
• Oracle GoldenGate Management Pack (EM-Plug-in und -Monitor)
• Oracle GoldenGate Studio

Was ist Oracle GoldenGate Veridata?

Oracle GoldenGate Veridata ist eine Hochgeschwindigkeitslösung für den Datenvergleich und die Reparatur, mit der Datenabweichungen zwischen heterogenen Datenbanken identifiziert, gemeldet und behoben werden, ohne laufende Geschäftsprozesse automatisch zu unterbrechen. Es bietet eine benutzerfreundliche und dennoch leistungsstarke Lösung für die Identifizierung nicht synchronisierter Daten, bevor sie sich negativ auf das Unternehmen auswirken.

Was sind die verschiedenen Komponenten von Oracle GoldenGate Veridata?

Die verschiedenen Komponenten von Oracle GoldenGate Veridata sind:

• Veridata Agent
• Veridataserver
• Veridata-Repository-Datenbank
• Vericom-Utility - CLI

Wie wird ein Echtzeit-Datenvergleich mit Oracle GoldenGate Veridata durchgeführt?

Oracle GoldenGate Veridata führt einen Echtzeit-Datenvergleich durch, indem Quell- und Zieldatenbanken verglichen werden, während die Oracle GoldenGate-Replikation ausgeführt wird.

Hier ist der allgemeine Prozess:

1. GoldenGate repliziert Transaktionsänderungen von der Quelldatenbank nahezu in Echtzeit in die Zieldatenbank.

2. Veridata stellt eine unabhängige Verbindung zur Quell- und Zieldatenbank her.

3. Es vergleicht Daten in konfigurierbaren Chunks oder Zeilenbereichen mit:

   • Primärschlüssel
   • Hashes/Prüfsummen
   • zeilenweise Validierung, wenn Unstimmigkeiten erkannt werden

4. Veridata identifiziert:

   • Fehlende Zeilen
   • Zusätzliche Zeilen
   • Spaltenwerte geändert
   • nicht synchronisierte Transaktionen

5. Vergleichsjobs können wiederholt oder kontinuierlich ausgeführt werden, während die Replikation aktiv bleibt. Dies ermöglicht eine fortlaufende Validierung mit minimalen Auswirkungen auf Produktionssysteme.

Um Tabellen zu sperren oder die Replikation zu unterbrechen, verwendet Veridata optimierte Vergleichstechniken wie:

• Prüfsummenbasierter Vergleich
• Parallele Verarbeitung
• partitionierte Tabellenscans
• Key-Range Chunking

Dadurch können Organisationen validieren, dass replizierte Daten während der folgenden Zeit synchronisiert bleiben:

• Migrationen
• Upgrades
• Cutover ohne Ausfallzeiten
• aktive Replikation
• Disaster Recovery-Vorgänge

Veridata selbst repliziert keine Daten. Es validiert die Genauigkeit der GoldenGate-Replikation nahezu in Echtzeit.

Informationen zum Echtzeit-Datenvergleich mit Oracle GoldenGate Veridata finden Sie unter Oracle GoldenGate Veridata 26c: Wie funktioniert das?

Wie kann ich die Größe von Oracle GoldenGate Veridata festlegen?

Informationen zum Ändern der Größe von Oracle GoldenGate Veridata finden Sie unter Größe von Oracle GoldenGate Veridata festlegen.

Wofür wird die Veridata Repository-Datenbank verwendet?

Alle Metadateninformationen (d.h. alle Konfigurationen von Veridata) werden in der Veridata-Repository-Datenbank gespeichert.

Veridata 26c enthält eine integrierte MySQL-Datenbank als Repository.

Der Kunde hat jedoch die Möglichkeit, diese integrierte MySQL- oder eine eigene MySQL-Datenbank für das Repository zu verwenden.

Wie groß wäre die Veridata Repository-Datenbank?

Alle Metadateninformationen von Veridata werden in dieser Repository-Datenbank gespeichert.

Es wäre also nicht von großer Größe. Maximal 5 GB wären die Größe des Repositorys.

Kann Oracle GoldenGate Veridata zum Vergleich von Daten zwischen heterogenen Datenbanken verwendet werden?

Ja, Oracle GoldenGate Veridata ist eine heterogene Datenvergleichs- und Reparaturlösung.

Prüfen Sie die folgende verknüpfte Zertifizierungsmatrix:

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

Können DDLs der Tabelle mit Oracle GoldenGate Veridata verglichen werden?

Nein, Oracle GoldenGate Veridata ist ein Datenvergleichstool und kann nur Daten zwischen Tabellen vergleichen. Das haben wir in unserer Roadmap.

Kann Oracle GoldenGate Veridata die Datenreplikation zwischen Quellen und Zielen in Echtzeit überwachen?

Ja, Oracle GoldenGate Veridata kann die Datenreplikation zwischen Quell- und Zieldatenbank nahezu in Echtzeit überwachen und validieren. Es vergleicht kontinuierlich Daten, während die GoldenGate-Replikation ausgeführt wird, und identifiziert Diskrepanzen wie fehlende Zeilen, zusätzliche Zeilen oder Datenunstimmigkeiten.

Dadurch wird sichergestellt, dass replizierte Datenbanken während Migrationen, Upgrades und laufenden Replikationsvorgängen synchronisiert bleiben, mit minimalen Auswirkungen auf Produktionssysteme.

Müssen wir Veridata Server für jede Quell- und Zieldatenbank installieren?

Nein, eine Installation von Veridata reicht aus, um Daten zwischen mehreren Quellen und Zielen zu vergleichen.

Sie müssen keine Veridata-Server installieren, die jeder Quell- und Zieldatenbank zugewiesen sind.

Was ist Veridata Agent? Wie muss es konfiguriert werden?

Veridata Agent ist ein leichtgewichtiges Java-Programm, das für das Abrufen von Daten aus Quell- und Zieldatenbanktabellen verantwortlich ist.

Sie müssen einen dedizierten Agent für jede Datenbank konfigurieren.

Beispiel: Wenn Sie 5 Quellen und Ziele haben, müssen Sie 5 Veridata-Agents für 5 Quellen und 5 Veridata-Agents für 5 Ziele konfigurieren.

Wo müssen die Veridata Agents installiert und bereitgestellt werden?

Veridata-Agents können nativ oder remote auf den Datenbankservern bereitgestellt werden. Wenn Sie Veridata Agents remote konfigurieren, müssen Sie sicherstellen, dass ein gutes Netzwerk zwischen den Veridata Agents und den Quell-/Zieldatenbanken vorhanden ist.

Wo befindet sich die Veridata Agent Properties-Datei?

Sie finden diese Informationen unter dem Pfad < AGENT_HOME > mit dem Namen "agent.properties".

Wo ist die Veridata-Serverkonfigurationsdatei vorhanden?

Die Veridata-Serverkonfigurationsdatei ist im folgenden Pfad vorhanden:

/config/veridata/veridata.cfg

Wo ist die Datei oggvdt_cainput.properties vorhanden?

Die Datei oggvdt_cainput.properties ist im folgenden Pfad vorhanden:

/config/oggvdt_cainput.properties

Wo finde ich die Veridata-Berichte?

Oracle GoldenGate Veridata-Berichte werden in der Regel auf dem Veridata Server-Host unter dem Veridata-Installationsverzeichnis generiert und gespeichert.

Die Standardstandorte sind in der Regel:

• Linux oder UNIX:
  • <VERIDATA_HOME>/reports
  • <VERIDATA_HOME>/veridata/reports
• Fenster: <VERIDATA_HOME>\reports

Sie können auch über die Veridata-Web-UI auf Berichte zugreifen:

1. Melden Sie sich bei der Veridata-Konsole an.
2. Öffnen Sie den Vergleichsjob.
3. Gehen Sie zu Berichte oder Jobdetails → Berichte.
4. Laden Sie je nach Konfiguration HTML-, XML- oder PDF-Ausgaben herunter.

Zu den allgemeinen Berichtstypen gehören:

• Vergleichsübersichtsberichte
• Nicht synchronisierte Zeilenberichte
• Reparaturauswertungen
• Audit-/Complianceberichte

Wenn Sie Veridata mit OGG Microservices- oder OCI-Deployments verwenden, können die Berichte stattdessen in Folgendes geschrieben werden:

• ein gemountetes Volume
• Shared-Storage
• OCI Object Storage, je nachdem, wie das Deployment konfiguriert wurde

Sie können den genauen Berichtspfad prüfen in:

<VERIDATA_HOME>/cfg/veridata.cfg

oder die Eigenschaften für Serverstart/-konfiguration.

Können wir mehrere Veridata Agents für eine Datenbank haben?

Ja, aber wir empfehlen 1 Agent für 1 Datenbank.

Wie viele Vergleichspaare kann ich in einer Gruppe erstellen?

Die Anzahl der Vergleichspaare, die erstellt werden können, ist nicht eingeschränkt. Beliebige Zahl ist in Ordnung.

Wie viele Vergleichspaare kann ich parallel in Veridata ausführen?

Der maximale Standardwert beträgt 100.

Sie kann jedoch aus der Datei veridata.cfg aktualisiert werden, indem der Wert von maxconcurrentjobs geändert wird.

Können in Veridata nur inkrementelle oder geänderte Daten täglich verglichen werden?

Ja, Veridata verfügt über ein Feature namens Delta Comparison.

Sobald Sie diese Funktion aktiviert haben, werden nur die geänderten Daten verglichen.

Was ist Delta Vergleich in Veridata?

Vergleichspaare können so konfiguriert werden, dass sie die Delta-Verarbeitung verwenden. Diese Performancefunktion vergleicht nur die Datenblöcke, die sich seit der letzten Ausführung geändert haben, anstatt die gesamte Tabelle zu scannen.

Dadurch wird verhindert, dass alle historischen Daten immer wieder verglichen werden und nur die geänderten Daten verglichen werden.

Wie aktiviere ich den Deltavergleich in Veridata?

In Oracle GoldenGate Veridata 26c ist Delta Comparison eher auf das moderne "kontinuierliche Datenvalidierung"-Modell ausgerichtet als auf die älteren Erläuterungen zur klassischen Delta-Verarbeitung aus der Legacy-Dokumentation. Das Feature wurde entwickelt, um den Vergleichskosten zu reduzieren, indem es sich nur auf geänderte Daten zwischen Vergleichszyklen konzentriert. Dies ist besonders wichtig für die kontinuierliche Validierung in Aktiv-Aktiv-, Hybrid-Cloud- und Großreplikationsumgebungen.

In Veridata 26c wird Delta Comparison über die modernisierte Veridata-Web-UI aktiviert, wenn Vergleichspaare und Jobs konfiguriert werden. Anstatt sich stark auf Legacy-Befehlszeilenworkflows zu verlassen, konfigurieren Administratoren das Vergleichsverhalten direkt in der UI oder über REST-APIs. Der Prozess umfasst in der Regel die Aktivierung der deltabasierten Validierung innerhalb der Vergleichspaarkonfiguration, sodass Veridata Änderungen zwischen Ausführungen verfolgt und zukünftige Vergleiche auf geänderte Datasets begrenzt. Dies reduziert die Auswirkungen auf die Datenbank und verbessert die Vergleichsperformance für Anwendungsfälle der kontinuierlichen Validierung.

Die 26c-Architektur betont auch:

• Workflows für kontinuierliche Validierung
• geplante Jobs
• REST-API-Automatisierung
• Cloud-native Vorgänge
• Skalierbare Microservices-basierte Vergleichsverarbeitung

statt älteren Standalone-Vergleichsausführungsmodellen.

Darüber hinaus führt Veridata 26c native Planungs- und erweiterte Automatisierungsfunktionen direkt in der Benutzeroberfläche und den APIs ein, sodass Delta Comparison betrieblicher in die fortlaufende Replikationsintegritätsvalidierung integriert wird, anstatt als manuelles Optimierungsfeature behandelt zu werden.

Welche Oracle Enterprise Manager-Plug-in-Version ist für die Überwachung von Oracle GoldenGate 26ai Microservices-Deployments zertifiziert?

Überwachung und Erkennung von Oracle GoldenGate 26ai Microservices in Enterprise Manager 24ai ist mit Oracle GoldenGate EM Plug-in Version 13.5.2.0.6 zertifiziert.

Warum werden Oracle AI Database- und GoldenGate-Patchstufen für Stabilität und Supportfähigkeit empfohlen?

Oracle empfiehlt dringend, Oracle GoldenGate mit den derzeit empfohlenen Oracle Database Release Updates (RUs) und GoldenGate Bundle-Patches auszuführen.

Ältere Datenbankpatchstufen können Kunden Folgendes zugänglich machen:

• integrierte Capture Bugs,
• LogMiner Instabilität,
• nicht unterstützte Kombinationen,
• Sicherheitslücken,
• und Replikationsfehler bereits in neueren RUs behoben.

Empfohlene Übung:

Folgen Sie den neuesten:

• GoldenGate Hinweise zu Patchempfehlungen,
• Datenbank-RU-Empfehlungen,
• und zertifizierten Interoperabilitätsmatrizen.

Validieren Sie Fixes, bevor Sie Produktdefekte auf älteren Patchebenen annehmen.

Primärer Hinweis für Oracle GoldenGate Core-Produkt-Patchsets (KB159960)

Unterstützt Oracle GoldenGate und OCI GoldenGate die Erfassung von Änderungsdaten von MongoDB?

Oracle GoldenGate und OCI GoldenGate unterstützen die Erfassung von Änderungsdaten von MongoDB und MongoDB Atlas. Es unterstützt die bidirektionale Replikation zwischen verschiedenen MongoDB-Datenbanken.

Kann ich Oracle GoldenGate und OCI GoldenGate für MongoDB zu Oracle AI Database-Migrationen verwenden?

Ja, Oracle GoldenGate unterstützt keine Ausfallzeitmigrationen von MongoDB zu Oracle AI Database. Weitere Informationen finden Sie in der Oracle GoldenGate-Dokumentation.

Wie kann ich Oracle GoldenGate-Migrationen für die Migration von MongoDB zu Oracle AI Database konfigurieren?

Stellen Sie die folgenden Voraussetzungen sicher:

• MongoDB-Quellversion ist 5 oder höher.
• Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA) 23.7 oder höher wird sowohl für die Quell-MongoDB- als auch für die Zieldatenbankinstanzen installiert und konfiguriert.
• Die Datenbanktools MongoDB (einschließlich mongodump und mongorestore) werden installiert, und die jeweiligen Verzeichnispfade werden der Pfadumgebungsvariablen hinzugefügt.

Führen Sie die folgenden Schritte aus, um MongoDB zu Oracle AI Database for Oracle GoldenGate zu migrieren:

1. Führen Sie das Dump-Utility MongoDB aus. Führen Sie den Befehl mongodump mit der Option --oplog aus, um einen Snapshot der Quelldatenbank MongoDB zu erstellen:

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

2. Führen Sie das Skript OplogLSN.sh aus, um die Zeitstempel des ersten und letzten Vorgangs aus der Datei oplog.bson zu extrahieren, indem Sie den Pfad zur Datei oplog.bson als Argument wie folgt angeben:

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

   Die Ausgabe enthält die Zeitstempel des ersten und letzten Vorgangs (oder den ersten Noop, wenn während des Dumpprozesses kein Vorgang stattgefunden hat).

   Ausgabe:

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

3. Oplog-Einträge prüfen: Wenn während des Dumps eingehende Vorgänge vorhanden waren, enthält die Datei oplog.bson Einträge für diese Vorgänge, die jeweils einen Zeitstempel aufweisen. Sie können OplogLSN.sh verwenden, um den Zeitstempel des ersten und letzten Vorgangs zu erfassen oder ihn zur manuellen Prüfung in eine JSON-Datei zu konvertieren, wie im vorherigen Schritt gezeigt.

4. Utility MongoDB Restore ausführen: Nachdem Sie die erforderlichen Zeitstempel angegeben haben, verwenden Sie das Utility mongorestore, um die ausgewählten Collections aus dem Dump in der MongoDB-Zielinstanz wiederherzustellen:

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

5. Starten Sie MongoDB CDC Extract: Starten Sie den MongoDB CDC Extract-Prozess vom Zeitstempel des ersten Vorgangs (LSN-Position), der aus der Datei oplog.bson extrahiert wurde. Dadurch wird sichergestellt, dass der CDC-Extrakt mit der Erfassung von Vorgängen beginnt, die nach dem Start des Dumpprozesses auftreten.

6. Konfigurieren Sie das MongoDB-Replicat mit der generierten CDC-Traildatei, und setzen Sie die Eigenschaft oplogReplayLastLsn auf den Zeitstempel des letzten Vorgangs aus der Datei oplog.bson. Dadurch wird sichergestellt, dass das Replicat im oplog-replay-Modus ausgeführt wird, sodass keine Kollisionen auftreten. Sobald der letzte Zeitstempel verarbeitet wurde, wird er im normalen Modus fortgesetzt. Diese Konfiguration garantiert eine präzise Initiierung, ohne Datenverlust oder Duplizierung, und eliminiert die Notwendigkeit einer kostspieligen Kollisionsbehandlung im Replicat.

Wie kann ich anfängliche Ladevorgänge von Snowflake zu Oracle AI Database ausführen?

1. Erstellen Sie einen Change Data Capture-Extrakt (aus der Oracle AI Database-Quelle).

2. SCN aus der Quelldatenbank abrufen.

3. Erstellen Sie einen anfänglichen Ladeextrakt (aus der Oracle AI Database-Quelle).

4. Erstellen Sie einen Verteilungspfad für CDC-Extraktion.

5. Verteilungspfad für den erstmaligen Ladeextrakt erstellen

6. Erstellen Sie ein Replicat für den anfänglichen Ladevorgang (Ziel Snowflake).

7. Erstellen Sie ein Replicat für die Change Data Capture-Replikation (Snowflake-Targeting).

Was muss ich tun, um "Ausnahme: net.snowflake.client.jdbc.SnowflakeReauthenticationRequest: Authentifizierungstoken ist abgelaufen" zu beheben. Der Benutzer muss sich erneut authentifizieren." Fehler in Oracle GoldenGate Snowflake-Replikation?

Dieser Fehler tritt auf, wenn längere Zeiträume inaktiv sind. Um dieses Problem zu beheben, können Sie den JDBC-Parameter CLIENT_SESSION_KEEP_ALIVE festlegen, um zu erzwingen, dass sich der Datenbankbenutzer nach einer Zeit der Inaktivität anmeldet.

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

Unterstützt Oracle GoldenGate und OCI GoldenGate die DDL-Replikation in Snowflake?

Oracle GoldenGate kann so konfiguriert werden, dass Quell-DDL-Änderungen an Snowflake-Zieltabellen propagiert werden. Die automatische Schemaentwicklung ist die Möglichkeit, Änderungen an einem Datenbankschema, wie Tabellen, Spalten, Indizes oder Beziehungen, zu erkennen, zu verwalten und anzuwenden, ohne dass ein manuelles Eingreifen erforderlich ist. Die automatische Schemaentwicklung unterstützt die Erkennung neuer Objekte und Metadatenänderungen und die automatische Generierung von Ziel-DDL für die Schemaentwicklung.

Beim ersten Laden kann es Zieltabellen erstellen oder ersetzen.

Bei CDC Replicat kann es Zieltabellen während der laufenden Anwendung erstellen oder ändern. Weitere Informationen finden Sie in der Oracle GoldenGate-Dokumentation.

Kann ich Oracle GoldenGate und OCI GoldenGate für die Apache Iceberg-Replikation verwenden?

Ja, Oracle GoldenGate unterstützt die Datenreplikation in Echtzeit in Apache Iceberg. Oracle GoldenGate verwendet die Apache Iceberg Java-API für offene Apache Iceberg Lakehouses. Oracle GoldenGate unterstützt Oracle AI Data Catalog, Amazon Glue, Polaris, Nesti, Hadoop und REST-Kataloge.

Kann ich Oracle GoldenGate und OCI GoldenGate für die Echtzeitdatenreplikation in Apache Iceberg-Tabellen in OCI Object Storage verwenden?

Ja, Oracle GoldenGate und OCI GoldenGate können für die Echtzeitdatenreplikation in Apache Iceberg-Tabellen konfiguriert werden, die über den OCI Object Storage-API-Endpunkt S3 in OCI Object Storage gespeichert sind. Weitere Informationen finden Sie unter "Echtzeit-Apache Iceberg Lakehouse auf OCI Object Storage mit OCI GoldenGate erstellen".

Unterstützt die Oracle GoldenGate- und OCI GoldenGate Apache Iceberg-Replikation beide beim Schreiben?

Ja, Oracle GoldenGate und OCI GoldenGate unterstützen Merge-on-Write für Iceberg-Tabellen, die von Snowflake, Google BigQuery und Databricks verwaltet werden. Auf diesen Plattformen verwendet GoldenGate die Compute-Ressourcen der Zielplattform zur Komprimierung.

Wie können Oracle GoldenGate und OCI GoldenGate Primärschlüsselaktualisierungen in Parketttabellen im OCI Object Storage verarbeiten?

Oracle GoldenGate und OCI GoldenGate verarbeiten Primärschlüsselaktualisierungen in drei Modi. Dieses Verhalten wird gesteuert, indem der Replicat-Eigenschaftendatei gg.handler.name.format.pkUpdateHandling hinzugefügt wird. Unterstützte Werte sind Abend, Update und Delete-Insert. Abend ist das Standardverhalten. Das Replicat ist nicht erfolgreich, wenn eine Primärschlüsselaktualisierung ermittelt wird und der Fehler in der Berichtsdatei protokolliert wird. Bei der Aktualisierung wird der Primärschlüssel wie jeder andere Aktualisierungsvorgang behandelt. Verwenden Sie diese Einstellung nur, wenn Sie sicherstellen können, dass der Primärschlüssel nicht als Auswahlkriterium verwendet wird.

Delete-Insert repliziert die Primärschlüsselaktualisierung als zwei Datensätze: eine mit dem Before Image, als Delete markiert, und eine mit dem After Image, als Insert markiert.

Um DeleteInsert zu verwenden, muss der Extract-Prozess unkomprimierte Änderungsdatensätze erfassen, d.h. alle Spalten werden in die Traildatei geschrieben.

Um unkomprimierte Datensätze zu generieren, verwenden Sie LOGALLSUPCOLS für Oracle AI Database-Quellen und COMPRESSUPDATES | NOCOMPRESSUPDATES für Nicht-Oracle-Datenbanken.

Beispiel: Wenn Sie in OCI Object Storage replizieren, legen Sie gg.handler.<gg.target value>.format.pkUpdateHandling=delete-insert fest, um Primärschlüsselaktualisierungen als einen Löschdatensatz mit dem Before Image und einen Einfügedatensatz mit dem After Image zu replizieren.

Wie kann ich Oracle DATE- und TIMESTAMP-Spalten in Parketttabellen replizieren, die in OCI Object Storage mit Oracle GoldenGate gespeichert sind?

Die Oracle-Spalten DATE und TIMESTAMP werden standardmäßig als Zeichenfolgen repliziert, wenn keine explizite Zuordnung konfiguriert ist. Ohne eine ordnungsgemäße Zuordnung erkennen Downstream-Engines diese Spalten nicht als date/time-Typen, wodurch Datumsarithmetik, Bereichsfilterung und zeitbasierte Partitionierung ohne explizites Casting unmöglich sind. Die Eigenschaft enableTimestampLogicalType ermöglicht die Zuordnung von Oracle-Spalten DATE und TIMESTAMP zum logischen Typ Avro timestamp-micros, der Werte als Mikrosekunden seit Epoch darstellt, der richtigen Darstellung für Analyse- und Data Lake-Workloads.

In der Oracle GoldenGate Cloud Object Storage-Replikation werden die Typen DATE und TIMESTAMP der Quelle Avro-Dateien (einschließlich Parquet, Iceberg und Delta) standardmäßig als STRING zugeordnet.

Um die Quelltypen DATE und TIMESTAMP als logischen Timestamp-Micros-Typ in Avro-Dateien (einschließlich Parquet, Iceberg und Delta) zu replizieren, setzen Sie gg.handler.<gg.target value>.format.enableTimestampLogicalType auf true.

Wenn der logische Zeitstempeltyp aktiviert ist, ist auch gg.format.timestamp erforderlich. Beispiel: gg.handler.oci.format.enableTimestampLogicalType= truegg.format.timestamp=yyyy-MM-dd HH:mm:ss.SSSSSS

Wie kann ich die Replikationsleistung von Oracle GoldenGate OCI Object Storage verbessern?

Die Performance der Oracle GoldenGate Cloud Object Storage-Replikation kann mit zwei Schlüsselfunktionen optimiert werden: Replicat-Typ und GROUPTRANSOPS-Parameter. Neben dem Replicat-Typ und der Transaktionsgruppierung wirkt sich die Größe der vom Replicat erzeugten Dateien direkt auf den Durchsatz aus und sollte in Verbindung mit den anderen Einstellungen optimiert werden. Oracle GoldenGate Distributed Applications and Analytics bietet zwei verschiedene Replikationsmodi: Classic Replicat und Coordinated Replicat.

Classic Replicat ist ein Single-Threaded-Prozess, der die Nachrichten auf Ziel-Cloud-Speicherservices anwendet. Coordinated Replicat ist ein Multi-Threaded-Prozess, bei dem mehrere Threads die OGG-Traildatei unabhängig lesen und Transaktionen parallel anwenden. Der Oracle GoldenGate Cloud Object Storage-Replikationsprozess optimiert die Verarbeitung mit Transaktionsgruppierung. Der Parameter GROUPTRANSOPS gruppiert mehrere kleine Transaktionen in einer einzigen größeren Transaktion, die auf Cloud-Speicherziele angewendet wird. GROUPTRANSOPS ist in der Parameterdatei konfiguriert. Standardmäßig ist GROUPTRANSOPS auf 1000 gesetzt. Sie können bis zu 20000 erhöhen, um eine bessere Leistung zu erzielen.

Beispiel: GROUPTRANSOPS 20000

Wie kann ich die Dateigröße in der Oracle GoldenGate- und OCI GoldenGate-Google Cloud-Speicherreplikation festlegen?

Oracle GoldenGate replicat erstellt eine Datei im lokalen Dateisystem und hält sie geöffnet, bis eine Rollover-Bedingung erfüllt oder durch ein Metadatenänderungsereignis aus der Quelle ausgelöst wird (wie DDL-Änderung). Benutzer können das Datei-Rollover mit Replicat-Eigenschaften steuern. Die maximale Dateigröße steuert die Dateigrößen. Standardmäßig sind Dateigrößen auf 1 GB konfiguriert. Sie können jedoch nach Bedarf konfiguriert werden. Wenn die maximale Größe erreicht ist, wird eine Datei geschlossen, und eine neue Datei wird generiert. Weitere Informationen finden Sie in der Dokumentation "File Writer Handler in Oracle GoldenGate for DAA konfigurieren".

Unterstützt Oracle GoldenGate und OCI GoldenGate die Partitionierung mit der Parquet-Dateireplikation in Google Cloud Storage?

Oracle GoldenGate und OCI GoldenGate unterstützen das Erstellen partitionierter Dateien in Zielobjektspeicher-Buckets. Die Partitionierung verbessert die Downstream-Pruning- und Abfrageperformance, aber die Überpartitionierung erhöht die Verzeichnis-/Dateizahl und verstärkt das Problem mit kleinen Dateien.

Um die Partitionierung zu verwenden, müssen die Daten nach der Tabelle auf der höchsten Ebene partitioniert werden. Dazu wird die Eigenschaft pathMappingTemplate verwendet, die auf den vollqualifizierten Tabellennamen gesetzt werden muss.

Es erstellt Verzeichnisse innerhalb des Containers/Buckets basierend auf dem vollqualifizierten Quelltabellennamen. Beispiel: gg.eventhandler.<gg.target value>.pathMappingTemplate=${fullyQualifiedTableName}

Zum Erstellen von Partitionen wird gg.handler.<gg.target value>.partitioner.<fully_qualified_table_name> verwendet. Diese Eigenschaft kann mit Vorlagenschlüsselwörtern wie ${columnValue[column_name]} oder konstanten Zeichenfolgenwerten verwendet werden, um die Partitionspfadstruktur zu definieren.

Unterstützt Oracle GoldenGate und OCI GoldenGate die DDL-Replikation auf Parkettdateien in Azure Data Lake Storage (ADLS)?

Die Oracle GoldenGate- und OCI GoldenGate-ADLS-Replikation propagiert Quell-DDL-Änderungen automatisch an die generierten Dateien. Alternativ kann EVENTACTIONS verwendet werden, um das Extract/Replicat-Verhalten bei einem DDL-Vorgang in der Quelldatenbank zu steuern.

Wenn Oracle GoldenGate-Extrakt ein Ereignis "Tabelle erstellen" aus der Quelldatenbank erfasst, erstellt das Replicat eine neue Datei mit dem Tabellennamen aus dem Ereignis "Tabelle erstellen" im Objektspeicher-Bucket/-Container der Ziel-Cloud.

Wenn der Oracle GoldenGate-Extrakt ein Ereignis "Spalte ändern/Spalte löschen" aus der Quelldatenbank erfasst, erstellt das Replicat eine neue Datei, die der aktualisierten Quelltabellendefinition entspricht.

Wenn Oracle GoldenGate-Extrakt ein Truncate-Ereignis aus der Quelldatenbank erfasst, können Sie das Replicat so konfigurieren, dass die Datendatei im Truncate-Ereignis rollt, indem Sie Folgendes festlegen:

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

Diese Eigenschaft ist standardmäßig auf "false" gesetzt, und Replicat rollt die Datei nicht im Ereignis "Truncate" aus. Oracle GoldenGate-Extrakt erfasst ein Drop Table-Ereignis aus der Quelldatenbank. Dies hat keine Auswirkungen auf das Zieldateisystem.

Wie verarbeitet Oracle GoldenGate und OCI GoldenGate den Oracle NUMBER-Quelldatentyp beim Replizieren in Parkettdateien in Azure Data Lake Storage (ADLS)?

Oracle NUMBER ist ein Dezimaldatentyp mit variabler Genauigkeit, der Ganzzahlen und Dezimalwerte mit fester Genauigkeit mit bis zu 38 Stellen darstellen kann.

Wenn eine Spalte ohne explizite Genauigkeit und Skalierung definiert wird (z.B. NUMBER), kann Oracle Werte mit unterschiedlicher Skalierung über Zeilen hinweg speichern. In einigen Replikations-/Schemagenerierungsszenarios kann der Formatierer möglicherweise keine einzelne Genauigkeit/Skalierung für das Zielschema deterministisch ableiten. Daher verwenden Mappings zu Avro/Parquet häufig eine konservative Dezimaldarstellung, es sei denn, Sie konfigurieren die Genauigkeit und Skalierung explizit so, dass sie mit den Quellspaltendefinitionen übereinstimmen.

gg.handler.<gg.target value>.enableDecimalLogicalType ist der Master-Switch für die Zuordnung des logischen Typs "Dezimal". Bei 'Wahr' wird der Avro-Formatter angewiesen, Oracle NUMBER-Spalten dem logischen Avro-Dezimaltyp zuzuordnen (Byte mit logicalType: decimal) anstelle der Standardzuordnung, bei der Zahlen als einfache numerische Avro-Primitives oder -Zeichenfolgen geschrieben werden.

Wenn Präzision/Skala nicht deterministisch abgeleitet werden kann, wählt der Formatierer normalerweise eine konservative Avro-Dezimaldefinition (hohe Präzision und Skala), um Präzisionsverlust zu vermeiden. Dies kann dazu führen, dass nachgeschaltete Verbraucher Werte mit einem unnötig großen Maßstab (z. B. scheinbare Nachkommastellen) sehen.

So richten Sie das Zielschema an bekannten, konsistenten Quelldefinitionen aus, insbesondere für Finanzdaten (Salden, Preise, Beträge):

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

Welche ADLS-Authentifizierungsmethoden werden von Oracle GoldenGate und OCI GoldenGate unterstützt?

Oracle GoldenGate und OCI GoldenGate unterstützen Zugriffsschlüssel, Shared Access Signature und Azure Entra ID.

Oracle GoldenGate unterstützt Amazon S3-Tabellen?

Ja, Oracle GoldenGate unterstützt die Echtzeitreplikation von Apache Iceberg auf Amazon S3-Tabellen über Amazon S3-Tabellen-REST-Kataloge.

Unterstützt Oracle GoldenGate und OCI GoldenGate Multiteile-Uploads in Amazon S3?

Ja, durch die Aktivierung der Amazon S3 Multipart Upload-Funktion können die großen Dateien in Amazon S3 hochgeladen werden, indem sie in kleine Teile aufgeteilt werden, die unabhängig und parallel hochgeladen werden können. Diese Funktion löst die bereits bekannten Amazon S3-Einschränkungen, wie z. B. den einzelnen Upload von Objekten mit einer Größe von mehr als 5 GB. Sobald alle Dateiteile erfolgreich hochgeladen wurden, wird eine Anfrage an Amazon S3 gestellt, um sie zu einem einzigen Objekt zusammenzustellen. Um diese Funktion verwenden zu können, müssen Sie gg.eventhandler.s3.multipartEnabled=true im Amazon S3-Replicat aktivieren.

Unterstützt Oracle GoldenGate und OCI GoldenGate die Partitionierung mit der Parquet-Dateireplikation in Google Cloud Storage?

Oracle GoldenGate und OCI GoldenGate unterstützen das Erstellen partitionierter Dateien in Zielobjektspeicher-Buckets. Die Partitionierung verbessert die Downstream-Pruning- und Abfrageperformance, aber die Überpartitionierung erhöht die Verzeichnis-/Dateizahl und verstärkt das Problem mit kleinen Dateien.

Um die Partitionierung zu verwenden, müssen die Daten nach der Tabelle auf der höchsten Ebene partitioniert werden. Dazu wird die Eigenschaft pathMappingTemplate verwendet. Sie muss auf den vollqualifizierten Tabellennamen gesetzt werden. Es erstellt Verzeichnisse innerhalb des Containers/Buckets basierend auf dem vollqualifizierten Quelltabellennamen. Beispiel: gg.eventhandler.<gg.target value>.pathMappingTemplate=${fullyQualifiedTableName}. Zum Erstellen von Partitionen wird gg.handler.<gg.target value>.partitioner.<fully_qualified_table_name> verwendet.

Diese Eigenschaft kann mit Vorlagenschlüsselwörtern wie ${columnValue[column_name]} oder konstanten Zeichenfolgenwerten verwendet werden, um die Partitionspfadstruktur zu definieren.

Wie hoch sind die Preise für OCI Database Migration Service? (Sachlich)

Die ersten 183 Tage (6 Monate) einer Migration werden kostenlos bereitgestellt, außer in Fällen, in denen die Migration mehr als 60 Tage ohne Datenübertragung läuft.

Welche Quellen und Ziele werden von OCI Database Migration Service unterstützt? (Sachlich)

Derzeit werden homogene Migrationen von Oracle und MySQL unterstützt. Die Quellen können On Premise, in anderen Clouds oder in OCI sein. Die Ziele müssen sich in OCI befinden. Oracle wird von 11g (11.2.0.4), 12c (12.1.0.2,12.2.0.1),19c,21c und allen nachfolgenden Oracle Database-Releases unterstützt. MySQL: 5.7 und 8 Versionen. Weitere Details finden Sie in der nächsten URL.

Welche Migrationstypen werden von OCI Database Migration Service unterstützt?

Logische Offline-Migration: Eine einmalige Kopie der Datenbank erfordert, dass Anwendungen während des Migrationsprozesses offline sind. Logische Online-Migration: Erste Kopie der Datenbank gefolgt von Change Data Capture während der Migration. Anwendungen können während des Migrationsprozesses online bleiben.

Welche Objekte und Schemas werden bei einer Migration von oracle standardmäßig ausgeschlossen?

Die folgenden Objekttypen sind immer ausgeschlossen:

• GoldenGate-Administratoren, die in DBA_GOLDENGATE_PRIVILEGES identifiziert werden, einschließlich ggadmin- und c##ggadmin-Benutzern.
• Wenn das Ziel Autonomous Data Warehouse mit gemeinsam verwendeter Infrastructure ist: CLUSTER, DB_LINK, INDEXTYPE, STATISTICS.
• Wenn das Ziel Autonomous Data Warehouse Dedicated Infrastructure ist, Autonomous Transaction Processing mit gemeinsam verwendeter oder dedizierter Infrastructure: CLUSTER, DB_LINK, STATISTICS
• Alle anderen Ziele: Statistik

Die folgenden Schemas sind standardmäßig ausgeschlossen:

• Schema ist in der Quell- oder Zieldatenbank in SYS.DBA_USERS als ORACLE_MAINTAINED markiert
• Schema ist in SYS.KU_NOEXP_VIEW in der Quelldatenbank als vom Export ausgeschlossen markiert
• Schema GGADMIN und C##GGADMIN

Welche OCI-Ressourcen sind für eine Migration erforderlich?

• Vault und Schlüssel zum Speichern von Verbindungs-Secrets.
• Je nach Übertragungsmediumauswahl Objektspeicher oder Dateisystem
• Eine Verbindung pro Quelle und Ziel. In einigen Szenarios ist möglicherweise mehr als eine Verbindung pro Quelle erforderlich.
• Eine Bewertung als Vorbereitung für die Migration.
• Die Bewertung kümmert sich um die Erstellung der Migration
• Bei Onlinemigrationen ist ein OCI GoldenGate-Deployment erforderlich, das jedoch vollständig vom Service verwaltet wird.
• Ein OCI-Ziel

Wo ist OCI GoldenGate verfügbar?

• Oracle Cloud: OCI GoldenGate ist in allen Public Cloud-, Regierungs- und dedizierten Cloud-Regionen in OCI verfügbar. Weitere Informationen finden Sie unter https://www.oracle.com/cloud/distributed-cloud/service-availability/.
• Azure: OCI GoldenGate ist auf Azure auf Oracle AI Database@Azure verfügbar. Weitere Informationen finden Sie unter https://docs.oracle.com/en-us/iaas/Content/database-at-azure/oaa_regions.htm.
• Google Cloud: OCI GoldenGate ist in Google Cloud in der Oracle AI Database@Google Cloud verfügbar. Weitere Informationen finden Sie unter https://docs.oracle.com/en-us/iaas/Content/database-at-gcp/get-started-regions.htm.