Re: Remote Storage Mirroring vs Dataguard - Important

From: John Thomas <jt2354_at_gmail.com>
Date: Sun, 10 May 2015 21:04:48 +0000
Message-ID: <CAOHpfbEbq94nQs_oTCUiJY3mjFbo9YpowszsEvAvirOQTZ7jHQ_at_mail.gmail.com>



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 <mcdonald.connor_at_gmail.com> 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 <jt2354_at_gmail.com> 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 <mark.brinsmead_at_gmail.com> 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 <
>>> dmarc-noreply_at_freelists.org> 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 <
>>>> dmarc-noreply_at_freelists.org> 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 DBAhttp://mgogala.freehostia.com
>>>>
>>>>
>>>
>
>
> --
> Connor McDonald
> ===========================
> blog: connormcdonald.wordpress.com
> web: http://www.oracledba.co.uk
>
> "If you are not living on the edge, you are taking up too much room."
> - Jayne Howard
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Sun May 10 2015 - 23:04:48 CEST

Original text of this message