Oracle GoldenGate Frequently Asked Questions

Get answers to the most commonly asked questions regarding Oracle GoldenGate AI implementation.

Why does Oracle GoldenGate matter for enterprise AI?

Oracle GoldenGate matters for enterprise AI because AI depends on current, trusted business data. Models, RAG systems, and AI agents cannot reliably reason or act when working from stale batch snapshots or incomplete copies of operational data. GoldenGate streams business events as they happen, giving AI systems access to fresh operational reality while preserving governance, consistency, and auditability.

How does Oracle GoldenGate support RAG and AI agents?

Oracle GoldenGate supports RAG and AI agents by continuously delivering operational data into vector databases, RAG pipelines, AI knowledge bases, lakehouses, and event-driven systems. Using GoldenGate AI capabilities, changed records can be enriched, embedded, summarized, classified, or routed as part of the pipeline, so AI systems operate on current business context rather than stale snapshots.

How does GoldenGate support vector data?

It can replicate existing vectors, move vectors into Oracle AI Database, stream vector changes, and generate embeddings during replication.

When should I use @AISERVICE?

Use @AISERVICE when embedding or enrichment should run in an external AI service, such as a managed or GPU-backed endpoint. See External AI Embedding with @AISERVICE

When should I use @DBFUNCTION?

Use @DBFUNCTION when embedding logic should execute in the target database as part of apply processing. See Native Database Embedding with @DBFUNCTION

How should historical vector loads be handled?

Use bulk instantiation or database-native loading for historical data, then let GoldenGate process incremental changes.

What are the main use cases for Oracle GoldenGate?

Oracle GoldenGate is used for mission-critical high availability and disaster recovery, zero-downtime migrations, real-time analytics, lakehouse ingestion, event-driven architectures, AI and RAG pipelines, data fabric architectures, and governed data synchronization across hybrid and multicloud environments.

Does Oracle GoldenGate support Oracle E-Business Suite (EBS) database migration, and is the Oracle certification information for EBS still valid?

Oracle EBS does not certify any logical replication product for migrations, instead focusing on traditional database methods (import/export, Oracle data pump).

While GoldenGate can be used to replace some of the work done by these traditional database methods to reduce the overall downtime associated with a migration it should not be used on all objects.

bjects that are not supported by GoldenGate or are related to temporary work should be migrated using traditional methods during a downtime window.

Does the AWS reference architecture for GoldenGate with EFS support cross-region DR scenarios?

Check the AWS blog High Availability for Oracle GoldenGate Microservices Architecture in AWS, which describes an in-region high availability design.

In that context:

• EFS replication characteristics are near real-time within a region , and
• The architecture is designed for local failover scenarios

For cross-region DR scenarios, behavior differs significantly:

• EFS replication is asynchronous (with higher RPO, e.g., minutes) , which can lead to missing trail files after failover
• Database promotion across regions may introduce RESETLOGS / new incarnation boundaries

Because of these factors, the in-region design patterns outlined in the AWS blog do not directly extend to cross-region DR without additional considerations.

Recommendation:

For cross-region architectures, use active data movement (e.g., GoldenGate Distribution Path) rather than relying on asynchronously replicated shared storage for trail files.

What are the Oracle Database versions GoldenGate supports?

• GoldenGate 19c and 21c supports Oracle databases from 11.2.0.4 to 21c
• GoldenGate 26ai supports Oracle databases from 19c to 26ai+

For more information, see https://www.oracle.com/integration/goldengate/certifications/.

What are the different types of GoldenGate configurations and use cases?

• Unidirectional: Data flows one way from source to target.
• Bidirectional: Data flows both ways between source and target.
• Multi-directional: Data flows between multiple sources and targets.
• Real-time data warehousing: Keep your data warehouse up-to-date with live transactional data.
• Disaster recovery: Maintain a synchronized copy of your database for failover purposes.
• Zero-downtime migrations: Move databases to new platforms or versions with minimal disruption.
• Application integration: Share data between different applications in real time.
• Cascade: Instead of direct source-to-target replication, changes are first replicated to an intermediate GoldenGate instance (or multiple instances), which then propagates the changes downstream.
• Distribution: Referred to as one-to-many topology, it is an architecture and design pattern used for moving data across multiple databases, cloud environments, and message queues in real-time.
• Consolidation: It allows businesses to centralize data from multiple sources into a single repository, also referred to as ODS (Operation Data Store) which is a real-time, integrated database that consolidates data from multiple transactional systems to support operational reporting and decision-making.
• Real-Time Message Streaming: GoldenGate allows users to publish messages to OCI Streaming, Apache Kafka, Confluent and other GoldenGate certified Kafka based message streaming platforms.
• Real-Time Data Lakes: Real-time replication to cloud storage services (OCI Object Storage, ADLS, Amazon S3, Google Cloud Storage) in various formats including JSON, ORC, Parquet and more.
• Zero Downtime MongoDB Migrations: GoldenGate supports zero downtime migrations from MongoDB to Oracle Database allowing customers to run their migrations without any business interruption.
• Cloud Warehouse Ingestions: GoldenGate allows users to feed large amounts of data to cloud native data warehouse and lake house services like Autonomous Database, Snowflake, Databricks and more.
• Data Streams with AsyncAPI Standards: GoldenGate allows developers to easily subscribe to GoldenGate Data Streams to directly integrate their applications with GoldenGate by receiving JSON formatted into their applications.

What are the key components of GoldenGate?

• Trail files: The files that captured changes are stored.
• Extract: Captures changes from the source database redo/transaction logs and writes to the trail file.
• Distribution Path: Reads from the trail file and further processes to the target system where the Replicat reads and applies to the database or target BigData.
• Replicat: Applies the captured changes to the target database.

What is Oracle GoldenGate and what are its primary use cases?

Oracle GoldenGate is a data integration and replication solution that captures, transforms, and delivers transactional changes across multiple heterogeneous systems in real time.

The primary use cases for Oracle GoldenGate are as follows:

• Database migrations with zero downtime and rollback scenarios
• Real-time analytics and reporting
• Disaster recovery and high availability
• Active/Active Multi Master Regions/Data Centers
• Data integration across on-premises and cloud platforms
• Real-Time Message Streaming
• Real-Time Lakehouses
• Zero Downtime MongoDB Migrations
• Cloud Warehouse Ingestions
• Data Streams with AsyncAPI Standards

Which databases and platforms does Oracle GoldenGate support?

Oracle GoldenGate supports a wide range of databases and targets, including:

• Oracle Database
• MySQL
• PostgreSQL
• SQL Server
• Db2 LUW, Db2 z/OS, Db2 for i
• Amazon RDS, Aurora, Google GCP, Azure Database
• Big Data platforms like Kafka and Hadoop
• Snowflake
• Apache Iceberg
• Various formats like JSON, Parquet, Avro, Delimited Text, etc.
• NoSQL data stores like MongoDB, Cassandra, etc.
• Message streaming platforms like Apache Kafka, Azure Event Hubs, Confluent, etc.

Oracle GoldenGate can capture from Oracle Fusion SaaS and OTM SaaS applications running in OCI.

Oracle GoldenGate cannot capture from Salesforce.com/SFDC.

Oracle GoldenGate can replicate changes into Teradata and TimesTen, but cannot capture from either.

It is recommended to review GoldenGate Certification Metrics for specific database and target support. For more information, see https://www.oracle.com/integration/goldengate/certifications/.

What are the differences between Oracle GoldenGate Classic Architecture and Microservices Architecture?

• Classic Architecture: Older, monolithic model with GGSCI for administration. De-supported in 26ai.
• Microservices Architecture (MA): Modern, REST-based modular design with individual services (for example, Service Manager, Admin Service). MA offers better scalability, security, and ease of use.

For more information on MA, see Oracle GoldenGate Microservices Architecture.

How does Oracle GoldenGate compare with other replication tools?

Oracle GoldenGate is ideal for data integration, database replication, data movement, database migrations, real time data ingestion due to the following reasons:

