Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
Subject: RE: Data Mirroring on two data centers -- How to use ASM ?
Date: Sun, 21 May 2006 09:39:14 -0700
Message-ID: <5D2570CAFC98974F9B6A759D1C74BAD0E5A4D7@ex2.ms.polyserve.com>
Thread-Topic: Data Mirroring on two data centers -- How to use ASM ?
Thread-Index: AcZ8wAXaFAydA/6zRMeLTo4V0CAKSwAMy9bg
From: "Kevin Closson" <kevinc@polyserve.com>
To: <oracle-l@freelists.org>
Sender: oracle-l-bounce@freelists.org
Errors-to: oracle-l-bounce@freelists.org
Precedence: normal
Reply-to: kevinc@polyserve.com

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


Tanel, your input is always golden, but I don't think the SAN
replication proponents (like me) are suggesting a single-technology
approach. There still has to be thought about logical corruptions
as you point out, and human accidents like rm(1) as well need to 
be factored in. I think storage-level replication combined with
an amount of local Data Guard and perhaps filesystem snapshots
can help. For instance, our next filesystem release will support a
non-intrusive snapshot capability that will allow you to snapshot
filesystems not just every now and then, but hundreds of thousands
of times. That would take care of rm(1) concerns because the database
in a filesystem snapshot looks just as it would if you had powered
off the system. So you could mount a snapshot that is, say, 30 seconds
old and roll it forward. I know, I know, I'm talking about some 
technology that doesn't come on a CD from Oracle Corp so it can't
possibly be helpful right ?  :-) Where I sit, the intent is to solve
this 
problem in a way that is not Oracle-centric but will have Oracle
in mind, and from a market persective, I think that is anything
but a foolish approach.

DR threads are always very healthy for the mind and if anything
can be stated matter-of-factly regarding DR, it is that you better 
not approach the problem with a religious brain-washed bias or the
project is
doomed.  Any input from Carel-Jan on this sort of thread is gold as
well.

In the end, it really does have to start with RTO/RPO analysis as 
Carel-Jan states a few posts back. If RTO/RPO can be established
the project might at least be more feesible than trying to make
brick without straw.


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