Re: Oracle 10 Failover

From: joel garry <joel-garry_at_home.com>
Date: Wed, 10 Sep 2008 14:18:18 -0700 (PDT)
Message-ID: <7d411c28-c297-4ec5-8123-3e6928b8b0b2@s1g2000pra.googlegroups.com>


On Sep 10, 12:56 pm, "Chris Seidel" <csei..._at_arcor.de> wrote:
> sybra..._at_hccnet.nl wrote:
> > I already explained Streams and CDC are asynchronous.
>
> I know.
>
> > This means transaction consistency is NOT guaranteed. Dataguard
> > potentially
> > guarantees transaction consistency.
>
> Do you mean that in case of a switch- or failover the running client
> transaction is maintained?
> AFAIK this is a RAC feature, isn't it?
> Or what do you mean with transaction consistency?
>
> > Are we discussing a distributed environment? As far as I am concerned
> > we are discussing misusing distributed multi-directional technologies
> > (replication, streams) to mimic unidirectional fallback technologies
> > (Dataguard).
>
> OK, so you advice that one should use DG and not replication/streams to
> create a failover/standby server?
> DG needs the Oracle EE. What option do I have on SE?
>
> > The main purpose of RAC is to protect servers (and to offer additional
> > scalability).
> > The main purpose of Dataguard is to protect disks.
> > I do not see where distributed environment comes into play, nowhere
> > you described you have a distributed environment.
>
> Who uses for the failover/standby database the same server?
> So this should always be distributed (at least 2 servers).
> Or do you mean with distributed different locations?
>
> My use case is that the two databases are on different locations to protect
> against a disaster (fire, water etc.) at one of the locations. Sorry, forgot
> to mention this.
>
> Thank you.

It does help to say your intentions :-)

There are other kinds of distributivity, like having data entry at multiple locations, or having local inquiries for everything when people are all over the map (literally).

Standby database in the Oracle world specifically means a database where continuous recovery is going on, fed by a primary database, copying the archived logs over as they are generated (see the Concepts manual, that is way old oversimplification). Anyways, before DG people would copy the archived logs over and apply them with scripts. Nowadays that would be considered reinventing the wheel, and it effectively means you have to dedicate expensive skilled labor to watch the thing. No reason you can't still do that (I think, haven't tried with SE), aside from absurdity (which has been lucrative for me!). If you are dealing with cheapness, you are going to have to know that failover will have limits. Some consider the ability to have the standby data trailing the primary data a feature, anyways.

See http://www.oracle.com/database/high-availability.html for the legitimate answers.

Could you be more specific as to the replication you referred to in the original post? I suspect you may have meant a non-Oracle thing?

jg

--
@home.com is bogus.
Hey, why upgrade old systems that are working?
http://catless.ncl.ac.uk/Risks/25.31.html#subj2
Received on Wed Sep 10 2008 - 16:18:18 CDT

Original text of this message