Rachel Thanks for the clarification. We haven't yet been hit with an issue arising from the staging environment hardware not exactly duplicating production. Where we've used Windows servers it has been pretty obvious the O.S. environment must be a good duplicate. One of the methods we've used to sell management on the "bang for buck" ratio of the 3-environment setup has been that staging can have some h/w compromises -- fewer CPUs, less memory, cheaper/fewer disks -- hopefully that won't come back to bite us. Sometimes we have put staging and test on the same Unix server, although this is usually more trouble to explain to managers than it is worth. And we are just performing functional testing, not load testing. Definitely for load testing you need to closely duplicate the H/W. Dennis Williams DBA Lifetouch, Inc. dwilliams@xxxxxxxxxxxxx -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Rachel Carmichael Sent: Tuesday, June 08, 2004 10:23 AM To: oracle-l@xxxxxxxxxxxxx Subject: RE: CBO irregularity Dennis, I'm not sure what you're asking... if you want to know if I think a full refresh of the staging environment from a production backup is a good idea, yes I do. Our problem was not that the data was a subset, it wasn't. The environment itself is not exactly duplicated. In production we have two database servers, in QA/stage we have one. In production, multiple applications run on the various app servers and hit the databases at the same time. In the QA load test, because the servers are smaller than production, we ran only the application we were porting. And in QA, without competition, it ran fine. I do believe that unless QA and production are mirrors, in terms of hardware as well as software, then you do not have a true QA environment. I *still* get the "sit down and shut up" response when I say that though. Rachel --- DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx> wrote: > 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. > > __________________________________ 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 -----------------------------------------------------------------