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

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,  

mwf  

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 <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> wrote:
>
>I am not sure how Mirrorview license works but with DG you pay per instance
per
CPU so it gets damn expensive.....
>
>
>--
>LSC
>

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






-- 
Cheers,
-- Mark Brinsmead
Senior DBA,
The Pythian Group
http://www.pythian.com/blogs 




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