Re: High Availability Options

From: hpuxrac <>
Date: Sat, 31 May 2008 03:05:58 -0700 (PDT)
Message-ID: <>

On May 28, 8:05 pm, Pat <> wrote:


> > You don't need EE for RAC necessarily.
> > You don't need RAC at all necessarily for HA.  Actually as Moans
> > Nogood has demonstrated often people lose reliability and availability
> > when implementing RAC.
> > Start by defining exactly what HA means to the customer.  How much
> > downtime can they tolerate and how often?
> The specifications I had to work on were:
> Primary production environment should take < 2 minutes to recover from
> a hardware failure (RAC does this for me I believe)

RAC "could" handle this but as Moans has pointed out ( repeatedly ) implementing RAC and supporting RAC requires a huge investment not only in licensing costs but in training, testing, verification, etc.

It is not unusual that people find they cause more downtime than they gain by attempting to implement RAC. It requires a huge investment in personnel, equipment, testing, etc. You cannot just setup a production RAC environment without having a test RAC environment to practice on and perfect everything.

Don't undersell the amount of time and effort and cost involved in an implementation like this if you choose RAC.

For example, 2 minutes is an eternity and could possibly be handled by having a spare server setup that can mount the storage and perform instance recovery. Or a standby database on the primary site.

Lots of possible HA solutions might fit into what you have described so far.

> In the event we lose the primary data center, we should be able to to
> have the DR environment up in < 10 minutes. Frankly I'm not sure the
> requisite network changes would propagate in < 10 minutes in the event
> we flat out lost a data center, but those were the parameters I had to
> work with.

You can do the remote HA either with oracle techniques or with storage based alternatives. Again lots of choices here.

We are switching out EMC symmetrix synchronous SRDF over to Clariion based mirrorview async.

> My understanding is I can set up RAC with Oracle Standard just fine,
> so that more or less meets my production criteria (although the SAN
> does remain a single point of failure, albeit an unlikely one)
> The hard part though is how to make sure that my offsite DR database
> is up to data. Dataguard will do that for me, and I can live in
> asynchronous mode (in a disaster we can afford to lose a few unapplied
> logs; this is not a financial app). Dataguard though (I think)
> requires enterprise.

Why don't you actually look at the licensing options and choices instead of guessing?

> The hard part of this spec for me at least is the offsite DR site,
> which is kind of ironic, because the other database we have in house
> is mysql and it has the opposite problem. Remote slaves are easy to
> set up (and part of the core product). There's no equivalent to RAC at
> all though (don't get me started about what mysql laughably calls
> their cluster solution).

Not sure this is relevant to what you are asking here. No need to start some kind of oracle/mysql flame war we get enough of the oracle/ sql server ones here.

Good luck and keep questioning all your assumptions. Received on Sat May 31 2008 - 05:05:58 CDT

Original text of this message