RE: Testing Refresh Procedure

On our systems, I use RMAN to refresh a dev database from production. Then the developers apply their change scripts to move the objects to the next release level.  

Josh C.  

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of hitender chugh
Sent: Wednesday, March 22, 2006 2:16 PM
To: oracledba.williams_at_gmail.com
Cc: danielwfink_at_yahoo.com; oracle-l_at_freelists.org Subject: Re: Testing Refresh Procedure

That's the requirement as the pl/sql code is still in the testing stage at lower levels and is not yet approved to moved to production.

From: "Dennis Williams" <oracledba.williams_at_gmail.com> To: chughhk_at_hotmail.com
CC: danielwfink_at_yahoo.com, oracle-l_at_freelists.org Subject: Re: Testing Refresh Procedure
Date: Wed, 22 Mar 2006 16:06:27 -0600

Chugh,

My requirements is also similar where I have to refresh the lower regions

(databases - development,system,acceptance etc.) from production data but not
the functions,procedures,packages etc. very frequently. I use exp, and imp data
after disabling triggers,fk constraints and truncating tables. 

The advantage of cloning techniques compared to export/import is that you receive an exact replica of the production system. Why would you want to exclude functions, procedures, packages, etc.? The idea is that before a change is promoted to production it is tested against a current copy of production. The worst circumstance is that you promote something to production only to discover after much anguish that production has a different version of a function, procedure, package, or etc. than the test database.  

Dennis Williams

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

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