Re: High Availability Options

On May 28, 4:59 pm, hpuxrac <johnbhur..._at_sbcglobal.net> wrote:
> On May 28, 2:20 pm, Pat <pat.ca..._at_service-now.com> wrote:
>
>
>
> > So, I've been asked to propose a HA solution for an Oracle database.
> > My original proposal was:
>
> > Production RAC cluster in data center A
> > DR Database (no cluster) in data center B
>
> > I originally proposed Oracle Enterprise at both sites with dataguard
> > being used to keep DR in synch with the prod cluster.
>
> > Naturally, that particular configuration added up to some serious
> > money (I don't recall the details, but I think we had 20+ LU's worth
> > of Oracle Enterprise at $40k a pop). Probably not surprisingly, the
> > customer came back and said "dear lord, can't you give us an HA
> > architecture for less money?"
>
> > Which brings me here. Are there any other best practises or
> > recommended approaches for a High Availability Oracle configuration
> > that don't rely on dataguard and Oracle Enterprise?
>
> 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) 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.

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.

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). Received on Wed May 28 2008 - 19:05:50 CDT