Re: DB Appliance

From: Gaja Krishna Vaidyanatha <>
Date: Sat, 10 Mar 2012 11:16:59 -0800 (PST)
Message-ID: <>

Hi Tim,
Although the subject line reads - DB Appliance, what I am about to share here is not specific to it. It is more widely applicable. But I do want to address what you shared in your first paragraph.

To Niall's defense, I think the whole definition of HA has changed dramatically since the advent of Cloud Computing. These days data center going down can be considered as an HA issue depending on the context. For example, an organization that utilizes geographically distributed clouds, can have 4 data centers in the mix, 2 on each coast of the US. So, think of US-East-A and US-East-B, which are considered co-locations and are say within 100km apart from each other. And a similar setup for the West Coast, 3000 km away - US-West-A and US-West-B which are co-locations, again within 100km of each other. And for the purposes of our discussion, let's assume that the East Coast is the Primary Region and the West Coast is the DR Region. Data Centers A & B are connected to one another using dark fiber and the network latency is very low (1-5 ms). The above setup is similar to what Amazon EC2 has to offer.

It is imperative that we are talking about 4 independent databases here (2 in each region). Now, when we talk about HA, it is between the US-East-A & US-East-B data centers. The complete disaster of EITHER Data Center A or B, does not cause a DR event. DR is engaged ONLY when BOTH A & B are unavailable. Stretch RAC/Extended RAC is not a viable option due to its high sensitivity to network latency and the inevitable node evictions and the performance aftermath that ensues on the slightest network hiccup. Stretch RAC is really suited more for a campus type implementation for some very specific applications when the data centers are close (say within 10km of each other). The databases in A & B on either region is kept in SYNC using standard replication methods available in Oracle - Active Data Guard in Maximum Protection Mode. The concept of cross-data-center-HA here is without Oracle RAC. In fact, RAC is not even required within the same data center,  as a server failure in A can automatically failover to the database in B. This design is fundamentally simpler as the 4 databases in question can be single-instnace databases and with a simple yet intelligent network routing between A & B. This setup can (and has) provide (provided) very high levels of uptime (yes 5 nines). I realize that there is much detail that is not covered here, but I wanted to give you another perspective on the subject nevertheless.



Gaja Krishna Vaidyanatha,
CEO & Founder, DBPerfMan LLC

Phone - +1-650-743-6060 Insights:Tales of the Oak Table - Co-author:Oracle Performance Tuning 101 - Enabling Cloud Deployment & Management for Oracle Databases

 From: Tim Hall <> To: "" <> Cc: "" <>; "" <>; "" <>; "" <>; Sent: Friday, March 9, 2012 2:17 AM
Subject: Re: DB Appliance  

Niall: I slightly disagree with your High-Availability (HA) point, but on a terminology issue.

RAC is a HA solution. It is meant to cope with a server going down. A data center going bang is not a typical HA issue. It is a disaster recovery issue. Unless you are using a stretch cluster, then RAC is not really a disaster recovery solution full stop.

With this in mind, I think the claim that ODA is a HA solution is valid*. It is most definitely not a disaster recovery solution. If you need that, you are going to have to buy more hardware and consider a solution like Data Guard or DBVisit Standby etc.

Now I know some people use the term HA to mean different things, which is why I said I "slightly disagree". :)

  • Complexity is the enemy of high-availability. RAC is complex, therefore RAC != HA. :)


-- Received on Sat Mar 10 2012 - 13:16:59 CST

Original text of this message