By Markus Weber on Jan 15, 2013
Listen to this recently recorded podcast to
hear Nick Wagner from Oracle GoldenGate product management team, and Joe
Meeks from Oracle Database product management team discuss how to use
GoldenGate for maximum availability and the new features of GoldenGate
11gR2 that strengthen its high availability solutions.
This podcast is a little recap of the great live webcast we hosted back in December 2012. In case you missed it, make sure to watch it on demand, at your convenience.
Great questions were asked during that webcast, and our expert Joe Meeks was able to answer plenty of them. Here are some great examples of that:
Q: What is the difference between the logical standby and GoldenGate ?
Joe: Data Guard logical standby (SQL Apply) is an included feature of Oracle Enterprise Edition. It utilizes all of the same transport and role management features used by Data Guard Redo Apply (physical standby database), but it uses SQL to apply changes to a standby database that is open read-write (physical standby uses media recovery). The focus SQL Apply is as a feature of Data Guard for database rolling upgrades. The process begins with a primary and Data Guard physical standby. The standby is converted to a logical and upgraded. Production is then switched to the standby and the original primary (now a standby) is upgraded. From 11g onward we use the Transient Logical Rolling Upgrade Process - this results in the upgrade concluding with a primary and physical standby both at the new version. SQL Apply is only used for replication across version
GoldenGate is our comprehensive logical replication product. It is meant to address all advance replication needs and is the preferred solution for requirements such as reporting offload where the target database must be open read-write, bi-directional and multi-master replication, zero downtime upgrades/migrations, data integration, etc.
Q: What is it that Oracle Data Guard can do that Oracle GoldenGate can't ?
Joe: This is a backward way of asking this question . GoldenGate is a comprehensive, feature rich replication product. It can do many things Oracle Data Guard can't.
Data Guard is very focused - simple physical replication. Unlike GoldenGate, it maintains an exact physical replica of the primary (backups are interchangeable), it has no datatype or other restrictions to consider, it uses standard Oracle Media Recovery so has very high performance for all workkloads, it has advanced corruption protection - lost-write protection and automatic block repair. It offers both Synchronous (a guarantee of zero data loss) and Asynchronous replication.
Data Guard's primary goal is to provide the simplest, fastest, most complete data protection for Oracle Database, period.
GoldenGates primary goal is to provide the most feature-rich replication solution for the broadest possible range of requirements.
My recommendation is to first understand your requirements and preferences, then chose the right tool for that job.
Q: How can we use the new DBFS in conjunction with Oracle Data Guard and GoldenGate ?
Joe: DBFS is useful in a GoldenGate configuration to store the GoldenGate trail files and checkpoint files in DBFS to provide recoverability and failover capabilities in the event of a system failure. Using DBFS is fundamental to the continuing availability of the checkpoint and trail files in the event of a node failure. Ensuring the availability of the checkpoint files is essential to ensure that, after a failure occurs, the Extract process can continue mining from the last known archived redo log file position and Replicat processes can start applying from the same trail file position before a failure occurred. Using DBFS allows one of the surviving database instances to be the source of an Extract process or destination for the Replicat processes.
From a Data Guard perspective - anything that is in DBFS is protected just as any other database data is protected. So DBFS provides a way to have Data Guard protect file system content for you as well that would otherwise be external to the Oracle database.