• It supports bold text hundreds of sources and targets (https://www.oracle.com/integration/goldengate/certifications/)

• It has an incredible support community across many different channels, including
  • 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 is considered the gold standard when it comes to database replication. All competitors strive to be more like GoldenGate and support the many features it supports.

• GoldenGate has many unique advantages, including the ability to create subscriptions to it’s trail files. See About Data Streams, Active-Active Replication, and streaming analytics for details on a fully managed service in OCI GoldenGate that is available in OCI, Google Cloud, and Azure hyperscalers.

• GoldenGate is as mission critical as the databases it replicates and there are numerous topologies that can be used to provide disaster recovery and high availability for GoldenGate itself, including complete automation with database disaster recovery solutions. https://docs.oracle.com/en/database/oracle/oracle-database/26/haovw/maa-platinum-and-oracle-goldengate-best-practices.html

• Additional reasons why GoldenGate is the best can be found here: https://www.oracle.com/a/ocom/docs/techpaper-goldengate-advantages.pdf.

What are the prerequisites for installing Oracle GoldenGate on database XYZ?

Platform & Compatibility

• Supported GoldenGate Microservices version
• Supported database versions (source and target)
• Supported operating system (Linux recommended)
• 64-bit OS and database

Deployment Model

• Defined deployment type (single-node or multi-node)
• Deployment target (VM, bare metal, or Kubernetes)
• All microservices components planned (Admin, Distribution, Receiver, etc.)

Database Configuration

• Database in ARCHIVELOG / transaction logging mode
• Supplemental logging enabled
• GoldenGate database user with required privileges
• Adequate redo / transaction log retention
• Primary keys or unique identifiers on tables

Infrastructure & System Resources

• Sufficient CPU and memory for Extract, Replicat, and services
• Sufficient disk space for trail files, checkpoints, and logs
• High I/O performance for trail file storage

Storage

• Dedicated filesystem for deployment, trails, and logs
• Shared storage if HA is required (e.g., ACFS or cloud filestore)
• Strategy for trail file cleanup and retention

Network & Ports

• Reliable network connectivity between systems
• Required ports open for Admin Server, Distribution, and Receiver
• Proper hostname resolution (DNS or hosts file)
• Low latency for real-time replication

OS & User Setup

• Dedicated OS user (e.g., ogg)
• Correct permissions on all directories
• Required environment variables configured
• OS limits configured (ulimits for files/processes)

Database Connectivity

• Connection strings / TNS / endpoints configured
• Connectivity tested successfully

Microservices-Specific Requirements

• Deployment managed via Service Manager
• Credential store configured
• HTTPS configuration (recommended)
• Optional reverse proxy or load balancer
• Browser access for Admin UI

Security

• Secure credential storage
• TLS/SSL configuration (if required)
• Firewall rules aligned with service ports
• Role-based access for administration

High Availability (Optional)

• Multi-node deployment design
• Shared or replicated configuration
• Load balancer for services
• Defined failover strategy

Operational Readiness

• Time synchronization (NTP)
• Monitoring and alerting setup
• Log management approach
• Backup before enabling replication
• Capacity planning for workload

For more information on preparing databases for Oracle GoldenGate, see Prepare Databases.

What are the differences between secure and non-secure deployments?

• Secure Deployment: Uses TLS/SSL for encrypted communication, OAuth for authentication, and ensures end-to-end security. For more information on secure deployments, see Secure Deployments.
• Non-Secure Deployment: Relies on plaintext HTTP/unencrypted communication. Recommended only for internal/test environments.

How do I configure Oracle GoldenGate Microservices using OGGCA?

• Run oggca.sh (Linux) or oggca.bat (Windows).
• Configure Service Manager and Deployment, specifying ports, paths, and certificates if needed.
• oggca.sh can also be ran in silent mode by providing a response file.

For more information, see Add a Deployment and Add a Deployment in Silent Mode using OGGCA.

What are the best practices for optimizing Oracle GoldenGate performance?

For modern Oracle GoldenGate deployments, the recommended approach is to use Integrated Extract together with Parallel Replicat, as Parallel Replicat is now the strategic and preferred replication method for high-performance target apply operations.

Integrated Replicat is being phased out in favor of Parallel Replicat because Parallel Replicat provides better scalability, improved transaction apply performance, and more efficient parallel processing for high-volume enterprise workloads.

A well-optimized GoldenGate architecture should separate capture, transport, and apply stages by using local and remote trail files, which improves resiliency and isolates replication from network interruptions. Performance also depends heavily on the underlying infrastructure, including fast storage, properly sized database memory, efficient redo log configuration, and stable network connectivity.

Continuous monitoring of Extract lag, Replicat lag, throughput, and checkpoint activity is essential to proactively identify bottlenecks before they impact replication latency.

In general, the best GoldenGate performance is achieved through a combination of scalable architecture design, proper workload distribution, database tuning, and carefully managed parallelism, allowing organizations to maintain low latency and reliable replication even under large transactional workloads.

How do I monitor lag and troubleshoot performance issues?

• Use the Performance Metrics Service in MA.
• Use lag and status commands in Admin Client and REST API
• Check for bottlenecks like network latency or disk I/O.
• Enable Heartbeat table
• User GoldenGate OEM Plugin
• Export Metrics with StatsD
• View current status in the WebUI

What tools or commands can I use to monitor Oracle GoldenGate processes?

In Oracle GoldenGate Microservices Architecture, monitoring is primarily performed through the web-based Administration Service, REST APIs, and the Performance Metrics Service rather than traditional classic architecture tools like GGSCI. The Administration Service provides centralized dashboards that allow administrators to monitor the health and status of Extract, Distribution, Receiver, and Parallel Replicat processes in real time. Through the web interface, users can track replication lag, checkpoint progress, throughput rates, path status, and process performance across the entire deployment. REST APIs also provide programmatic access to monitoring data, enabling integration with automation frameworks and enterprise observability platforms.

A key monitoring component in Microservices Architecture is the Performance Metrics Service (PMSRVR), which collects and exposes operational metrics for replication processes and distribution paths. These metrics can be integrated with monitoring solutions such as Oracle Enterprise Manager, OCI Monitoring, Prometheus, and Grafana to provide centralized dashboards, alerting, and long-term performance analysis. Administrators also rely on deployment logs, report files, and diagnostic information available through the Service Manager and Administration Service interfaces to troubleshoot errors, monitor process behavior, and investigate latency issues.

For OCI GoldenGate deployments, additional monitoring capabilities are available through the OCI Console, OCI Logging, OCI Monitoring, and OCI Alarms, providing cloud-native visibility into deployment health, scaling behavior, replication lag, and operational events. Overall, monitoring in GoldenGate Microservices Architecture focuses on centralized observability, API-driven management, and integration with enterprise monitoring platforms to provide real-time insight into replication performance and system health.

Users can create their own dashboards and monitoring application by accessing StatsD exports and API calls.

What are trail files, and how does Oracle GoldenGate use them in replication?

Trail files store data changes captured by the Extract process in a platform-agnostic format.

• They act as an intermediary between Extract and Replicat processes.

• Provide fault tolerance by allowing replay of captured changes.

• It de-couples the Extract and Replicat component to allow more flexibility of GoldenGate architectures, such as 1 to many for data distribution, as well as cascading replication. Also it makes the cross-platform replication more efficient.

• It is in proprietary binary format that can be interpreted by Logdump utility, which is usually needed during troubleshooting sessions. See the Logdump Reference guide for details.

• For users that want to consume data directly from the GoldenGate trail file, the best option is to use GoldenGate Data Streams, which will allow the user to subscribe to a channel that is maintained by GoldenGate Data Streams by reading from the GoldenGate trail files and put each record from the trail file as an event into that channel.

What is the best recommended Replicat type?

Start with Parallel Replicat: For most use cases, especially those involving high-volume transactional workloads, Parallel Non-Integrated Replicat offers the best performance and flexibility.

GoldenGate Distributed Applications and Analytics support Classic and Coordinated Replicat.

For GoldenGate for Distributed Applications and Analytics, depending on the target, Coordinated Replicat will provide better performance.

How do I set up TLS/SSL for secure data replication?

• Oracle GoldenGate supports TLS/SSL encryption in both the datastore connection and distribution path between GoldenGate Deployments.

• For Distribution Path using TLS/SSL, the certificates are managed through Service Manager’s RestAPI Endpoint. The use can also perform the certificates management task thru Service Manager’s WebUI.

• The Distribution Path can be created under Distribution Service or Receiver Service(target-initiated path).

• Update parameter files with ENCRYPTION directives.

• To secure the distribution path by using TLS/SSL, the deployment has to be set up either as “unsecured deployment + NGINX” or “secured deployment”. For more information, see Secure Data in Transit and How to Convert Non Secure Deployment Into Secure Deployment with SSL/TLS.

  • When using NGINX, the TLS terminates at NGINX. Only the NGINX listening port needs to be exposed to incoming traffic.
  • When using secured deployment, all the GoldenGate services listening ports need to be exposed to incoming traffic. The TLS terminates at the service ports.

What are the options for encrypting trail files?

• Oracle GoldenGate currently supports the following three encryption methods: When communicating with Oracle GoldenGate running on HP NSK, ENCKEYS method is also supported. However, this is strongly discouraged if no HP NSK build is involved. All the above methods support the AES encryption algorithm.
  • Using the master encryption key inside the wallet
  • Oracle OKV for on-premise vault
  • OCI KMS for vault service
• Configure encryption via the ENCRYPTTRAIL parameter.

For more information on securing data, see Secure Data at Rest in the Oracle GoldenGate Microservices Documentation.

How can I integrate Oracle GoldenGate with external identity providers (for example, IAM, OAM) for GoldenGate’s own authentication?

• Oracle GoldenGate Microservices Architecture supports integration with external identity providers such as Oracle Identity and Access Management (IAM), Oracle Access Manager (OAM) and Azure Entra ID to provide centralized authentication, Single Sign-On (SSO), and role-based access control for GoldenGate administration and monitoring services. This integration is especially important in enterprise and cloud environments where centralized identity governance, security compliance, and federated authentication are required.

• In GoldenGate Microservices Architecture, authentication is managed through the Service Manager and Administration Services, which support integration with enterprise identity providers using standards such as OAuth 2.0, OpenID Connect (OIDC), SAML, and LDAP-based authentication depending on the deployment model and provider capabilities. For OCI GoldenGate deployments, integration is commonly performed through Oracle Cloud Infrastructure Identity and Access Management (OCI IAM), allowing administrators to use centralized OCI users, groups, policies, and federation services for secure access to GoldenGate deployments and REST APIs.

• When integrating with Oracle Access Manager (OAM) or enterprise SSO solutions, GoldenGate is typically configured behind a reverse proxy or web gateway that handles authentication and token validation. After successful authentication, user identity and authorization information are forwarded to GoldenGate services. This approach enables centralized login policies, MFA enforcement, session management, and corporate identity federation without requiring separate GoldenGate-specific credentials.

• For Azure Entra ID integrations, GoldenGate can use external directory services provided by Entra ID for user authentication and role mapping, enabling organizations to manage administrative access through existing enterprise user groups and security policies. Role-based access control can then be applied to control permissions for administration, deployment management, monitoring, and API access within the GoldenGate environment.

• GoldenGate REST APIs can also be secured using enterprise authentication mechanisms, allowing external automation platforms, CI/CD pipelines, and monitoring tools to authenticate using centralized identity tokens rather than local service accounts. In cloud-native and hybrid deployments, this integration improves security consistency across enterprise platforms while simplifying user lifecycle management and audit compliance.

• Overall, integrating Oracle GoldenGate with external identity providers enables centralized authentication, SSO, federated identity management, and enterprise-grade security controls, making GoldenGate deployments easier to secure and manage in large-scale enterprise and OCI environments.

• Each ID Provider has slightly different implementation on the endpoint for token request, even with OIDC and OAuth 2.0 standard. GoldenGate will need to create specific profile for such ID Provider to integrate with GoldenGate. So, if your ID Provider is not on the supported list, then you can raise an enhancement request.

How do I migrate databases with zero downtime using Oracle GoldenGate?

Oracle GoldenGate enables near zero-downtime database migrations by continuously replicating transactional changes from the source database to the target database while both systems remain online. Instead of requiring a long outage window for export, import, and cutover activities, GoldenGate allows organizations to synchronize data in real time so the final migration cutover can be completed with minimal application interruption.

In a typical zero-downtime migration architecture, GoldenGate captures changes from the source database using Integrated Extract and writes them into trail files. The changes are then transmitted through Distribution Services and applied to the target database using Parallel Replicat. While the initial data load is being migrated through backup/restore, Data Pump, RMAN duplication, or other bulk load methods, GoldenGate continuously replicates ongoing transactions so the target remains synchronized with the source throughout the migration process.

The migration workflow usually follows several phases:

• preparation and environment setup
• initial data load
• continuous change replication
• validation and synchronization
• controlled cutover

During the initial load phase, a full copy of the database is transferred to the target environment. Once the baseline data is loaded, GoldenGate applies all ongoing transactional changes captured from the source database. This continuous replication significantly reduces the outage window because the target database is already nearly synchronized before cutover begins.

Data validation is a critical part of zero-downtime migrations. Oracle GoldenGate Veridata is commonly used to compare source and target databases during replication to ensure data consistency before production switchover. Continuous validation helps identify discrepancies early and reduces migration risk.

At cutover time, application activity is briefly paused, remaining transactions are allowed to replicate, and administrators verify that replication lag reaches zero. Once synchronization is confirmed, applications are redirected to the target database, and the target environment becomes the new production system. Because most data movement occurred while systems were online, the actual outage window is typically reduced to only the final synchronization and application redirection process.

GoldenGate supports zero-downtime migrations across:

• Oracle-to-Oracle migrations
• cross-version upgrades
• platform migrations
• on-premises to OCI migrations
• heterogeneous database migrations
• multicloud and hybrid cloud transitions

In modern GoldenGate Microservices Architecture and OCI GoldenGate deployments, migration management is further simplified through centralized web interfaces, REST APIs, automated deployment services, and integrated monitoring capabilities. Parallel Replicat, integrated capture, and scalable distribution services help handle large transactional workloads efficiently during migration activities.

Overall, Oracle GoldenGate enables zero-downtime migrations by combining continuous real-time replication, scalable parallel processing, continuous validation, and controlled cutover procedures, allowing organizations to migrate critical databases with minimal business disruption and reduced operational risk.

What are the best practices for configuring bidirectional replication?

Best practices for configuring bidirectional replication with Oracle GoldenGate include:

• Define clear active-active replication architecture and data ownership rules.
• Avoid update conflicts by ensuring the same data is not modified simultaneously on both systems whenever possible.
• Configure conflict detection and resolution (CDR) policies appropriately.
• Use primary keys or unique keys on all replicated tables.
• Ensure both source and target tables have identical structures and compatible data types.
• Exclude unnecessary tables, temporary objects, and unsupported operations from replication.
• Use loop prevention mechanisms to avoid replicated transactions being sent back to the originating system.
• Maintain synchronized database character sets, time zones, and schema definitions.
• Monitor replication lag, process health, and conflict events continuously.
• Test failover, switchover, and recovery procedures regularly.
• Configure proper checkpointing and trail management.
• Separate workloads and size infrastructure appropriately for active-active traffic.
• Use supplemental logging and proper transaction logging configurations.
• Implement strong monitoring, alerting, and auditing practices.
• Validate data consistency regularly using tools such as Oracle GoldenGate Veridata.
• Plan carefully for DDL replication and schema changes.
• Document conflict handling rules and operational procedures clearly.

Bidirectional replication environments require careful planning because they are more complex than unidirectional replication and can introduce challenges such as:

• update conflicts
• replication loops
• data divergence
• latency sensitivity
• and operational complexity.

What does it mean when Replicat shows “stuck” transactions, and how can I fix it?

When Replicat shows “stuck” transactions, it usually means the Replicat process is unable to apply one or more transactions on the target database and replication progress stops or becomes delayed.

Common causes include:

• database locks or blocking sessions on the target
• missing or conflicting records
• constraint violations
• duplicate key errors
• unsupported operations
• long-running transactions
• data type mismatches
• network or connectivity issues
• insufficient system resources

Typical troubleshooting steps include:

• review the Replicat report file and discard file for errors
• check the GoldenGate error logs
• identify the transaction or table causing the blockage
• verify target database availability and health
• check for locked objects or blocking sessions
• resolve data conflicts or constraint issues
• confirm trail files are accessible and intact
• verify checkpoint progress
• restart Replicat after correcting the issue if necessary

In some cases, administrators may need to:

• skip problematic transactions,
• reposition Replicat,
• or resynchronize affected tables

depending on the case, severity and business requirements.

How do I manage disk space and purge old trail filesin Microservices?

In Oracle GoldenGate Microservices Architecture, disk space management and trail file purging are important to prevent storage exhaustion and maintain healthy replication environments.

Trail files are typically managed using automated purge policies that remove old trail files after they are no longer needed by downstream processes.

Common practices include:

• configuring automatic trail file purging
• monitoring disk usage regularly
• separating trail storage from operating system storage
• using dedicated file systems or volumes
• setting retention policies based on recovery requirements

Trail files can usually be purged when:

• all Extract and Replicat processes have processed them
• checkpoints have advanced beyond the files
• the files are no for recovery or resynchronization

In Microservices, trail management is commonly handled through:

• the Administration Server
• Distribution Service
• Receiver Service
• command-line administration tools
• or REST APIs

Additional recommendations include:

• enabling disk space monitoring and alerts
• archiving trails if required for auditing
• using external storage for long retention periods
• periodically reviewing purge policies and storage growth trends

Proper trail management helps avoid:

• replication stoppages
• disk full conditions
• performance degradation
• and recovery complications.

How do I configure auto start and restart in Microservices?

In Oracle GoldenGate Microservices Architecture, auto start and auto restart can be configured to automatically start and recover deployment services and replication processes after failures or server restarts.

This is typically configured by:

• enabling auto start profiles for Extract and Replicat processes
• enabling auto restart policies with retry intervals and retry counts
• configuring service manager startup behavior
• integrating the deployment with operating system services or container orchestration platforms

Auto restart settings help ensure high availability by automatically restarting failed processes without manual intervention.

Common configuration options include:

• startup delay
• retry count
• retry interval
• dependency ordering
• failure thresholds

These settings can usually be managed through:

• the GoldenGate Microservices web interface
• REST APIs
• or command-line administration tools

Auto start and restart are commonly used in:

• production HA environments
• cloud deployments
• containerized environments
• disaster recovery architectures
• unattended replication systems.

What are the troubleshooting steps for replication lag?

Common troubleshooting steps for Oracle GoldenGate replication lag include:

• Check the lag status using GoldenGate monitoring commands or dashboards.
• Verify whether the Extract, Pump, or Replicat processes are running normally.
• Review GoldenGate report files and error logs for warnings or failures.
• Check for long-running transactions on the source database.
• Monitor network latency and bandwidth between source and target systems.
• Verify that trail files are being generated and consumed correctly.
• Check CPU, memory, disk I/O, and storage utilization on both source and target servers.
• Ensure checkpoint progress is advancing normally.
• Review database performance issues such as locks, slow queries, or resource contention.
• Verify archive logs or transaction logs are available and not missing.
• Check for large batch operations or spikes in transaction volume.
• Tune Replicat performance using parallelism or batching if necessary.
• Confirm trail file disk locations have sufficient space.
• Validate parameter configurations for Extract, Pump, and Replicat processes.
• Restart affected processes if required after resolving the root cause.

Replication lag analysis usually focuses on identifying whether the bottleneck is caused by:

• source database activity,
• network delays,
• GoldenGate processing,
• or target database performance.

How can I use GoldenGate for distributed data streams and JSON relational duality?

• Oracle Database 23ai JSON Relational Duality Views enables developers to easily consume relational data as JSON document models. This combines the advantages of JSON documents with those of the relational model, while avoiding the limitations of each. Oracle JSON relational duality view is essentially a SQL view that presents JSON data in a structured, relational format.
• Replicating Business Objects with Oracle JSON Relational Duality and GoldenGate Data Streams prioritizes data products and becomes the single source of truth for applications, transaction fabrics, data/event meshes, and data fabrics by ensuring the uniqueness of the data objects.
• You can refer to Oracle LiveLabs to experience how to configure GoldenGate Data Streams with JSON Relational Duality.

What are the advanced options for data transformation in GoldenGate?

• Use column mapping, filtering, and transformation functions in parameter files.
• Integrate SQLEXEC for custom queries or procedures.

Can GoldenGate run on z/OS to capture changes from or deliver changes to Db2 for zOS?

• GoldenGate does not run Extract/Replicat directly on z/OS. Instead, the Extract/Replicat will run remotely in the support platform such as AIX/Linux/zLinux and connect to the Db2 z/OS for remote capture and remote delivery.
• GoldenGate does need to install a small package to Db2 z/OS to call certain API to capture changes from Db2 log files. The detail can be found in Install Extract Components on Db2 z/OS.

If you only run Replicat against the Db2 z/OS, then this package is not needed.

Does GoldenGate for Db2 for i and Db2 LUW have Microservices Architecture?

• Yes, starting GoldenGate 26ai, GoldenGate has added Microservices Architecture and only Microservices Architecture for these two builds.
• Before 26ai, there are only Classic Architectures available for both builds.

Does GoldenGate provide any ODBC Drivers in Db2 for i/Db2 for LUW/Db2 z/OS build installation?

No, the end user will have to install the appropriate ODBC drivers using their own license agreement with IBM for those ODBC drivers if they are not already installed on the server where GoldenGate is being installed. Please refer to IBM’s ODBC driver user guide on how to download appropriate ODBC driver(s).

How can I run GoldenGate in Docker Container?

Oracle GoldenGate can be run in Docker containers by deploying the GoldenGate software as a containerized service. Oracle provides GoldenGate container images through Oracle Container Registry (OCR), allowing users to pull and deploy prebuilt images for faster setup and standardized environments.

Running GoldenGate in containers provides benefits such as:

• simplified deployment and upgrades
• portability across environments
• easier scalability
• better integration with cloud-native platforms

GoldenGate Microservices Architecture is typically preferred for container deployments because it is designed for modern distributed environments and works well with Docker and Kubernetes orchestration platforms.

Containerized GoldenGate deployments are commonly used in:

• cloud environments
• CI/CD pipelines
• Kubernetes platforms
• hybrid and multi-cloud architectures
• modern data replication and streaming solutions

Persistent storage is usually configured externally to retain trails, checkpoints, and configuration data outside the container lifecycle.

What is the OCI GoldenGate?

Oracle Cloud Infrastructure (OCI) GoldenGate is a fully managed, cloud-native Data Fabric platform that enables real-time data movement, integration, and streaming across heterogeneous environments at enterprise scale. It captures and delivers transactional data changes with low latency between databases, data warehouses, analytics platforms, messaging systems, and cloud services.

As a core component of a modern Data Fabric strategy, OCI GoldenGate helps organizations connect, synchronize, and operationalize distributed data across on-premises, hybrid, and multicloud environments. It supports a wide range of use cases including real-time data replication, zero-downtime migrations, operational reporting, event-driven architectures, streaming analytics, AI/ML data pipelines, and data synchronization.

OCI GoldenGate also provides integrated capabilities to design, orchestrate, monitor, transform, validate, and compare data pipelines through a unified and intuitive user experience.

In which regions is OCI GoldenGate available?

Check here for the current regions OCI GoldenGate is deployed on - https://www.oracle.com/cloud/data-regions/

Where can I find the OCI GoldenGate documentation?

The OCI GoldenGate documentation is available at: https://docs.oracle.com/en/cloud/paas/goldengate-service/index.html

What are the key use cases for OCI GoldenGate?

Key use cases for OCI GoldenGate include:

• Data replication: migration, CDC, offline reporting, real-time data warehousing, integration with non-Oracle sources and targets, and Big Data ingest and delivery
• Data pipelines: correlate data events and ETL data in micro-batches
• Streaming analytics: time series, embedded ML, and geospatial
• Data verification: compare data at high speed
• Simple user experience to move on-premises data into Autonomous AI Databases, Cloud at Customer, and Object Storage
• Simple HA/DR and multi-active setup for OCI region-to-region, hybrid, on-premises-to-OCI, and multicloud deployments Use cases will continue to evolve as new deployment types and features get added.

What are the differences between OCI GoldenGate and GoldenGate on OCI Marketplace?

Here are a couple of differences between the two offerings:

• OCI GoldenGate is a fully managed service where Oracle manages infrastructure operations such as backups, patching, and upgrades. GoldenGate on OCI Marketplace is customer-managed.
• OCI GoldenGate uses OCI service constructs such as deployments, connections, private endpoints, and managed scaling
• OCI GoldenGate is Microservices-based and does not support Classic architecture
• Pricing: OCI GoldenGate uses universal credits and there is a BYOL path for on-premises users. GoldenGate on OCI Marketplace requires on-prem licenses.
• Simplified connectivity to Autonomous AI Databases in OCI GoldenGate with automatic wallet handling and Private Endpoint support vs. more manual setup in GoldenGate on OCI Marketplace.
• Scaling: OCI GoldenGate automatically scales to up to 3 times the number of OCPUs selected when creating an instance (max limit of 24 OCPUs per deployment). Scaling an instance is manual with GoldenGate on OCI Marketplace.

Where can I find the Service Level Objectives (SLOs) and Service Level Agreements (SLAs)?

Use the current Oracle PaaS and IaaS public cloud service pillar document and the current Oracle Cloud SLA page:

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

What does OCI GoldenGate cost?

OCI GoldenGate is priced by the OCPU’s consumed by the OCI GoldenGate host. The OCPU per hour metric follows the standard definition:

• OCPU Per Hour is defined as the number of Oracle Compute Unit (OCPU) hours used as part of the Oracle Cloud Service. An OCPU provides CPU capacity equivalent of one physical core of a processor with hyper-threading enabled. Each OCPU corresponds to two hardware execution threads, known as vCPUs. Each OCPU has a pre-defined amount of memory. Each partial OCPU Hour consumed will be billed as a full hour.

• There are no OCPU minimums.
• Price Per OCPU per Hour: $1.3441
• OCI GoldenGate Deployment OCPU Counts: Between 1-24 OCPUs
• Auto-Scale Policy:
  • Customers may enable or disable Auto-Scale.
  • Customers choose a base size (minimum) from 1‚ 24 OCPUs (between 1-8 Base OCPUs if Auto-Scale is enabled).
  • Auto-Scale is 3x the selected base size as follows:
    • Auto-Scale of OCI GG:
      • User Choice: Enable or Disable Auto-Scale: user may choose whether they want auto-scale
        • Choose Base Size: user chooses the Base Size in OCPUs, for purposes of billing, this would be the minimum
        • Auto-scale: scaling up/down will happen automatically and transparently
      • Monitoring: OCI GoldenGate emits telemetry on how many OCPUs are utilized at a given moment
      • Partial Hours: Follow same rules as Autonomous Database, Exadata Cloud Service: “For the purposes of Oracle Autonomous Data Warehouse and Oracle Autonomous Transaction Processing, partial OCPU hours consumed are billed as partial hours with a one-minute minimum.”
      • Peak Utilization: Follow same rules as Autonomous Database and Exadata Cloud Service: “If auto scaling is enabled, the Cloud Service will always provide capacity for the number of OCPUs you specified when you created or explicitly scaled your service, but the Cloud Service may also provide additional OCPUs (up to a total of 3x of the number of OCPUs you specified when creating or explicitly scaling your service) as needed based upon your workload. Your OCPU consumption per hour will be computed as follows: maximum (the number of OCPUs for your service, actual OCPUs consumed by your service). The actual OCPU usage is based upon per minute consumption, averaged across the hour.”

You can also refer to the Cloud Estimator which includes OCI GoldenGate in the Data Integration category: https://www.oracle.com/cloud/costestimator.html

How is BYOL licensed?

Conversion Ratios:

• For every 8 Processor licenses, you may activate up to 1 OCPU of OCI GoldenGate.
• For every 400 supported Named User Plus licenses, you may activate up to 1 OCPU hour of OCI GoldenGate.

Any of the following supported program licenses may be aggregated to meet the conversion ratio above:

• Oracle GoldenGate or
• Oracle GoldenGate for Non Oracle Database or
• Oracle GoldenGate for Distributed Applications and Analytics or
• Oracle GoldenGate for Big Data (but not Oracle GoldenGate for Big Data Targets)

Can I migrate my GoldenGate Marketplace to OCI GoldenGate?

• Migration from GoldenGate (either GoldenGate on-prem or GoldenGate Marketplace) to OCI GoldenGate is not automated.
• OCI GoldenGate is built on the GoldenGate Microservices Architecture. So if the customer is already using GoldenGate (on premise, on Compute or in the OCI Marketplace), this is a very straightforward technical migration. For more information, see Migrating to Oracle Cloud Infrastructure GoldenGate.
• If the customer is using GoldenGate Classic Architecture, this will require some additional work during the migration. This migration path is a proven migration path that many customers have already successfully completed for their on premise investments. A migration utility from GoldenGate Classic to GoldenGate Microservices is also available, which could be used to help customers migrate.

How do I appropriately size OCI GoldenGate?

OCI GoldenGate uses a hub architecture.

• All data is routed though the OCI GoldenGate host.
• Data is remotely captured from the source.
• Data is remotely delivered to the target.
• Review Metering and billing information
• Review About OCPU utilization
• Review the Sizing considerations for your deployment type in OCPU management and billing

Note:

• There are many variables around performance (network, source/target database, effective use of indices, shape of schema, and so on). Therefore, real-world testing on production workloads is the gold standard for appropriate sizing.
• You can monitor OCPU Utilization on the OCI GoldenGate Deployment Details page and the Metrics Explorer in the OCI Console.
• You can set alarms in the OCI Console to notify you when OCPU utilization reaches certain levels.

What sources and targets are supported in OCI GoldenGate?

For information on supported source and target systems, see Explore Connections.

Can OCI GoldenGate connect to private IPs or On-Prem Oracle systems?

Yes. For more information on connectivity, see OCI GoldenGate connectivity.

OCI GoldenGate connectivity to source and target is enabled with remote capture and remote delivery.

How do I set up a distribution path between OCI GoldenGate and GoldenGate running on OCI Marketplace or on-premises?

The following LiveLabs describe how to create distributions paths between OCI-GG and a GG microservices installation:

• Send Data from Oracle GoldenGate to OCI GoldenGate
• Send Data from OCI GoldenGate to Oracle GoldenGate

Does OCI GoldenGate support single instance Oracle databases?

Yes, both pluggable (multi-tenant) and single instances are supported.

Are dedicated Autonomous Databases supported?

Yes, Autonomous AI Database on Dedicated Infrastructure environments are fully supported.

Check current Autonomous AI Database and OCI GoldenGate documentation for the exact prerequisites: Oracle Autonomous AI Database

Can I access and monitor OCI GoldenGate using Oracle Management Cloud and Oracle Enterprise Manager (OEM)?

The Management Pack for GoldenGate now supports OCI GoldenGate.

What is Oracle GoldenGate Foundation Suite?

Oracle GoldenGate Foundation Suite is a bundle of three products. It includes:

• Oracle GoldenGate Veridata
• Oracle GoldenGate Management Pack (EM Plugin and Monitor)
• Oracle GoldenGate Studio

What is Oracle GoldenGate Veridata?

Oracle GoldenGate Veridata is a high-speed, data-comparison and repair solution that identifies, reports on, and fixes data discrepancies between heterogeneous databases without interrupting ongoing business processes automatically. It provides an easy-to-use yet powerful solution for identifying out-of-sync data before it negatively impacts the business.

What are the various components of Oracle GoldenGate Veridata?

The various components of Oracle GoldenGate Veridata are:

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

How is real-time data comparison done with Oracle GoldenGate Veridata?

Oracle GoldenGate Veridata performs real-time data comparison by comparing source and target databases while Oracle GoldenGate replication is running.

Here’s the general process:

1. GoldenGate replicates transactional changes from the source database to the target database in near real time.

2. Veridata connects independently to both the source and target databases.

3. It compares data in configurable chunks or row ranges using:

   • primary keys
   • hashes/checksums
   • row-by-row validation when mismatches are detected

4. Veridata identifies:

   • missing rows
   • extra rows
   • changed column values
   • out-of-sync transactions

5. Comparison jobs can run repeatedly or continuously while replication remains active, allowing ongoing validation with minimal impact on production systems.

To avoid locking tables or interrupting replication, Veridata uses optimized comparison techniques such as:

• checksum-based comparison
• parallel processing
• partitioned table scans
• key-range chunking

This enables organizations to validate that replicated data stays synchronized during:

• migrations
• upgrades
• zero-downtime cutovers
• active-active replication
• disaster recovery operations

Veridata itself does not replicate data,it validates the accuracy of GoldenGate replication in near real time.

For information on real-time data comparison using Oracle GoldenGate Veridata, see Oracle GoldenGate Veridata 26c: How does it work?

How do I size Oracle GoldenGate Veridata?

For information on sizing Oracle GoldenGate Veridata, see How to size Oracle GoldenGate Veridata?.

What is Veridata Repository Database used for?

All the metadata information (that is, all the configurations of Veridata) will be stored in the Veridata Repository Database.

Veridata 26c comes with a built-in MySQL database as repository.

However, the customer has the option to use this built-in MySQL or their own MySQL database for the repository.

What would be the size of the Veridata Repository Database?

All the metadata information of Veridata will be stored in this repository database.

So, it would not be of a big size. A maximum of 5 GB would be the size of the repository.

Can Oracle GoldenGate Veridata be used to compare data between heterogeneous databases?

Yes, Oracle GoldenGate Veridata is a heterogeneous data comparison and repair solution.

Please check the following certification matrix linked:

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

Can we compare DDLs of the table using Oracle GoldenGate Veridata?

No, Oracle GoldenGate Veridata is a data comparison tool and it can only compare data between tables. However, we have this in our roadmap.

Can Oracle GoldenGate Veridata monitor the data replication between sources and targets in real time?

Yes, Oracle GoldenGate Veridata can monitor and validate data replication between source and target databases in near real time. It continuously compares data while GoldenGate replication is running and identifies discrepancies such as missing rows, extra rows, or data mismatches.

This ensures that replicated databases remain synchronized during migrations, upgrades, and ongoing replication operations, with minimal impact on production systems.

Do we need to install Veridata Server for each Source and Target database?

No, one installation of Veridata is enough to compare data between multiple sources and targets.

You don’t need to install Veridata Servers dedicated to each source and target database.

What is Veridata Agent? How does it need to be configured?

Veridata Agent is a light-weight Java program which is responsible for fetching data from source and target database tables.

You need to configure one dedicated Agent for each database.

For example, if you have 5 sources and targets, then you need to configure 5 Veridata Agents for 5 sources and 5 Veridata Agents for 5 targets.

Where do we need to install and deploy the Veridata Agents?

Veridata Agents can be deployed either native or remote to the Database Servers. When you configure Veridata Agents remotely, then you need to make sure to have a good network between the Veridata Agents and the source/target databases.

Where is the Veridata Agent Properties file located?

This can be found in < AGENT_HOME > path with the name "agent.properties".

Where is the Veridata server config file present?

The Veridata server config file is present in the following path:

/config/veridata/veridata.cfg

Where is the oggvdt_cainput.properties file present?

The oggvdt_cainput.properties file is present in the following path:

/config/oggvdt_cainput.properties

Where can I find the Veridata Reports?

Oracle GoldenGate Veridata reports are typically generated and stored on the Veridata Server host under the Veridata installation directory.

The default locations are usually:

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

You can also access reports from the Veridata Web UI:

1. Log in to the Veridata console.
2. Open the comparison job.
3. Go to Reports or Job Details → Reports.
4. Download HTML, XML, or PDF outputs, depending on the configuration.

Common report types include:

• Comparison summary reports
• Out-of-sync row reports
• Repair reports
• Audit/compliance reports

If you are using Veridata with OGG Microservices or OCI deployments, the reports may instead be written to:

• a mounted volume
• shared storage
• OCI Object Storage, depending on how the deployment was configured

You can verify the exact report path in:

<VERIDATA_HOME>/cfg/veridata.cfg

or the server startup/configuration properties.

Can we have multiple Veridata Agents for a database?

Yes, but we recommend 1 agent for 1 database.

How many Compare pairs can I create in a group?

There is no restriction on the number of Compare pairs that can be created. Any number is fine.

How many Compare pairs can I run in parallel in Veridata?

The maximum default value is 100.

But it can be updated from the veridata.cfg file by changing the value of maxconcurrentjobs.

Can only incremental or changed data be compared on daily basis in Veridata?

Yes, Veridata has a feature called Delta Comparison.

Once you enable this feature, only the changed data will be compared.

What is Delta Comparison in Veridata?

Compare pairs can be configured to use delta processing, a performance feature that compares only the data blocks that have changed since the last run, instead of scanning the entire table.

This prevents comparing all the historical data again and again and compares only the changed data.

How do I enable Delta Comparison in Veridata?

In Oracle GoldenGate Veridata 26c, Delta Comparison is more aligned with the modern “continuous data validation” model rather than the older classic-style delta processing explanations from legacy documentation. The feature is designed to reduce comparison overhead by focusing only on changed data between comparison cycles, which is especially important for continuous validation in active-active, hybrid cloud, and large-scale replication environments.

In Veridata 26c, Delta Comparison is enabled through the modernized Veridata Web UI when configuring Compare Pairs and Jobs. Instead of relying heavily on legacy command-line workflows, administrators configure comparison behavior directly in the UI or through REST APIs. The process typically involves enabling delta-based validation within the Compare Pair configuration so Veridata tracks changes between executions and limits future comparisons to modified data sets. This reduces database impact and improves comparison performance for continuous validation use cases.

The 26c architecture also emphasizes:

• continuous validation workflows
• scheduled jobs
• REST API automation
• cloud-native operations
• scalable microservices-based comparison processing

rather than older standalone comparison execution models.

Additionally, Veridata 26c introduces native scheduling and enhanced automation capabilities directly in the UI and APIs, making Delta Comparison more operationally integrated into ongoing replication health validation rather than being treated as a manual optimization feature.

What Oracle Enterprise Manager plugin version is certified for monitoring Oracle GoldenGate 26ai Microservices deployments?

Oracle GoldenGate 26ai Microservices monitoring and discovery in Enterprise Manager 24ai is certified with Oracle GoldenGate EM Plugin version 13.5.2.0.6.

Why are recommended Oracle Database and GoldenGate patch levels important for stability and supportability?

Oracle strongly recommends running Oracle GoldenGate with currently recommended Oracle Database Release Updates (RUs) and GoldenGate bundle patches.

Older database patch levels may expose customers to:

• integrated capture bugs,
• LogMiner instability,
• unsupported combinations,
• security vulnerabilities,
• and replication defects already fixed in newer RUs.

Recommended practice:

Follow the latest:

• GoldenGate patch recommendation notes,
• database RU recommendations,
• and certified interoperability matrices.

Validate fixes before assuming product defects on older patch levels.

Primary Note for Oracle GoldenGate Core Product Patch Sets (KB159960)

Does Oracle GoldenGate and OCI GoldenGate support change data capture from MongoDB?

Oracle GoldenGate and OCI GoldenGate supports change data capture from MongoDB and MongoDB Atlas. It supports bi-directional replication between different MongoDB databases.

Can I use Oracle GoldenGate and OCI GoldenGate for MongoDB to Oracle Database migrations?

Yes, Oracle GoldenGate supports no downtime migrations from MongoDB to Oracle database. You can refer to Oracle GoldenGate documentation for details.

How can I configure Oracle GoldenGate migrations to migrate from MongoDB to Oracle Database?

Ensure the following prerequisites:

• MongoDB source version is 5 or higher.
• Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA) 23.7 or above is installed and configured for both the source MongoDB and target database instances.
• The MongoDB Database Tools (including mongodump and mongorestore) are installed, and the respective directory paths are added to the path environment variable.

