RE: Remote Storage Mirroring vs Dataguard - Important
Date: Sat, 9 May 2015 14:43:20 -0400
Message-ID: <042101d08a88$06a9c8c0$13fd5a40$_at_rsiz.com>
AND, if you had access to a production class server at the recovery site (perhaps from a shared pool of recovery site assets, perhaps privately owned and maintained with the exact OS patches of the production server), then it might be cost effective to transfer the licenses in the event the primary site is declared dead.
Thus, your recovery on storage local to the recovery site proceeds just fine licensed on the minimum number of CPUs that will keep up.
Once “the primary site is dead” is declared you commission the production class server on the storage farm of the wee recovery server. Depending on the slack time available for database and application software being up at the recovery site that is supplied by physical world logistics, this may be a big win, but far less of an outage than getting new servers available and running the right OS software from scratch.
As Connor notes a seamless failover in the face of a site disaster is often comedy (as long as a complete recovery is ensured within a reasonable time frame) compared to everything else that must be done to execute business continuation.
By way of explanation of why you probably *DON’T NEED* seamless failover in such a case the whole IT department should be engaged in a definition of the whole shooting match along with elapsed time estimates for the existing transfer plans.
This can then become something of a “Method R” for rationalizing what aspects of the business continuation plan should be worked on IF the projected elapsed time to business continuation does not meet your service level agreements or fuzzy goals.
mwf
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Connor McDonald
Sent: Saturday, May 09, 2015 5:30 AM
Cc: ORACLE-L
Subject: Re: Remote Storage Mirroring vs Dataguard - Important
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 DBA http://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-lReceived on Sat May 09 2015 - 20:43:20 CEST