Oracle Goldengate Technology

After Oracle corp. acquiring Goldengate software there is a lot of buzz about Oracle Goldengate and it is one of the hot topics at Oracle open world 2010.Oracle Goldengate can be used as a replication tool, ETL, and even as a DR solution.

Oracle Goldengate (Golden Gate) is probably the best replication software and it is very easy to configure and deploy it in large scale environment. Here are some of the things you need to be aware of:

•  All Golden Gate configuration files are ascii text based files. Very easy to make changes but it is prone to human errors in an environment having many DBA's working on it.
•  In order to use parallel apply threads, Golden Gate breaks down the database transaction into multiple transactions based on the hashing key defined for range split of the data. So, transactional consistency will not be guaranteed during real time but there won't be any data loss, but make sure that your application can tolerate this.
• If there is no primary key or unique index exists on any table, Golden Gate will use all the columns as supplemental logging key pair for both extracts and replicats. But if you define key columns in the Golden Gate extract parameter file and if you don't have the supplemental logging enabled on that key columns combination, then Golden Gate will assume missing key columns record data as "NULL", which is a huge deal, and this will introduce logical data corruption on the target.
•  Golden Gate started supporting bulk data loads with their 11.1 release but any NOLOGolden GateING data changes will be silently ignored without any warning.
•  Golden Gate doesn't support compression on the source database.
•  Golden Gate does support DDL replication but it is not easy to do selective DDL replication, it replicates every DDL that happens on the source database which is not desirable for some customers.
• Tables being replicated to on the target can also be written to by any other application or DBA's.
• Golden Gate supports ignoring data conflicts for updates after the first instantiation of the target database until it catches up. But it is very easy to forget turning off that parameter and any updates being lost will not be alerted by Golden Gate.
• Golden Gate still works by reverse engineering the Oracle redolog. This may not be totally true with Golden Gate 11, but I expect Golden Gate to interpret Oracle redo more directly in later versions of 11 or 12.
• Golden Gate dynamically decides to change the key columns that form the supplemental logging based on the state of primary key (i.e. in VALIDATED or NONVALIDATED state), which can introduce data corruptions on the target databases as the expected key columns data is missing in the trail files and they will be set to NULL. They now have the patch available for this, you can set "_USEALLKEYCOLUMNS and ALLOWNONVALIDATEDKEYS" parameters in GLOBALS file to get around this problem.