Follow these steps to migrate MongoDB to Oracle Database for Oracle GoldenGate:

1. Run MongoDB Dump Utility. Run the mongodump command with the --oplog option to create a snapshot of the source MongoDB database:

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

2. Run the OplogLSN.sh script to extract the first and last operation timestamps from the oplog.bson file by providing the path to oplog.bson file as an argument as follows:

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

   The output provides the timestamps of the first and last operation (or the first noop if no operation occurred during the dump process.)

   Output:

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

3. Inspect Oplog Entries: If there were any incoming operations during the dump, then the oplog.bson file contains entries for those operations, each with a timestamp. You can use OplogLSN.sh to capture the first and last operation timestamps or convert it to JSON file for manual inspection, as shown in the previous step.

4. Run MongoDB Restore Utility: After you have the necessary timestamps, use the mongorestore utility to restore the selected collections from the dump to the target MongoDB instance:

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

5. Start MongoDB CDC Extract: Start the MongoDB CDC Extract process from the first operation timestamp (LSN position) extracted from the oplog.bson file. This will ensure the CDC Extract begins capturing operations that occur after the dump process started.

6. Configure the MongoDB Replicat with the generated CDC trail file and set the oplogReplayLastLsn property to the last operation timestamp from the oplog.bson file. This ensures the Replicat runs in oplog-replay mode, avoiding any collisions. Once the last timestamp is processed, it continues in normal mode. This configuration guarantees precise initiation, with no data loss or duplication, and eliminates the need for costly collision handling in the Replicat.

