Rachel Please forgive my question, but I'm still fairly new to this 3-ring circus. My objective is to refresh the staging environment by recovering the production backup. This will accomplish two objectives: 1) Create an exact duplicate of production. 2) Test the production backup, a vital task which never seems to get done otherwise. I have always been opposed to the idea of staging being a subset of the production data. While it sounds good in theory, I feel there are too many problems with this approach. And you can't test your backup. If you see any flaws in my logic, please let me know. Naturally, in the hurly-burly of the daily life of a DBA, the ideal is not always met. If is tempting to feel the staging database isn't yet stale so doesn't need refreshed immediately, even though the commitment is to refresh it before a large implementation. The development environment of course is a whole different issue, usually treated as a developer playground. -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Rachel Carmichael Sent: Tuesday, June 08, 2004 9:44 AM To: oracle-l@xxxxxxxxxxxxx Subject: RE: CBO irregularity there is dev, QA and production and then there is dev, QA and production I have all 3 environments, supposedly. QA does not accurately mimic production and in fact, we almost had to roll back a major production release because real load showed problems not found in the QA load test. Dev is even worse... but TECHNICALLY we have all 3 environments --- Jared Still <jkstill@xxxxxxxxxx> wrote: > On Tue, 2004-06-08 at 07:14, DENNIS WILLIAMS wrote: > > ... > > wanted to congratulate you for having 3 environments (development, > QA, > > production). At least it sounds from your posting that you are > finding most > > ... > > Many more of us in the USA will be seeing dev,QA/test and production > environments thanks to the Sarbanes-Oxley act, section 404. > > Accountability and the CoBIT standard will force the issue. > > Jared > > > ---------------------------------------------------------------- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > ---------------------------------------------------------------- > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > put 'unsubscribe' in the subject line. > -- > Archives are at //www.freelists.org/archives/oracle-l/ > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > ----------------------------------------------------------------- __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------