Raj - Thanks for sharing the details of how this method works in practice for you.
Dennis Williams DBA, 40%OCP Lifetouch, Inc. [EMAIL PROTECTED] -----Original Message----- Sent: Monday, January 06, 2003 1:44 PM To: Multiple recipients of list ORACLE-L 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----- <mailto:[EMAIL PROTECTED]> ] Sent: Monday, January 06, 2003 2:14 PM To: Multiple recipients of list ORACLE-L 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] -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