How can I run initial loads from Snowflake to Oracle Database?

1. Create a change data capture extract (from source Oracle Database).

2. Get SCN from the source database.

3. Create an initial load extract (from source Oracle Database).

4. Create a distribution path for CDC Extract.

5. Create a distribution path for initial load Extract.

6. Create a Replicat for the initial load (targeting Snowflake).

7. Create a Replicat for the change data capture replication (targeting Snowflake).

What should I do to fix “Exception: net.snowflake.client.jdbc.SnowflakeReauthenticationRequest: Authentication token has expired. The user must authenticate again.” error in Oracle GoldenGate Snowflake replication?

This error occurs when there are extended periods of inactivity. To resolve this issue, you can set the JDBC parameter CLIENT_SESSION_KEEP_ALIVE to force the database user to login after a period of inactivity.

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

Does Oracle GoldenGate and OCI GoldenGate support DDL replication to Snowflake?

Oracle GoldenGate can be configured to propagate source DDL changes to target Snowflake tables. Automatic schema evolution is the capability to detect, manage, and apply changes to a database schema, such as tables, columns, indexes, or relationships, without requiring manual intervention. Automatic schema evolution supports detecting new objects and metadata changes, then automatically generating target DDL for schema evolution.

For initial load, it can create or replace target tables.

