Re: HA Architecture Plus + Reporting Purposes

From: Tim Gorman <>
Date: Wed, 07 Dec 2011 21:14:22 +0000
Message-ID: <W9100215917265981323292462_at_webmail72>

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 Wed Dec 07 2011 - 15:14:22 CST

Original text of this message