Re: Is RAC really HA on Linux

paul,
good points.

we are a hospital & somes apps are so mission critical that patient care is compromised for every minute of downtime we incur.

we are extensively using data guard right now. we have also achieved zero data loss on the san (against a SINGLE point of failure) by using a combination of dataguard and triplexing our active redos on two stroage controllers (in different locations) and on local unix storage. We are almost certain that we will always be able to obtain at least one copy of the active redo if any part of the system goes belly-up (hence zero dataloss once applied to our physical standby).

We have tested our failover scripts many times and generally takes us about 15 mins to actaully failover anyone of our oracle servers (with zero data loss). Much of the time in the outage that the customer sees is getting support to execute the failover & restart application servers etc. The real outage ends up being about 1.5 hours once everything is fully functional. This is especially true if the outage occurs outside of prime time.

thanks,

steve

Paul Drake <bdbafh_at_gmail.com>
Sent by: oracle-l-bounce_at_freelists.org
09/13/2004 02:59 PM
Please respond to bdbafh  

        To:     oracle-l_at_freelists.org
        cc: 
        Subject:        Re: Is RAC really HA on Linux

Steve,

methinks that the base10 log of cost of |zero data loss| > 6. that would likely include synchronous copying of redo logs to a remote site that blocks commits until applied at the remote site. big, fast, redundant pipe(s) required.
duplexed local storage.
dual (multi) paths for all SAN, ethernet. Redundant system for testing OS patches, Oracle patchses, configuration changes.

I would seriously recommend not using the term "zero data loss" unless that is what is being specified as the objective to you, which it will likely no longer be after they see the price tag. "minimal data loss" is much more fuzzy and obtainable.

Pd

On Mon, 13 Sep 2004 14:28:28 -0400, Stephen Evans <evans036_at_mc.duke.edu> wrote:
> niall,
> agreed with the single database bit. We still plan on having a stand-by
> that can provide us with zero data loss (but definitely not HA).
>
> it is interesting that you perceive RAC as not addressing HA (but only
> scalability). and of course the db is a single point of failure in a RAC
> config (unless you mitigate that with some kind of SAN based continuous
> copy with auto failover to that too).
>
> so do folks generally consider (not withstanding the db as a single
point
> of failure) that RAC is NOT considered high availability? I think i'm
> inclined to agree with Niall's viewpoint if we cannot do rolling
upgrades
> within the cluster. From memory, oracle RAC can only withstand rolling
> upgrades if the patch is designated as such (and patchsets are NOT).
>
> does anyone know if future versions of oracle RAC will support rolling
> upgrades/patchsets?
>
> hope i'm not rambling too much.
>
> steve
>
> Niall Litchfield <niall.litchfield_at_gmail.com>
> 09/13/2004 10:27 AM
> Please respond to Niall Litchfield
>
> To: evans036_at_mc.duke.edu
> cc: oracle-l_at_freelists.org
> Subject: Re: Is RAC really HA on Linux
>
>
>
>
> Comments inline
> On Mon, 13 Sep 2004 10:11:41 -0400, Stephen Evans <evans036_at_mc.duke.edu>
> wrote:
> > i hope i addressed this right - its my first post.
>
> looks like it!
>
> > i am looking at RAC to provide an HA environment on Linux (most likely
> > Redhat AS3)
>
> I think I'd view RAC as a scalability solution for Oracle rather than
> an HA solution. You still only have the one database with RAC, what
> happens if that DB suffers a failure?
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.niall.litchfield.dial.pipex.com
>
> --
> To unsubscribe - mailto:oracle-l-request_at_freelists.org&subject=unsubscribe
> To search the archives - http://www.freelists.org/archives/oracle-l/
>

--
To unsubscribe - mailto:oracle-l-request_at_freelists.org&subject=unsubscribe 
To search the archives - http://www.freelists.org/archives/oracle-l/




--
To unsubscribe - mailto:oracle-l-request_at_freelists.org&subject=unsubscribe 
To search the archives - http://www.freelists.org/archives/oracle-l/