[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:
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
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:
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:
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: