RE: CBO irregularity

From: Shreeni <shreeni_at_sbcglobal.net>
Date: Tue, 8 Jun 2004 10:28:48 -0500
Message-ID: <000901c44d6d$4bb84cc0$180c16ac@JAISRIRAM>

The last time I suggested this to mgmt ( abt QA/Prod servers ) my CTO said these words " Dont' walk in IT wonderland Mr DBA " and all & sundry in the meeting laughed till they watered in the eyes and gave me the I-told-u-so look.

Shreeni

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Rachel Carmichael
Sent: Tuesday, June 08, 2004 10:23 AM
To: oracle-l_at_freelists.org
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_at_LIFETOUCH.COM> 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_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://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_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Tue Jun 08 2004 - 10:41:30 CDT