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

  • From: "Mark W. Farnham" <mwf@xxxxxxxx>
  • To: <piontekdd@xxxxxxxxx>
  • Date: Tue, 18 Mar 2008 17:26:55 -0400

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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
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. 
etc.

YMMV
Bradd Piontek
piontekdd@xxxxxxxxx



On Tue, Mar 18, 2008 at 9:29 AM, Nuno Souto <dbvision@xxxxxxxxxxxx> 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@xxxxxxxxxxxx

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



 

Other related posts: