Oracle GoldenGate

Replication

Business Continuity

Query offloading

Requires a specialized skillset

Replicates data without "missing" items. This is key, as there was initial concern that with the amount of tables and columns involved, certain items were bound to be "missed", though we have not seen this (outside of an anomalous server crash incident that wasn't due to GG).

Replicates data in real-time. Proof of concept for GG was intuitive for end users, as the data is immediately available. There are no "jobs" or "interfaces" that need to be run: the data is immediately available on the target database for viewing

GG is able to modify data "in transit", which can save loads of time if you were to need to instead modify large amounts of data after it is synchronized to the target database. As one would expect, this is seamless with low complexity modification, by can become untenable with larger blocks of data (e.g. CLOBs).

GG can sometimes lag behind in synching large objects (i.e. CLOBs and BLOBs) on tables, which is odd because we are using GG on an Oracle database with an Oracle software suite. It's definitely possible to use GG on non-LOB columns, and we do, but it is best used for non-LOB columns, just based on personal experience.

When using GG, it is key to separate the replicat groups into manageable sizes. This can be somewhat burdensome, as maintenance will increase with each new replicat group. If tables are large enough, they need to essentially be their own group.

Sometimes, replicat groups need to be grouped by parent and child (if using in a normalized db). This again increases maintenance due to more groups existing. This will be especially true for large tables that are partitioned with foreign key constraints on child tables.

As the product under the Oracle umbrella, it perfectly and natively supports the Oracle database very well.

For the standard scenario and use cases, the configuration is straight-forward (in our case uni-direction copy from source to target).

It is robust and the performance meets our SLA, even for a large amount of data volume.

The error report is not only detailed but hits the right points, so trouble shooting is easy.

The metrics UI is another product that should be purchased separately, with high price, we use open source Grafana as a replacement.

Documentation can be improved. Sometimes [it is] not so easy to find the correct information quickly.

Documentation is easy to follow

Downtime seems very minimal

Able replicate in real-time

Expensive, considering we were going to use Active Data Guard.

A lot of memory is being used.

No UI

OGG can be used and integrated with heterogeneous databases as well as homogeneous databases.

OGG is easy setup as well as easy learning curve

OGG supports large databases

OGG support many uses cases (topologies) such as unidirectional replication, bidirectional, peer-to-peer, Broadcast, Cascading replication etc.

OGG can be used not only for CDC (change capture), can be used to full load

Expensive

Require resources such as OGG script developer and SME

I was able to find what I needed, but it took longer than I think it needed to. The system was navigable, but not until I had training on it. Before that I was clueless on how to find anything.

It allows the replication in real time from the Oracle database in RAC to the contingency database, through the immediate replication of the data in the redo logs, without the need to wait for them to be written at the level of the archive logs.

You can have multiple different data sources coming into this Oracle GoldenGate. You are not limited to only Oracle databases.

The time that it takes to implement Oracle GoldenGate. Because you can have multiple databases going through it it can take a long time to set it up.

It was more complicated than it needed to be. Without the training I feel that it isn't intuitive. I think maybe the structure should be reinvented so that it is more intuitive.

GoldenGate replication is only for databases, it would be nice to use it across file and folders

Integrates with Oracle databases and Oracle database servers (particularly exadata - engineered systems)

Easy to define source and destination data attributes and configuration

Robust error reporting

More integration with traditional Oracle products such as SQL*plus

GUI

More transparent integration with OEM

More standard error reporting similar to traditional Oracle products

Flexibility to migrate data.

Fast transactions between source and target databases .

Easy to analyze problems when occur.

Good for disaster recovery and data protection database.

Oracle GoldenGate Studio is expensive, and you can use Grafana instead.

Character set problems when migrating database.

No Downtime during System Migration. Replicating data onto other servers in preparation for a system migration does not result in any downtime.

Initial setup of Oracle GoldenGate is easy and straightforward. Instructions are precise and simple to follow.

Thorough and Insightful Documentation. All troubleshooting and tuning issues are well-known by the community, and hence are well-documented online.

Lack of Simple UI for Non-Technical Users. It would be nice to have an option to toggle simpler, and less advanced options to make it easier for non-technical users to understand what Oracle GoldenGate is.

Lack of Variety of Performance Metrics. Would prefer more detailed performance metrics to be offered out-of-the-box.

Some Features Won't Always Run as Expected. We have sometimes faced issues when features don't run as they are used to. They will be working at times, but there is the occasional failure in streaming.

When it works, it works great

Whenever we have to do a data subset from prod to lower environments its almost impossible for GG to find its checkpoint... we had lots of difficulty with restarting GG process after the refresh.

Oracle GoldenGate has been able to replicate all of our data in different servers and locations.

It also supports large databases

It supports a high volume of daily transactions of our sales.

In certain cases, we consider how well GoldenGate is able to help us interconnect our main database directly to our backup system (we use actifio for it).

We have some difficulties to cut-off our size of main database, so maybe Oracle GoldenGate could make it easier by providing a function to shrink our data safely.

We also interconnected with our partners to share some data, specific and limited fields only, through third party services, using messaging system (ISO 8583, XML and JSON). It would be great if GoldenGate also provided such a function.

Replication of data.

Easy of set up.

Notification of status.

Improvement of collision management.

Log dump features could be improved for better ease of use.

Data replication to keep our data up-to-date and used for reporting purposes.

Data migration with zero downtime.

Data sync between two data centers to keep the system active/active with load balancing.

We're facing issues during bi-directional replication. The detailed data quality issues alerts may be helpful.

Oracle's new AutoCDR (conflict detection and resolution) feature makes setting up active-active replication fairly easy. We were able to setup active-active replication using the AutoCDR feature in a very short time.

We had plans for separating reporting and ingestion from our primary DW system. This system generates an excess of 1TB of redo during ingestion. GoldenGates coordinated replicate helped us achieve this almost impossible task with ease.

In my previous workplace, for a large telecom company, we had to publish data from the store of records as a service. We used GoldenGate BigData adapters to replicate data to a Kafka endpoint.

For quick application failovers, we use GoldenGate Active-Passive replication with connection failover defined in the WebLogic connection settings.

There are certain challenges using the product when the redo generation is in excess of about 120G per hour.

For large transaction (more than 10 million records per commit), extract get slower. Some other replication tools do such activities better.

Ability to recreate large transaction without breaking the transaction into individual statements may help. There are ways to make this transaction faster, but having the ability to replicate a statement as it was issued on the source may be helpful in some cases.

GoldenGate, using CDC, moves data between databases and database technologies to enable near real-time propagation.

GoldenGate can transform data as it moves from tables in the same or different databases.

GoldenGate can move data between database platforms.

We need more rapid support for bug mitigation.

GoldenGate's API needs to allow for streaming from Oracle's cloud databases where we don't have access to the OS.

Realtime replication and zero data loss.

Less lag and more reliable.

No downtime for our primary database.

GUI could use a little improvement.

Initiating integration and configuring source and target is easy.

Easy integration with different types of DB.

Availability to synchronize specific tables/DB schemas.

No clear documentation for some points like sequence synchronization.

GoldenGate is tightly integrated with Oracle databases and supports all features like encryption, LOBs, compressions etc.

GoldenGate is very flexible, you can customize it as per your requirement. Whether it is high transaction DB or a DR site, it can work anywhere.

We can dump data in multiple formats with big data adaptor like kafka, hdfs, xml etc.

We can achieve high throughput by splitting extracts and replicats. Also from integrated capture and replication it is so smart that it spawn parallel process based on the load.

Goldengate is very useful in cross platform migration.

Memory consumption of extract is exponentially high, sometimes extract restart consumes so much memory that it impact the current application connections.

There are so many bugs in the system for dumping data via xml or other format like hdfs. Data corruption is so frequent that we wrote our own scripts to detect and repair xml corruption. As always we didn't get proper support from Oracle on this issue.

For active-active replication on busy systems, online DDL change can sometimes cause data discrepancy.

With integrated capture creating index on big table is a headache even thought you are creating with via gg user. Extract starts get lagging even after skipping the DDL by gg user in param file. This was not the case with classic capture.

Data replication in real-time.

Fault tolerance.

No data loss.

Better documentation would be appreciated.

The unidirectional and bidirectional capability of data replication.

Data quality assurance including both DDL & DML replication.

Validation and data quality measurement facility available through Veridata.

Also helps in zero downtime based migration.

The data validation functionality is built-in and part of auto configuration instead of a separately licensed product.

Easy software installation

Quick modifications

Alternative to syncing data

Initial Load Difficulties

Log reviewing

Ease of use

Support from Oracle on the product

Business presence and reputation

Oracle Support Reps' knowledge lacking for issues and problem SR's

Oracle docs for common issues

Integration with older products EOL

Supports both homogeneous and heterogeneous replications.

Supports DDL replication if both source and target databases are Oracle.

Supports multiple replication topology such as unidirectional, bi-directional, cascading, peer to peer and multicasting.

Can interface with JMS and Big Data Systems.

Like most Oracle products, it is quite expensive.

Too many tables in single replication channels creates performance bottlenecks. You have to split your tables into multiple channels.

It provides continuous capture and delivery of data from source to target due to its real-time data feed feature.

It maintains the reliability and accuracy of transactional data.

It is very easy to install.

Complete data recovery is possible in case of failures.

The product is somewhat expensive to most of the companies.

Active-active replication

Simple setup

Reliable transactional replication

Great support

complex conflict resolution

speed of replication

integrity constraint errors