RE: Some Dataguard is good, lots more must be better?

From: "Connor McDonald" <mcdonald.connor@xxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Date: Tue, 19 Sep 2006 21:54:50 +0800

My only gripe with DG, is the license fee....no more of that nice "if you
only use some of the time" stuff anymore - it gets licensed as if it was a
fully fledged always-on database...
 
Suddenly a great product looks like a dud one...simply due to the cost.
 
Cheers
Connor


  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Carel-Jan Engel
Sent: Monday, 18 September 2006 7:18 AM
To: exriscer@xxxxxxxxx
Cc: kevinc@xxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: Re: Some Dataguard is good, lots more must be better?


Oh, and then I forgot the independency of storage vendors. There is no
requirement to have the same storage for every system. E.g. one of my
customers runs production on NetApp, and both the local and remote standby
on DASD.

It just depends on your requirements. 

Or better, it depends. 


Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok)
===     

On Mon, 2006-09-18 at 00:21 +0200, Carel-Jan Engel wrote:


It's not only the writes (can you do that synchronously for many databases,
and I mean REALLY synchronously?)
What I like very much in DG is the DELAY feature. Having a database running
4-8 hours behind appears to be very useful for logical failures. Not only
humans causing problems, but also during e.g. an Oracle upgrade. I stop the
standby, upgrade the primary, and when everything is fine with the primary
just restart the standby with the new $OH. When the upgrade flaws: just
start and activate the standby. 

One customer has all its databases (with an ASP app) running 2 days behind
at the DR site.
This database is open READ ONLY throughout the day, and gets synced with all
the received redo early in the morning. This is used very commonly by the
helpdesk to restore 'mistakenly thrown away data' on behalf of the
customers. It turned out to be a nice USP!

When all the DG stuff is scripted properly a failover/switchover can be
performed by the DBA easily. No dependencies of SA's or the Storage Dept.
Instantiate: one single command and it is taken care of. 

Regarding the upgrade Oracle thing: what is the granularity of a failover
when using storage replication? A server or a DB? With DG I can easily move
a single database to another site. Is this possible with storage
replication? Or should we failover the complete storage with all databases?
How is this dealt with administrator-wise? Do we need to involve more
people, creating more dependencies? 

RMAN can create backups using the standby. How to deal with rman backups
when using storage replication? RMAN can be pretty I/O intrusive. Of course
one could choose not to use RMAN at all.

Just a few thoughts ;-)

Carel-Jan



On Sun, 2006-09-17 at 21:47 +0200, LS Cheng wrote: 


Hi
 
Recently I was on a site who run a DG for each instance, the server with
highest number of instance was 4 though. In total they have around 12
instances so 12 DG. Whenever they have a new instance they create a new
Service Guard package which includes a ORACLE_HOME (right now for example
they have 12 ORACLE_HOME), a new DG. 
 
For a 1.5TB new Database with static data I suggested to create a new
instance, they were cautious because that meant a lot of work!
 
 
rgds
 
 
On 9/17/06, Kevin Closson <kevinc@xxxxxxxxxxxxx> wrote: 




I know some of you folks have large SMPs as the result of consolidating from

a lot of little SMPs into one large one for managability sake. What about
distaster 
recovery?  If you have, say, 20 databases in a large SMP, do you set up 20
"streams" of 
DG to a DR site?  Is that a nightmare?  Are there any sites out there that
have, say, more 
than 10 databases that require disaster protection where DG is the tool of
choice? Or 
do such sites opt to replicate at the storage (or volume e.g., Veritas VVR)
level? 

Yes, Carel-Jan will remind us  that replicating at the storage level
requires replication of 
all writes as opposed to just sending redo pieces. 

Thoughts ? 





Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok)
===

Follow-Ups:
- RE: Some Dataguard is good, lots more must be better?
  - From: Carel-Jan Engel

References:
- Re: Some Dataguard is good, lots more must be better?
  - From: Carel-Jan Engel

RE: Some Dataguard is good, lots more must be better?

Other related posts: