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

From: Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx>
To: exriscer@xxxxxxxxx
Date: Mon, 18 Sep 2006 00:21:06 +0200

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 ? 
>         
>

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

References:
- Some Dataguard is good, lots more must be better?
  - From: Kevin Closson
- Re: Some Dataguard is good, lots more must be better?
  - From: LS Cheng

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

Other related posts: