RE: Testing Refresh Procedure
- From: "joshc" <collier_jw@xxxxxxxxxxx>
- To: <chughhk@xxxxxxxxxxx>, <oracledba.williams@xxxxxxxxx>
- Date: Wed, 22 Mar 2006 14:37:44 -0800
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of hitender chugh
Sent: Wednesday, March 22, 2006 2:16 PM
To: oracledba.williams@xxxxxxxxx
Cc: danielwfink@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxx>
To: chughhk@xxxxxxxxxxx
CC: danielwfink@xxxxxxxxx, oracle-l@xxxxxxxxxxxxx
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
-- //www.freelists.org/webpage/oracle-l
Other related posts:
