RE: CBO irregularity

  • From: DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx>
  • To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 8 Jun 2004 10:35:09 -0500

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
-----------------------------------------------------------------

Other related posts: