Re: Data Mirroring on two data centers -- How to use ASM ?

Interesting thread. I am often working with a bank too and there are other advantages to SAN replication:

 o No need to worry about the Oracle version (among the dozens of production databases you always find some that are late because they are used to run some 3rd party app that has never been certified on any recent release).

o Somehow, I'd feel more confident when upgrading software.

o It works for Sybase too.

Note that SAN replication can be synchronous or asynchronous. When it's synchronous it lengthens commit time, but hardly anything else.

I agree that if there is any data dictionary corruption, you are better off with a slightly delayed replication. That said, the last data dictionary corruption I have seen (call me lucky) was a long long time ago. Moreover, defining what is the suitable delay looks tricky to me. I have always noticed that it takes longer to wait for someone who has the suitable authority to say "OK, we switch everything to the backup server" than to perform the operation from a pure technical point of view; detection, diagnosis, decision, all take time, and the delay may zoom along in the meanwhile.

I agree with Yechiel that for OLTP performance impact is negligible (I have been involved in tests recently). You may have issues with batch programs, especially if the distance between sites is above 50km (about 30 miles for those who still have to use modern units :-)) and if the batch programs are poorly written.

If you must define one particular strategy per RDBMS/version, no doubt you end up with something finely tuned and technically optimal, but I am afraid that no one will really care in business lines, especially it it takes you months to set it up when they can have it now with SAN replication.

I have no shares in any SAN provider, but I consider the question when I am told storage requirements :-).

HTH, Stéphane Faroult

Yechiel Adar wrote:

> Hello Tanel
>
> You might be right about the amount of data that goes over the line
> but we replicate our mainframe storage to remote site and have almost
> nil impact on performance. We are a bank with over 100 branches, so
> there is a lot of activity when the branches are open.
> If we are talking about DR scenario, and using fiber to connect the
> sites, I would still go with SAN replication.
>
> Adar Yechiel
> Rechovot, Israel
>
>
>
> Tanel Põder wrote:
>
>> One more reason to use data guard instead of storage/LVM level
>> replication in high-activity OLTP environments is that redolog entry
>> based shipping is much more more fine grained than storage block
>> level replication.
>>
>> I once asked one EMC admin, they told that the minimum block size for
>> SRDF is 32k. So if you update one row and commit, you'd need to ship
>> few hundred bytes to standby, while with SRDF you'd need to transfer
>> 32 kilobytes over the fibre when the block is written to disk /plus/
>> you need to continuously transfer redolog writes before the datafile
>> blocks are sent to remote.
>>
>> If your management definitely requires SAN based replication, then
>> you could just keep your archivelogs on a replicated volume/storage
>> and do frequent log switches to keep the lag small in case of primary
>> failure.
>>
>> Tanel.
>>
>> ----- Original Message -----
>>
>> *From:* Carel-Jan Engel <mailto:cjpengel.dbalert_at_xs4all.nl>
>> *To:* db.mail.1_at_gmail.com <mailto:db.mail.1_at_gmail.com>
>> *Cc:* oracle-l_at_freelists.org <mailto:oracle-l_at_freelists.org>
>> *Sent:* Saturday, May 20, 2006 3:06 AM
>> *Subject:* Re: Data Mirroring on two data centers -- How to use
>> ASM ?
>>
>> Hi Madhu,
>>
>> I'm wondering your primary 'requirement' of mirroring data across
>> TWO data centers.
>>
>> IMHO, mirroring between data centers is a solution, or if you
>> like, tool. Whatever, it isn't a requirement.
>>
>> Requirements could be something like:
>> - After a server failure, the database should be available again
>> within 30 minutes
>> - After a server failure, no more than 5 minutes worth of
>> transactions may be lost
>> - After a database corruption, the database should be available
>> again within 6 hours
>> - After a database corruption, no more than 30 minutes of
>> transactions may be lost
>> - Restoring of the database to any point in time between now and
>> now - 6 days must be possible
>>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l