Re: Oracle 10 Failover

From: <sybrandb_at_hccnet.nl>
Date: Wed, 10 Sep 2008 23:57:18 +0200
Message-ID: <ehfgc497u4c1kbs0jrs0vnmte2ljd2t1e9@4ax.com>


On Wed, 10 Sep 2008 21:56:19 +0200, "Chris Seidel" <cseidel_at_arcor.de> wrote:

>sybrandb_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?

Dataguard can be configured in various protection modes. One of them guarantees a commit on the primary will only execute if the corresponding commit in the standby succeeds. This means you should be able to guarantee zero-loss.

Using replication techniques you have no control over this, as Streams etc replicate changes on table level, it doesn't work on transaction level.
So in a Streams scenario, if you decide to 'switch' (I try to avoid switchover and failover here), you will potentially have 'gaps' and you don't know where they are.
Streams can be zero-loss, but you can't guarantee it.

>
>> 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?

You need to answer whether you can afford data loss (or inconsistent data) and how much down-time you can afford. Apart from that you need to take into account Streams and other options potentially require more manual intervention and are more difficult to troubleshoot.

>DG needs the Oracle EE. What option do I have on SE?

Theoretically (I didn't use it) there is 'manual standby'. This means archivelogs have to by shipped by a homegrown mechanism, and have to registered manually at the standby database. Obviously you won't get zero-loss protection. A completely different idea, and sorry I don't recall the product name right now (it was an EMC product), is to replicate the disks, so outside the database.
>
>> 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?

I have that seen proposed. Not joking. By a subsidiary of the former largest independent bank in the Netherlands.

>So this should always be distributed (at least 2 servers).
>Or do you mean with distributed different locations?
>

No, for me you have a distributed environment when you have two *independent * databases which share data. Let' s assume you have two different applications in two different databases, both share 'reference data'
This can be accomplished by database links, it can be accomplished by .. Streams etc. Actually *this* is the purpose of Streams. A physical standby database isn't fully accessible, and doesn't function without the primary. Even if they may be in two different locations, they are not independent, so this is not a distributed environment.
>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.

There was that very funny story once of a computer room in a separate lower building, so the servers were under a roof. The airco had it's outlet through the roof.
At some point it started raining very hard, and the airco was functioning as a sink. However the water got between the roof and the ceiling. At a certain point the complete ceiling came down!!! I would loved to have seen that.

>
>Thank you.
>

Hth

-- 
Sybrand Bakker
Senior Oracle DBA
Received on Wed Sep 10 2008 - 16:57:18 CDT

Original text of this message