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@LIFE To: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
TOUCH.COM> cc:
Sent by: Subject: RE: Help with Import
[EMAIL PROTECTED]
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.
[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).
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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: [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).
