Re: Remote Storage Mirroring vs Dataguard - Important

From: Connor McDonald <>
Date: Sat, 9 May 2015 17:29:36 +0800
Message-ID: <>

In terms of mitigating the license cost, there's no drama having a node that is not designed to *run* your workload, just to *capture/apply* it.

For example, you could have a 10cpu main node but only a single cpu DG node (whose job it is to apply archives). Of course, you dont get true DR failover (ie, there would need to be manual configuration of a new node etc in the event of true site failover), but a lot of sites I've seen have so many manual processes attached to all the other non-db components in the event of site failover, that the obsession with a seamless *db* failover is somewhat comical.


On Thu, May 7, 2015 at 12:23 AM, John Thomas <> wrote:

> In a large system with lots of components you can't even guarantee that
> local storage will accurately contain the blocks that Oracle wrote.
> Electrical glitches, cosmic rays - don't laugh, you can look up the IBM
> paper detailing the probability of you like - failing controllers and all
> sorts of other unexpected events.
> The work on T10 Data Integrity Format/ Data Integrity eXtensions
> demonstrates this, for a local system but is not yet widely supported.
> Maybe when it becomes available for synchronous remote SAN replication you
> can start to be comfortable that your DR site will actually recovery your
> database. Until then your DR is only as good as your last trial recovery.
> Else use Data Guard, which will let you know when you have a corrupt block.
> Regards
> JT
> On Wed, 6 May 2015 16:24 MARK BRINSMEAD <> wrote:
>> Yes. Generally, this can be a *big* plus. The licenses needed to
>> operate a standby database can cost hundreds of thousands of dollars. This
>> is probably the only reason I would consider storage-level replication for
>> DR. (It can be used for all sorts of other clever purposes elsewhere,
>> though.)
>> Of course, the need to restore/install Oracle software, and maybe
>> configure some devices (e.g., if using ASM) could make your failover a
>> little-less-than-instantaneous.
>> Personally, I have higher confidence in a dataguard standby -- if for no
>> other reason that I know it is ready for failover at a moment's notice, and
>> I can validate the integrity of the database as often as if I choose to.
>> But sometimes there are compelling reasons to sacrifice a little confidence.
>> On Wed, May 6, 2015 at 10:50 AM, Mladen Gogala <
>>> wrote:
>>> On the other hand, you can do storage replication, without consuming
>>> an Oracle license. Essentially, you can just replicate your storage and, if
>>> switchover is needed, restore the Oracle software from backup, bring up the
>>> instance and go on. Saving on Oracle licenses is a BIG plus.
>>> On 05/05/2015 02:22 AM, Svetoslav Gyurov wrote:
>>> Hi Sanjay,
>>> I used storage replication many times to copy prod to dev or take a
>>> snapshot before some major activity but never used it in a way as a DR.
>>> To answer your questions:
>>> - I would prefer DG because it's much more flexiable. You've got an
>>> idea what is the transport lag, apply lag and what is the state of your
>>> standby. You can open the standby as readonly, ADG or ever snapshoot
>>> standby to do some testing. Switchover is just a matter of one command
>>> through the broker. I cannot see neither of these happening with the
>>> storage replication.
>>> - It should be fine, as long as you replicate all the ASM LUNs. If you
>>> open the standby database you'll always have to do instance recovery, keep
>>> that in mind.
>>> - Yes, you can have your storage replication in SYNC. Pretty much it's
>>> similar to DG - the blocks from the first storage arre written to the cache
>>> of the second storage and they an acknoledgement is sent.
>>> - Not sure what the question is but if you have a GAP the storage
>>> systems are smart enough - and because we are only replicating blocks they
>>> can assisiliy recover the gap and become in sync again.
>>> - The fastest and safe way to bring the standby database in consistent
>>> state is by using DataGuard broker.
>>> - Modern storages have the option to change the direction of the
>>> replication so this shouldn't be a problem.
>>> Regards,
>>> Sve
>>> On Sat, May 2, 2015 at 4:19 AM, Sanjay Mishra <
>>>> wrote:
>>>> Can anyone share their views on the following on Real practical
>>>> experience with the setup in their environment. I had worked with dataguard
>>>> but never with Storage Replication for Disaster recover.
>>>> Some points for the required environment which can affect or help in
>>>> providing or sharing the experience
>>>> - Oracle 11g 2-Node RAC setup using ASM on both Primary and DR site
>>>> - Database size range from 1-5Tb
>>>> - Database has lots of DML activites on daily basis
>>>> Questions:
>>>> - What is the best option to be used for Disaster Recovery when has
>>>> to choose Storage Replication vs DataGuard for RAC setup and if can provide
>>>> why you think one preferred over other as per your experience ?
>>>> - Does there can be issue if Primary storage or server crashed and
>>>> Recovery either failed to start the Datbase on DR or lost some data ?
>>>> Keeping in mind that we are working in SYnc Mode.
>>>> - Is Storage mirroring can be setup so that both Primary and Remote
>>>> storage is almost SYNC like Synchronous Data Giuard Setting ?
>>>> - Is it possible that we may loose the DR location and Storage
>>>> Replicated environment failed to start ?
>>>> - Which one is faster to bring Database live, Storage mirrored DR
>>>> env or Dataguard based environment?
>>>> - How to go back or switch back to original Primary when you have
>>>> done switchover initially to DR location ? In Oracle Dataguard we can go
>>>> back using Flashback DB feature and reinstantiate the database
>>>> - Any other Pros and Cons for both option as well as any good Link
>>>> to be checked.
>>>> TIA
>>>> Sanjay
>>> --
>>> Mladen Gogala
>>> Oracle DBA

Connor McDonald

"If you are not living on the edge, you are taking up too much room."
- Jayne Howard

Received on Sat May 09 2015 - 11:29:36 CEST

Original text of this message