Re: HA Architecture Plus + Reporting Purposes

From: Gaja Krishna Vaidyanatha <>
Date: Thu, 8 Dec 2011 09:53:47 -0800 (PST)
Message-ID: <>

Dear List,
I totally agree with Tim on his assertion about how RAC is marketed vs. the reality. On a more philosophical note, the first question I'd ask is whether or not a given application is designed for RAC and what %age of elapsed time is the "cluster and interconnect-related waits". We usually use a rule-of-thumb of no more than 10% overhead for the appropriate applications having the right requirements for RAC. In the end it usually boils down to two things:
  1. Cannot scale beyond the largest single SMP server available for use, thus need a cluster of nodes - RAC
  2. Redo log files are the biggest bottleneck, solid state technology has not done the trick and thus need a cluster of nodes to spread the bottleneck - RAC

I observe this a lot in my world - people who put the cart before the horse. The decision to go with RAC is already made before even verifying and validating whether the application will be able to standup straight with production load in a RAC environment. And the rationale is usually - We need high levels of HA. And then people figure out in production, that performance is a huge pain and then discover that the "cluster and interconnect waits" are for example - 68%-72% of elapsed time. No point blaming RAC then, the application was just not designed for RAC and you just threw RAC at it.

HA (and very high levels of HA) can be achieved for non-RAC certified applications by deploying Active Data Guard and Golden Gate in a simple single instance configuration. This combined with some simple yet intelligent traffic management using load balancers (e.g. F5 GTMs and LTMs) will do the trick. This is especially relevant in today's world, as we start to deploy Oracle databases in a geographically dispersed Cloud (think Amazon EC2's Availability Zones within a given Region for HA and Availability Zones across Regions for DR). Now we are talking about multiple, geographically dispersed data centers and the design for HA is a lot different. Tim is also right on the money about HA & DR, they are not much different. In my mind, the difference between HA and DR is the distance to the DR data center from the HA data centers. That's it!

Having said all of the above, I concur with Tim on recommending Options #1 & #2 for reporting, subject to the following conditions:

  1. Option #1 with "Active Data Guard" instead of "Data Guard" if the reporting component of your applications do not manipulate session-level temporary objects (global temporary tables)
  2. Option#2 with "Golden Gate" if the reporting component of your applications manipulate session-level temporary objects (global temporary tables) -- Currently ADG does not support manipulation of GTTs when the database mode is "Read Only With Apply".   May the force be with you :)))



Gaja Krishna Vaidyanatha,
CEO & Founder, DBPerfMan LLC

Phone - +1-650-743-6060 Insights:Tales of the Oak Table - Co-author:Oracle Performance Tuning 101 -

 From: Michael Dinh <mdinh_at_XIFIN.Com> To: "''" <>; "" <>; ora-apps-dba <>; oracle-l <>; "" <> Sent: Wednesday, December 7, 2011 1:24 PM Subject: RE: HA Architecture Plus + Reporting Purposes  

I have not used DG for reporting purposes because the standby created is primarily use for backup since the servers and storage is not at the same capacity as standby.

However, with redo at 200M and 100-150 log switches per day, standby was able to catch up after 3 days of down time applying logs in less than a day.

That's a good and fuzzy feeling.

Golden Gate will come at an additional cost.

HTH Michael Dinh

Disparity Breaks Automation (DBA)

Confidence comes not from always being right but from not fearing to be wrong - Peter T Mcintyre  
-----Original Message-----

From: [] On Behalf Of Tim Gorman Sent: Wednesday, December 07, 2011 1:14 PM To:; ora-apps-dba; oracle-l; Subject: Re: HA Architecture Plus + Reporting Purposes

Options 1 and 2 are the only viable HA/reporting solutions in your list.

Despite what Oracle asserts in their marketing, RAC is not an high-availability solution, it is a scalability solution for situations when it is not possible to scale non-RAC within a server. Oracle tries to differentiate between "disaster recovery" (DR) and "high availability" (HA) in order to prevent DataGuard and GoldenGate from cannibalizing RAC, but DR and HA are really the same thing to a database. After all, what parts of DR would you give up and still be able to call the result "HA"?

Good luck,


-----Original Message-----

From: Avadhani mys [] Sent: Wednesday, December 7, 2011 01:35 PM To: 'ora-apps-dba', 'oracle-l', Subject: HA Architecture Plus + Reporting Purposes

Hi Gurus,We are planning to propose a solution to avoid bottleneck onperformance from reporting[Discoverer Reports] job runs on a database.As we are aware that with any High Availability Architecture, therewill be single point of DB connection for any reporting job runs. Weare thinking about 3 strategies to propose listed below. Can youplease shed light on Advantages/Disadvantages of each approach basedon your experience or any approach which can solve/address HighAvailability and Performance.1) Data Guard - Pure Disaster Recovery Solution. Leverage ActiveStandby for Reporting purposes (Partial only for 100% read onlyreports)2) Golden Gate Replication Technology to replicate Data Secondarysite and using Secondary site for reporting purposes.3) RAC - High Availability Solution with additional node to be usedfor Reporting purposes.4) RAC - High Availability Solution with Golden Gate ReplicationTechnology to replicate Data Secondary site real time for  reportingpurposes. Any HA/D
R gains from this point?Your help will be really helpful in determining the best feasible approach.Thanks in Advance.Regards,Avadhani--


-- Received on Thu Dec 08 2011 - 11:53:47 CST

Original text of this message