Dennis,
We do almost the same thing that you described.
We have a 140G database. Everyday we *clone* that production database and call it 'DAYOLD'. This database is used by app support to investigate data related issues and bugs. But a day before release, we run *all* scripts sent in by developers on this database. It they fail on dayold database, the whole request (and any dependencies) are pulled from the release, if not fixed within 30 minutes from reporting.
It has been working very well for us for more than 8 months. We clone 4 such databases of varying sizes everyday. These usually get refreshed after the hot backup on the specific database. The cloning process (and locking down of schema and scrambling of sensitive information is part of cloning) is usually finished by 5:30am except Sunday.
Yes, and we use the same script on production ... with different passwords. What do you do for multi-schema releases? We change passwords of all schema to a known value and put "conn blah/blah" like statements in the script that calls all developer supplied scripts. Once the release is complete, it re-sets all passwords back to what they were, and fires a compile_all script to fix all the invalid stuff.
Raj
______________________________________________________
Rajendra Jamadagni MIS, ESPN Inc.
Rajendra dot Jamadagni at ESPN dot com
Any opinion expressed here is personal and doesn't reflect that of ESPN Inc.
QOTD: Any clod can have facts, but having an opinion is an art!
-----Original Message-----
From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 06, 2003 2:14 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Help with IMPort
Michael - Yeah but the developers are always whining about something anyway
:-) Just kidding. Yes, timing of the refresh can be an issue. We are looking
toward a staging environment. Now that will be identical to production. Then
we can execute a script that will create or modify tables and other objects,
and test the new release. If all goes well, then the same script can be used
on production. The actual test system where the developers play should have
more modest requirements in terms of amount of data, frequency of refresh,
etc. Anyway, this is the environment we are moving toward.
Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
[EMAIL PROTECTED]
*********************************************************************This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you.*********************************************************************1
