Re: sync up production to UAT for a 500G+ database

Exactly. Let's recap for a second:

The original point was that *for a test
database*, Mirrorview (or similar SAN
replication) is cheaper than all the
paraphernalia required for DG.
That implies *not* using DG when using
Mirorview. Therefore, all considerations about DG in such an environment are
irrelevant.

I'd suggest we leave the subtleties of
parallel DG licensing and its relative
merits out of this.

The subject was a functional test
database and its associated costs.

Not a full-on HA environment in which of course other considerations kick-in.

Point is simple: done in a sensible manner, SAN replication is much cheaper for non-critical test database duplication than the current Oracle EE+DG licensing.

That may not be the case in future or may not have been in the past. It is now.

-- 
Cheers
Nuno Souto
dbvision_at_iinet.net.au


Mark W. Farnham wrote,on my timestamp of 18/03/2008 10:23 PM:


> I do not disagree /per se /with what Mark has written below.

> However:

> 

> 1)       Have you ever paid sticker price for a car?

> 

> 2)       The original poster carefully noted the target of this “sync 

> up” is a TEST database, very specifically **not** intended as a 

> recoverability target, and by implication from the current practice of 

> letting the TEST database get stale enough that the testers want that to 

> change, **not** part of the production processes.

> 

> 3)       Given that it is **not** part of the business continuation 

> thread, there is a real question of whether the holes you can seal up 

> with DG and the attendant automation provided by Oracle through DG are 

> worth the license fees as opposed to practicing physical recovery to 

> create a database local to the TEST database that can be copied after 

> cancelling recovery at the desired point in time. I believe that 

> practicing recovery every night is a useful way to test Oracle’s 

> suitability for your production operations on a continuing basis as 

> patches are released and features are added, and likewise cloning the 

> object of that physical recovery test provides a place where you can 

> TEST additional Oracle technology to consider whether it is executing 

> correctly against your data. On the other hand, if you were to use this 

> TEST database as a source of periodic data snapshots to load “as of” 

> figures into a datamart or datawarehouse that was then in turn used for 

> production reports and analyses, I could see Oracle making a case that 

> the TEST database was part of the production processes. I do not believe 

> that is the purpose of the original poster for this particular thread.

> 

>  

> 

> Regards,

> 

>  

> 

> ------------------------------------------------------------------------

> 

> *From:* oracle-l-bounce_at_freelists.org 

> [mailto:oracle-l-bounce_at_freelists.org] *On Behalf Of *Mark Brinsmead

> *Sent:* Monday, March 17, 2008 10:38 PM

> *To:* dbvision_at_iinet.net.au

> *Cc:* ORACLE-L

> *Subject:* Re: sync up production to UAT for a 500G+ database

> 

>  

> 

> Hmmm...

> 

> If you are using DataGuard, you need EE, don't you?  I'm pretty sure 

> that DG has never been available with SE, although that /might/ have 

> changed with 11g.  (I am pretty sure that looked when 11g was announced 

> and I don't /recall/ seeing any changes to DG licensing rules.  That 

> doesn't mean they weren't there, though.)

> 

> Now, while it is true that you don't /have/ to license EE by CPU, you 

> /do/ have to license a /minumum/ of 25 named users per CPU (with EE, 

> that is), which means /at least/ the 50% of the cost of CPU licenses.

> 

> There's one other little matter.  Last time I checked, you were required 

> to license your DG standby database with the /same licensing metric/ as 

> you have for the primary.  That is, if you use CPU licensing for the 

> primary database, you must use CPU licensing for the standby.  Of 

> course, nothing /requires/ you to have the same number of CPUs for the 

> standby -- unless you want to do something lavish, like load-testing or 

> performance testing.

> 

> Bottom line:  standby databases are generally far from free.  Or -- in 

> most cases -- cheap.

> 

> On Mon, Mar 17, 2008 at 8:51 AM, dbvision_at_iinet.net.au 

> <mailto:dbvision_at_iinet.net.au> <dbvision_at_iinet.net.au 

> <mailto:dbvision_at_iinet.net.au>> wrote:

> 

> And where was it said

> or implied it wasn't licensed?

> What it doesn't have to be is a

> full-on EE, CPU-based licence.

> 

> 

> On Mon Mar 17 20:03 , "Bradd Piontek"  sent:

> 

> 

>>Am I missing something? Whether you are using dataguard or not, you need to


> license the test database.

>>
>>
>>On Mon, Mar 17, 2008 at 3:55 AM, LS Cheng <exriscer_at_gmail.com 


> <mailto:exriscer_at_gmail.com>> wrote:

>>
>>I am not sure how Mirrorview license works but with DG you pay per 


> instance per

> CPU so it gets damn expensive.....

>>
>>
>>--
--
http://www.freelists.org/webpage/oracle-l