Comparing Oracle Data Guard vs. Active Data Guard for EBS Environments
By Steven Chan-EBS Development-Oracle on Oct 10, 2008
[Nov 6 Update: Our High Availability team has suggested some additional uses for Active Data Guard in E-Business Suite environments. Article updated with those additional use cases.]
Given the number of questions I've fielded about Active Data Guard through other channels, it was inevitable that my recent article about strategies for handling EBS reporting loads would prompt questions about its compatibility with the E-Business Suite.
The answer to this deceptively-simple question is only meaningful if you understand what's happening behind the scenes when users log into the E-Business Suite. This article compares the operational implications of using Oracle Active Data Guard versus Oracle Data Guard in E-Business Suite environments.
What Is Active Data Guard?
Active Data Guard is a new option for Oracle Database 11g Enterprise Edition. From its official product literature:
Oracle Active Data Guard enables read-only access to a physical standby database for queries, sorting, reporting, web-based access, etc., while continuously applying changes received from the production database.
I've emphasized the read-only nature of the replicated database because of this feature's implications for E-Business Suite environments. But first, a little background.
Behind the Scenes: Logging Into the E-Business Suite
In the E-Business Suite world, every user is assigned one or more responsibilities. These responsibilities govern the E-Business Suite applications (i.e. menu functions) and data that a given user can access. For example, as a manager, I might be assigned responsibilities that allow me to review my employees' compensation and approve their expense reports. I'm also an employee, which means that I can review my own payslips and file new expense reports.
Every time anyone logs into a running E-Business Suite instance, the following things happen:
Their authenticated credentials are checked against their assigned E-Business Suite responsibilities.
A user session is created in the E-Business Suite database.
- All activities are logged for audit and tracking purposes, even queries against existing data.
This level of security prevents E-Business Suite unauthorized users from, say, assigning stock options to themselves. It also provides an audit trail in case someone abuses their position by attempting to cook the books in the midst of a financial industry meltdown.
This also applies to the use of external reporting tools like Oracle Discoverer. Discoverer users must log into the E-Business Suite instance, which checks their assigned responsibilities to prevent users from running reports against data that they're unauthorized to view.
So What About Active Data Guard?
Putting this together:
- Active Data Guard makes a read-only replication of a given database.
- Even the simple act of logging into an E-Business Suite database requires write access.
Therefore, it may be possible to use Active Data Guard to replicate an E-Business Suite database, but there's not much benefit in doing so if your objective is to offload reporting functions from your production environment. After all, if you have an Apps read-only database that you can't access, it's not all that useful for creating standalone databases for reporting purposes.
Nov 6, 2008 Update: Note that this limitation precludes the use of Active Data Guard if you're interested in creating a reporting instance that requires read-write EBS access. However, nothing stops you from using Active Data Guard as part of your failover strategies for your E-Business environments. For example, you can use Active Data Guard to make a read-only copy of your production E-Business Suite environment; in the event of failover, that environment would fail over to the Active Data Guard database thus opening it to normal read-write EBS operations.
If course, this means that you might ask, "Besides that failover scenario, why do I care about Active Data Guard if I can't really use the physical standby in read-only mode? Two possible ways that the Active Data Guard standby could still provide incremental value compared to a regular physical standby are:
- If you use any read-only reporting scripts or packages, you can now direct those to the Active Data Guard physical standby.
- Another component of the Active Data Guard option is that it enables RMAN fast incremental backups on the Active Data Guard physical standby (i.e. basically supporting RMAN block change tracking file on the physical standby). This is another potential way of offloading some processing from the production database to the standby database.
What Works for Reporting Instances: Data Guard Redo Apply With Physical Standby Databases
As an alternative to Active Data Guard for creating reporting instances, we support the use of Oracle Data Guard. From its official product literature:
Oracle Data Guard is the management, monitoring, and automation software infrastructure that creates, maintains, and monitors one or more standby databases to protect enterprise data from failures, disasters, errors, and corruptions.
Data Guard maintains these standby databases as synchronized copies of the production database. These standby databases can be located at remote disaster recovery sites thousands of miles away from the production data center, or they may be located in the same city, same campus, or even in the same building. If the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, thus minimizing the downtime associated with the outage, and preventing any data loss.
Specifically, we support the use of Oracle Data Guard Redo Apply with physical standby databases for E-Business Suite environments. We do not support the use of this feature with logical standby databases due to the lack of Oracle LogMiner support for certain datatypes used in the E-Business Suite.
Our Maximum Availability Architecture team has put together some excellent papers describing various certified Data Guard configurations for Oracle E-Business Suite Release 11i and 12. For more details, see:
- Business Continuity for Oracle Applications Release 12 on Database Release 10gR2 (MetaLink Note:452056.1)
- Transitioning E-Business Suite to the Maximum Availability Architecture with Minimal Downtime: E-Business Suite 11 i .10.2 and Database 10 g R2 (PDF, 569K)
- Maximum Availability Architecture and Oracle E-Business Suite Release 11i (Metalink Note 403347.1)