| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Help with Import
Hi,
We use a slightly different approach here...
We have a couple of development environments which get refreshed with a subset of data (using Princeton Softech's "Move for Servers") every so often. The system testers also have a couple of environments like this. These environments are good for checking basic functionality and for creating specific scenario's to test exception handling, etc.
We also have a full volume test environment (about 1TB) which is a complete replica of production - same hardware, same data, only passwords changed. The is refreshed before any significant performance testing where a clean environment is required. The refresh is created by restoring database and archive log files from production and then recovering the database (sorry, I don't know the real nitty gritty since this is not something I do personally).
The system test teams verify any database scripts against this environment
(after they have been unit tested in one of the development environments).
Naturally the volume test environment is the playground for any scripts
where performance is a concern. Also, since the environment is normally
only a couple of weeks old a lot of data investigations can be done in this
environment, saving some load on production.
To be honest, having a replica of production like this is a god send. Previously I worked on a large data warehouse where all testing / development environments were tiny by comparison and it was much harder to make any guarantee of performance. Here I can say "this script is going to take 25-35 minutes when run in production" with confidence.
I don't know who convinced the business to duplicate all hardware, but my thanks go out to them. I do know that the volume test servers are nominated as failover servers if for some reason production was down for several days - our system can effectively operate for 2-3 days without a database before data is lost so instant failover isn't required.
Regards,
Mark.
DENNIS WILLIAMS
<DWILLIAMS_at_LIFE To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
TOUCH.COM> cc:
Sent by: Subject: RE: Help with Import
root_at_fatcity.co
m
07/01/2003
08:33
Please respond
to ORACLE-L
Raj - Thanks for sharing the details of how this method works in practice for you.
Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----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
QOTD: Any clod can have facts, but having an opinion is an art!
-----Original Message-----
<mailto:DWILLIAMS_at_LIFETOUCH.COM> ]
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: DENNIS WILLIAMS INET: DWILLIAMS_at_LIFETOUCH.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-LReceived on Mon Jan 06 2003 - 16:44:23 CST
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing). <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Privileged/Confidential information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply e-mail or by telephone on (61 3) 9612-6999. Please advise immediately if you or your employer does not consent to Internet e-mail for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of Transurban City Link Ltd shall be understood as neither given nor endorsed by it. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mark Richard INET: mrichard_at_transurban.com.au 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).
 |
 |