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

  • From: Carel-Jan Engel <cjpengel.dbalert@xxxxxxxxx>
  • To: mcdonald.connor@xxxxxxxxx
  • Date: Tue, 19 Sep 2006 16:43:11 +0200

Yes, agreed. It's not very cheap. Oracle should address that. In May, at
the end of FY, negotiations may result in significant discounts for
standbys. If seen discounts varying from 100 - 25%.

OTOH, compare it with RAC. (I know I don't have to this explain you,
Connor, but I feel the need to repeat this because so many sites are
following the Oracle RAC preachers without hesitation). For EE you pay
50% more. And you THINK you've got HA, Oracle marketing makes you to
believe this. However, you've got just server failover, no redundant
database. And people (beancounters) tend to forget that n-x nodes have
to deliver if x nodes fail. Given n=2 and x=1, you might need to double
the amount of CPU's, just to be able to run the normal load after a node
fails. There are quite some applications around that effectively stop
working if you cut away half of their CPU's. Not too much HA then,
despite RAC.

And how expensive is it to buy two Netapps/Celerras or whatever? What if
you trade in one of them and set up a nice DASD standby?

And then you have the lucky ones that run Named User Plus licences
based. If the requirements are met (IIRC, it least 25 users
licensed/CPU) you can add extra CPU's in the shape of a standby server
to your config without paying extra licenses!

Just my EUR 0.02 (which is slightly more than USD 0.02, but not enough
to cover for extra licenses)

Best regards,

Carel-Jan Engel

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

On Tue, 2006-09-19 at 21:54 +0800, Connor McDonald wrote:
> 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)
> ===

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 09-2006