Oracle-L: RE: Help with Import

From: Jamadagni, Rajendra <Rajendra.Jamadagni_at_espn.com>
Date: Mon, 06 Jan 2003 11:44:04 -0800
Message-ID: <F001.00527E11.20030106114404@fatcity.com>

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-----
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.
dwilliams_at_lifetouch.com

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Jamadagni, Rajendra
  INET: Rajendra.Jamadagni_at_espn.com

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: ListGuru_at_fatcity.com (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).



text/plain attachment: ESPN_Disclaimer.txt

Received on Mon Jan 06 2003 - 13:44:04 CST