Re: Remote Storage Mirroring vs Dataguard - Important

Date: Sun, 10 May 2015 20:08:30 -0400
Message-ID: <>

But, the standby server *does* contribute to the CPU count that determines the minimum number of named users.

It may sometimes be the case that in an environment licensed for named users, a standby database will not add cost, but I imagine that is fairly rare. Unless, of course, you maintain standbys for a small minority of your databases. In cases like that, this can probably work nicely.

This is an interesting use-case for named-user licenses.

On Sun, May 10, 2015 at 5:04 PM, John Thomas <> wrote:

> That does depend on your business environment I suppose.
> In my current environment, we are fortunate to have dedicated database
> servers that do nothing but run the database and store external files on a
> drive mounted from a SAN. The service level agreement is effectively
> immediate recovery to the standby.
> So the single CPU log apply machine would not be an option, as in a crisis
> considerable time would be needed to get everything switched over to the
> real cold standby server. (Actually in a crisis requiring a failover, would
> you really want to have to manage enabling your new production server for
> use with user demands exploding all around you and the business effectively
> down until you can get the new server running a database?)
> We use named user licensing with a fairly large user number. As long as we
> don't exceed the processor minimums, the standby licensing doesn't add
> cost.
> Regards
> JT
> On Sat, 9 May 2015 at 10:30 Connor McDonald <>
> wrote:
>> 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.
>> hth,
>> Connor
>> 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
>> ===========================
>> blog:
>> web:
>> "If you are not living on the edge, you are taking up too much room."
>> - Jayne Howard

Received on Mon May 11 2015 - 02:08:30 CEST

Original text of this message