GoldenGate - Ideal Synchronization for Low/Moderate Data Complexity
Overall Satisfaction with Oracle GoldenGate
GoldenGate (GG) is being used by the utility company I work
for in various areas.
Data Analytics is the main use of GG at the moment. Normally, the sheer level of database hits
required by our daily Business Intelligence reports would place a heavy burden on
the disk groups in our core ASM; however, with GG, we are able to seamlessly
replicate that data in real-time into a separate database using separate
resources. By doing this, we are able to
alleviate potential bandwidth issues posed by our BI group’s database querying. It should be noted that GG does not require
all tables to be replicated: we only replicate under 100 of the thousands of
tables in the main databases. Our GG
database is not normalized, so we are essentially combining disparate databases
into one, which has its advantages and disadvantages.
Another use we currently have for GoldenGate is on a
large project level. As part of a data
conversion effort, we are using GoldenGate to replicate data into a separate
database in real-time. This will allow
us to save 12+ hours during our conversion, as well will not need to execute an
RMAN backup in order to move data into our target database. In other words, we are directly replicating
data into our target database, so right when we are ready to switch
servers/databases for the go-live of our project, we will be ready to
immediately start to convert data.
- 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.
- On a project level, by allowing us to begin our data conversion process 12 hours earlier, we are able to save in off-time losses and increase customer satisfaction, as we will be on line a whole half day earlier.
- By being able to replicate data to cheaper performing resources, we are able to save money by not having to duplicate the costs of our main resources.
- GG knowledge is somewhat specialized, so it does require a human resource(s) to be employed that knows how to maintain it. This is not a full time job, but it is absolutely necessary.
Do you think Oracle GoldenGate delivers good value for the price?
Yes
Are you happy with Oracle GoldenGate's feature set?
Yes
Did Oracle GoldenGate live up to sales and marketing promises?
Yes
Did implementation of Oracle GoldenGate go as expected?
I wasn't involved with the implementation phase
Would you buy Oracle GoldenGate again?
Yes