Re: Is RAC really HA on Linux
- From: Stephen Evans <evans036@xxxxxxxxxxx>
- To: bdbafh@xxxxxxxxx
- Date: Mon, 13 Sep 2004 15:38:47 -0400
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@xxxxxxxxx>
Sent by: oracle-l-bounce@xxxxxxxxxxxxx
09/13/2004 02:59 PM
Please respond to bdbafh
To: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxx>
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@xxxxxxxxx>
> 09/13/2004 10:27 AM
> Please respond to Niall Litchfield
>
> To: evans036@xxxxxxxxxxx
> cc: oracle-l@xxxxxxxxxxxxx
> Subject: Re: Is RAC really HA on Linux
>
>
>
>
> Comments inline
> On Mon, 13 Sep 2004 10:11:41 -0400, Stephen Evans <evans036@xxxxxxxxxxx>
> 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@xxxxxxxxxxxxx&subject=unsubscribe
> To search the archives - //www.freelists.org/archives/oracle-l/
>
--
To unsubscribe - mailto:oracle-l-request@xxxxxxxxxxxxx&subject=unsubscribe
To search the archives - //www.freelists.org/archives/oracle-l/
--
To unsubscribe - mailto:oracle-l-request@xxxxxxxxxxxxx&subject=unsubscribe
To search the archives - //www.freelists.org/archives/oracle-l/
Other related posts:
