RE: Oracle High Availability Question(s)

From: Scott Canaan <>
Date: Wed, 14 Feb 2018 21:25:38 +0000
Message-ID: <>

We would not go into RAC without training. We learned our lesson on the Data Guard mess.

Scott Canaan '88 (<>)
(585) 475-7886 - work (585) 339-8659 - cell
"Life is like a sewer, what you get out of it depends on what you put into it." - Tom Lehrer

From: Tim Gorman [] Sent: Wednesday, February 14, 2018 4:23 PM To: Scott Canaan;; Subject: Re: Oracle High Availability Question(s)

Going into Data Guard without training is uncomfortable, but going into RAC without training is untenable. You can try it, but it is going to hurt a lot, and you'll end up with something you'll regret.


I used to teach Oracle Education's Parallel Server (OPS) courses in the 1990s.  It was a 3-day class, and at the end of the first day, I would find myself teaching an additional session into the evening.  Originally, I didn't intend the additional session because I was exhausted, but by the end of the first day, every attendee fell into one of two groups:  1) this is great stuff and we're glad to be here! and 2) this is utter nonsense, WTF, and you're out of your mind.

We spent time discussing each person's use-cases, we found that the people who sorted into the first group (i.e. "Loving it!") were using OPS (which was the predecessor to RAC) for all the right reasons (i.e. usually data warehousing and large queries) and those who sorted into the second group (i.e. "WTF!") were using OPS for high-availability only.  Both camps had an easier time over the next two days of instruction, because the first group felt validated and energized, and the second group understood their cognitive dissonance better.

So I built that extra session into the curriculum unofficially.


The last comment (promise!) is that using RAC to scale out across nodes is indeed a form of performance optimization, but not for all performance problems.  Scaling out permits a larger volume of workloads overall, but RAC does not increase the performance of any one of those workloads.  In fact, RAC reduces the performance of individual workloads due to the synchronization demands for lock and cache coherency between nodes.  So it is important to understand "scaling out" versus "scaling up", and how RAC helps with one but actually harms the other.

Understand how the tool is designed and how it works, and then use it for the intended purpose.

On 2/14/18 13:39, Scott Canaan wrote:
We are currently using Data Guard and we hate it.  It's the only place we use it and we were never given any training on it, so we threw it together as best we could.  Every time we have to do anything with it (including patching), we pray that it will recover and continue working.

What we have proposed is to go to Linux clustering instead, eventually going to Libvert, eliminating the Data Guard and moving the fault tolerance to the cluster.  The app is not Data Guard aware, so when a failover does occur, the app stops working until someone manually points it to the other server and restarts it.  Linux clustering would solve that problem.

RAC was mentioned as another alternative, so I've been looking into it, but everything I found showed all of the nodes pointing to one disk or disk array, which is not what we want.  I've already said that if they want us to go with RAC, we will require training as we are not going to go into it blind like we did with Data Guard.

Scott Canaan '88 (<>)

(585) 475-7886 - work (585) 339-8659 - cell
"Life is like a sewer, what you get out of it depends on what you put into it." - Tom Lehrer From:<> [] On Behalf Of Tim Gorman Sent: Wednesday, February 14, 2018 3:27 PM To:<>;<> Subject: Re: Oracle High Availability Question(s) Whether you have RAC licensing or not, anyone is far better off deploying Data Guard for high availability. Data Guard is designed for high-availability and disaster-recovery first and foremost. RAC is designed as a scalability solution first and foremost, and the only way Oracle gets away with marketing it as an availability solution is because RAC must include fault tolerance against node failure to even operate. RAC is wonderful and mature software, but using it for availability is an adaptation. On 2/14/18 12:10, Hans Forbrich wrote: You might want to look up 'stretch RAC' One useful article is Oracle's wwhite paper disclaimer: My opinion, not my employer's /Hans On 2018-02-14 11:59 AM, Scott Canaan wrote: Currently, we don't have a license for RAC, therefore we aren't using it. We have one application in particular that is required to be available as close to 7 x 24 x 365 as possible. One other requirement is that the redundancy includes physical disk, with one set of disks in one location and the redundant set in another location. In looking at RAC, it appears that a shared disk (or disk group) is used which doesn't satisfy the second requirement. So far, I have not found a description of RAC that shows it using more than one disk / disk group for redundancy. What is the best way to accomplish the second requirement? --
Received on Wed Feb 14 2018 - 22:25:38 CET

Original text of this message