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

All good observations. My experience is that you should also consider loads on the production SAN versus loads on a test system SAN. Instantiation once in a while of the "whole thing" combined with the passive trickle feed of archived redo logs is *potentially* a lot less load on the production SAN, whether the copying from or "resilvering" after a split. Usually the read of the archived redo logs can be completely segregated from other i/o loads such that it has negligible affect on production.  

As you said, your mileage may vary. If the volume of changes is small compared to the total database size, that tends to favor recovery. Even though you eventually copy the entire database to produce a refreshed TEST, that SAN load occurs on the test SAN, not the production SAN, except if a re-instantion is required. Whether you have to license a TEST database used purely for determining whether functionality is correct is an interesting question.  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Bradd Piontek
Sent: Tuesday, March 18, 2008 2:51 PM
Cc: ORACLE-L
Subject: Re: sync up production to UAT for a 500G+ database  

Below is where I am confused. While I have used EMC MirrorView and Snapview to do just this, I am curious as to where the 'cheaper' comparison comes in? From a licensing cost standpoint, whether I'm using some SAN vendor's disk tool, Some Oracle technology or home-grown database cloning technique, or some other third-parties software, I will need to license the test database. Maybe it is our contracts at my particular company. If I have EE licensed in production, I will have EE licensed in test. (Granted, we don't have to license per-cpu, and can do the minimum named user per our contract).

Now, from a time and effort standpoint, I have found SAN replication to be easier and quicker for me, the DBA. (maybe not so for the SAN administrator, you'd have to ask him :) ).

It might be nice to get to the core of the question rather than getting on a tangent. Not only does the original poster what to duplicate a 500+GB database, they want to be able to make changes to it during the day, and then have it re-synced with production nightly. I think some valid solutions to this question have been posted.

1. Use your SAN vendor's tools to do fancy things at the disk level. 
2. Refresh from a known backup nightly from prod.
3. Use RMAN duplicate. 

YMMV
Bradd Piontek
piontekdd_at_gmail.com

On Tue, Mar 18, 2008 at 9:29 AM, Nuno Souto <dbvision_at_iinet.net.au> wrote:

Exactly. Let's recap for a second:

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

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

--

http://www.freelists.org/webpage/oracle-l Received on Tue Mar 18 2008 - 16:26:55 CDT