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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
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
