Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Data Mirroring on two data centers -- How to use ASM ?

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

From: Tanel Põder <>
Date: Sun, 21 May 2006 18:00:58 +0800
Message-ID: <0b7a01c67cbd$76c73df0$6401a8c0@porgand>

Yep, those are all valid thoughts :)

Nevertheless, if the primary goal is maximum resiliency of data, which is usually the main reason why anybody implements full database replication to another data centre, then a redolog apply based solution provides better chances to achieve that - thanks to being less prone to corruptions and immediate detection

Btw, I wasn't talking about introducing a delay for applying logs to avoid corruptions - even without any delay at all, you're safer with log apply mechanism, because it is aware of the structure of data, computes checksums and most importantly - it operates at much higher level than storage based binary replication.

So from corruptions perspective - a storage level replicated database IS as single point of failure. Not to mention that all user errors such accidential rm -rf * get all propagated to remote storage without a question.

Now the question is big risk you're willing to take. During my 8.5 years of DBAing, I've seen 6 cases of block corruptions in production environments, including in OBJ$ table which effectively disabled any operations in database (mostly caused by disk controller glitches).

If you can tolerate the risk, then go ahead with storage replication, if not you have pay the higher maintenance price and go with data guard like solutions (note that with proper scripts and standardized configurations its not that hard to have working 100+ database DR solutions - we've been doing it here (in an european investment bank) for years).

And if even data guard like solutions aren't enough because additional performance or flexibility requirements, then you have to step few layers closer to the end user again and use some kind of application/transaction monitor replication...


> 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 <>
>>> *To:* <>
>>> *Cc:* <>
>>> *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
>> --
> --

Received on Sun May 21 2006 - 05:00:58 CDT

Original text of this message