For CDC Replicat, it can create or modify target tables during ongoing apply. For more details, refer to Oracle GoldenGate documentation.

Can I use Oracle GoldenGate and OCI GoldenGate for Apache Iceberg replication?

Yes, Oracle GoldenGate supports real-time data replication into Apache Iceberg. Oracle GoldenGate uses Apache Iceberg Java API for open Apache Iceberg Lakehouses. Oracle GoldenGate supports Oracle AI Data Catalog, Amazon Glue, Polaris, Nesti, Hadoop, REST catalogs.

Can I use Oracle GoldenGate and OCI GoldenGate for real-time data replication to Apache Iceberg tables on OCI Object Storage?

Yes, Oracle GoldenGate and OCI GoldenGate can be configured for real-time data replication to Apache Iceberg tables stored on OCI Object Storage through OCI Object Storage S3 API endpoint. Refer to Building a Real-Time Apache Iceberg Lakehouse on OCI Object Storage with OCI GoldenGate for more details.

Does Oracle GoldenGate and OCI GoldenGate Apache Iceberg replication support both merge on write?

Yes, Oracle GoldenGate and OCI GoldenGate support merge-on-write for Iceberg tables managed by Snowflake, Google BigQuery, and Databricks. On these platforms, GoldenGate uses the target platform’s compute resources for compaction.

