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 (srcdco_at_rit.edu <mailto:srcdco_at_rit.edu>)

>

> (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:*oracle-l-bounce_at_freelists.org 

> [mailto:oracle-l-bounce_at_freelists.org] *On Behalf Of *Tim Gorman

> *Sent:* Wednesday, February 14, 2018 3:27 PM

> *To:* fuzzy.graybeard_at_gmail.com; oracle-l_at_freelists.org

> *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

>     http://www.oracle.com/technetwork/products/clustering/overview/extendedracversion11-435972.pdf

>

>     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?

>



--
http://www.freelists.org/webpage/oracle-l