How does Oracle GoldenGate and OCI GoldenGate can handle primary key updates in parquet tables on OCI Object Storage?

Oracle GoldenGate and OCI GoldenGate handle primary key updates in three modes. This behavior is controlled by adding gg.handler.name.format.pkUpdateHandling to the Replicat properties file. Supported values include abend, update, and delete-insert. Abend is the default behavior. The Replicat fails when a primary key update is detected and logs the error in the report file. Update treats the primary key update like any other update operation. Use this setting only if you can guarantee that the primary key is not used as selection criteria.

Delete-insert replicates the primary key update as two records: one with the before image, marked as a delete, and one with the after image, marked as an insert.

To use delete-insert, the Extract process must capture uncompressed change data records, meaning all columns are written to the trail file.

To generate uncompressed records, use LOGALLSUPCOLS for Oracle Database sources and COMPRESSUPDATES | NOCOMPRESSUPDATES for non-Oracle databases.

For example, when replicating to OCI Object Storage, set gg.handler.<gg.target value>.formatpkUpdateHandling=delete-insert` to replicate primary key updates as one delete record with the before image and one insert record with the after image.

How can I replicate Oracle DATE and TIMESTAMP columns to parquet tables stored on OCI Object Storage with Oracle GoldenGate?

Oracle DATE and TIMESTAMP columns are replicated as strings by default when no explicit mapping is configured. Without proper mapping, downstream engines will not recognize these columns as date/time types, making date arithmetic, range filtering, and time-based partitioning impossible without explicit casting. The enableTimestampLogicalType property enables mapping of Oracle DATE and TIMESTAMP columns to the Avro timestamp-micros logical type, which represents values as microseconds since epoch, the correct representation for analytical and data lake workloads.

In the Oracle GoldenGate Cloud Object Storage Replication, source DATE and TIMESTAMP types are mapped to Avro files (including Parquet, Iceberg and Delta) as STRING by default.

To replicate source DATE and TIMESTAMP types as timestamp-micros logical type to Avro files (including Parquet, Iceberg and Delta), set gg.handler.<gg.target value>.format.enableTimestampLogicalType to true.

When timestamp logical type enabled, gg.format.timestamp is also required. For example: gg.handler.oci.format.enableTimestampLogicalType= truegg.format.timestamp=yyyy-MM-dd HH:mm:ss.SSSSSS

How can I improve Oracle GoldenGate OCI Object Storage replication performance?

The Oracle GoldenGate Cloud Object Storage Replication performance can be tuned using two key features: Replicat type and GROUPTRANSOPS parameter. In addition to the Replicat type and transaction grouping, the size of the files produced by the Replicat directly affects throughput and should be tuned in conjunction with the other settings. Oracle GoldenGate Distributed Applications and Analytics provides two different replication modes: Classic Replicat and Coordinated Replicat.

Classic Replicat is a single-threaded process that applies the messages to target cloud storage services. Coordinated Replicat is a multi-threaded process where multiple threads read the OGG trail file independently and apply transactions in parallel. The Oracle GoldenGate Cloud Object Storage Replication process optimizes processing with transaction grouping. The GROUPTRANSOPS parameter groups multiple small transactions into a single larger transaction applied to cloud storage targets. GROUPTRANSOPS is configured in parameters file. By default, GROUPTRANSOPS is set to 1000. You can increase up to 20000 for better performance.

For example: GROUPTRANSOPS 20000

How can I set the file size in Oracle GoldenGate and OCI GoldenGate Google Cloud Storage replication?

Oracle GoldenGate replicat creates a file in the local file system and keeps it open until a rollover condition is met or triggered by a metadata change event from the source (like DDL change). Users can control file rollover by using replicat properties. Max File Size controls the file sizes. By default, file sizes are configured to 1 GB; but it can be configured as needed. When the max size is reached, file is closed, and a new file is generated. For more details, see Configuring the File Writer Handler in Oracle GoldenGate for DAA documentation.

Does Oracle GoldenGate and OCI GoldenGate supports partitioning with parquet file replication to Google Cloud Storage?

Oracle GoldenGate and OCI GoldenGate supports creating partitioned files in target object storage buckets. Partitioning improves downstream pruning and query performance, but over-partitioning increases directory/file counts and amplifies the small-file problem.

To use partitioning, data must be partitioned by the table at the highest level. This is done using the pathMappingTemplate property and it should be set to the fully qualified table name.

It will create directories within the container/bucket based on the fully qualified source table name. For example: gg.eventhandler.<gg.target value>.pathMappingTemplate=${fullyQualifiedTableName}

For creating partitions, gg.handler.<gg.target value>.partitioner.<fully_qualified_table_name> is used. This property can be used with template keyword such as ${columnValue[column_name]} or constant string values to define the partition path structure.

Does Oracle GoldenGate and OCI GoldenGate support DDL replication to parquet files on Azure Data Lake Storage (ADLS)?

Oracle GoldenGate and OCI GoldenGate ADLS replication propagates source DDL changes automatically to the files generated. Alternatively, EVENTACTIONS can be used to control the Extract/Replicat behavior in case of a DDL operation in the source database.

If Oracle GoldenGate extract captures a Create Table event from the source database, the Replicat will create a new file with the table name from the Create Table event in the target cloud object storage bucket/container.

If Oracle GoldenGate extract captures an Alter Column/Drop Column event from the source database, the Replicat will create a new file reflecting the updated source table definition.

If Oracle GoldenGate extract captures a Truncate event from the source database, you can configure the Replicat to roll the data file on Truncate event by setting:

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

This property is set to false by default and the Replicat does not roll the file in Truncate event. Oracle GoldenGate extract captures a Drop Table event from the source database, this has no impact on the target file system.

How does Oracle GoldenGate and OCI GoldenGate handle source Oracle NUMBER data type while replicating to parquet files on Azure Data Lake Storage (ADLS)?

Oracle NUMBER is a variable-precision decimal data type that can represent integers and fixed-point decimal values with up to 38 digits of precision.

If a column is defined without explicit precision and scale (for example, NUMBER), Oracle can store values with varying scale across rows, and in some replication/schema-generation scenarios the formatter may not be able to deterministically derive a single precision/scale for the target schema. As a result, mappings to Avro/Parquet often use a conservative decimal representation unless you explicitly configure precision and scale to match the source column definitions.

gg.handler.<gg.target value>.enableDecimalLogicalType is the master switch for decimal logical type mapping. When set to true, it instructs the Avro formatter to map Oracle NUMBER columns to the Avro decimal logical type (bytes with logicalType: decimal) instead of the default mapping which writes numbers as plain Avro numeric primitives or strings.

When precision/scale can’t be deterministically inferred, the formatter typically chooses a conservative Avro decimal definition (high precision and scale) to avoid precision loss. This can lead to downstream consumers seeing values expressed with an unnecessarily large scale (for example, apparent trailing fractional digits).

To align the target schema with known, consistent source definitions, especially for financial data (balances, prices, amounts):

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

What ADLS authentication methods are supported by Oracle GoldenGate and OCI GoldenGate?

Oracle GoldenGate and OCI GoldenGate supports Access Keys, Shared Access Signature and Azure Entra ID.

Oracle GoldenGate supports Amazon S3 Tables?

Yes, Oracle GoldenGate supports real-time Apache Iceberg replication to Amazon S3 Tables through Amazon S3 Table REST Catalogs.

Does Oracle GoldenGate and OCI GoldenGate support multi part uploads to Amazon S3?

Yes, enabling the Amazon S3 Multipart Upload feature allows uploading the large files to Amazon S3 by splitting them into small parts that can be uploaded independently and in parallel. This feature solves the already known Amazon S3 limitations, such as the single upload of 5GB+ size objects. Once all the file parts are successfully uploaded, a request is made to Amazon S3 to assemble them into a single object. To use this feature you need to enable gg.eventhandler.s3.multipartEnabled=true in Amazon S3 replicat.

Does Oracle GoldenGate and OCI GoldenGate supports partitioning with parquet file replication to Google Cloud Storage?

Oracle GoldenGate and OCI GoldenGate supports creating partitioned files in target object storage buckets. Partitioning improves downstream pruning and query performance, but over-partitioning increases directory/file counts and amplifies the small-file problem.

To use partitioning, data must be partitioned by the table at the highest level. This is done using the pathMappingTemplate property and it should be set to the fully qualified table name. It will create directories within the container/bucket based on the fully qualified source table name. For example: gg.eventhandler.<gg.target value>.pathMappingTemplate=${fullyQualifiedTableName}. For creating partitions, gg.handler.<gg.target value>.partitioner.<fully_qualified_table_name> is used.

This property can be used with template keyword such as ${columnValue[column_name]} or constant string values to define the partition path structure.

How is OCI Database Migration Service priced? (Factual)

The first 183 days (6 months) of a migration are provided at no charge, except in cases where the migration runs for more than 60 days without any data transfer.

Which sources and targets does OCI Database Migration Service support? (Factual)

Currently Oracle and MySQL homogeneous migrations are supported. The sources can be on-prem, on other clouds or in OCI. The targets need to be in OCI. Oracle is supported from 11g (11.2.0.4), 12c (12.1.0.2,12.2.0.1),19c,21c and all subsequent Oracle Database releases. MySQL: 5.7 and 8 versions. More details can be found in the next URL.

What are the migration types supported by OCI Database Migration Service?

Offline logical migration: One-time copy of the database, requires applications to be offline during the migration process. Online logical migration: Initial copy of database followed by change data capture during migration. Applications can stay online during the migration process.

During an oracle migration what objects and schemas are excluded by default?

The following object types are always excluded:

• GoldenGate administrators identified in DBA_GOLDENGATE_PRIVILEGES, including ggadmin and c##ggadmin users.
• If target is Autonomous Data Warehouse Shared Infrastructure: CLUSTER, DB_LINK, INDEXTYPE, STATISTICS.
• If target is Autonomous Data Warehouse Dedicated Infrastructure, Autonomous Transaction Processing Shared or Dedicated Infrastructure: CLUSTER, DB_LINK, STATISTICS
• All other targets: STATISTICS

The following schemas are excluded by default:

• Schema is marked as ORACLE_MAINTAINED in SYS.DBA_USERS on the source or target database
• Schema is marked as excluded from export in SYS.KU_NOEXP_VIEW on the source database
• Schema GGADMIN and C##GGADMIN

What OCI resources are required for a migration?

• Vault and key to Store connection secrets.
• Depending on the transfer medium selection Object storage or file system
• A connection per source and target, some scenarios might require more than one connection per source.
• An Assessment as preparation for the migration.
• The Assessment takes care of the Migration creation
• For online migrations an OCI GoldenGate deployment is required, but this is entirely managed by the service.
• An OCI target

Where is OCI GoldenGate available?

• Oracle Cloud: OCI GoldenGate is available in all public cloud, government, and dedicated cloud regions in OCI. See https://www.oracle.com/cloud/distributed-cloud/service-availability/ for more information.
• Azure: OCI GoldenGate is available on Azure on Oracle Database@Azure. See https://docs.oracle.com/en-us/iaas/Content/database-at-azure/oaa_regions.htm for more information.
• Google Cloud: OCI GoldenGate is available on Google Cloud on Oracle Database@Google Cloud. See https://docs.oracle.com/en-us/iaas/Content/database-at-gcp/get-started-regions.htm for more information.