| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: CBO irregularity
Fuad
Thanks for the clarification. Familiar with HIPAA. I don't think this would violate ITIL. Under ITIL, there is no reason for developers to have access to staging (the exact copy of production), particularly if they are excluded from production anyway. The developers develop on test and provide scripts that will update staging. An administrator(s) execute the scripts and then the users test. If the scripts fail, then it is bounced back to the developers for correction. If the scripts succeed and the testing succeeds, then the same persons who ran the scripts on staging run them on production. It is perfectly acceptable for the test environment to be different in terms of data as long as everyone realizes this may mean more failures because their environment is different. Frankly my personal opinion is that following these formal procedures may cause additional delays and additional work in the short term. But as these systems become more important to companies, we must guard against production failures. ITIL is mainly focused on reducing production failures.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]On
Behalf Of Fuad Arshad
Sent: Tuesday, June 08, 2004 11:03 AM
To: oracle-l_at_freelists.org
Subject: RE: CBO irregularity
Well from our perspective its the HIPAA compliance that we have to be in
and on top of that there is Sarbaines-oxley which ( and i couldnt find the
document to quote becuase its under a pile of the other million important
documents) s the fact that Data should not be available to any other parties
including development groups.
the sarbaines-oxley was basically created to try to set up a paper trail for
every bit of information passed to avoid any future enrons
keeping this in mind i think we should start a discussion on how everyone
else is setting up to meet sarbaines-oxley compliance as well.
there is some q&a here
http://www.rampant-books.com/art_nanda_interview_securing_dbms.htm
<http://www.rampant-books.com/art_nanda_interview_securing_dbms.htm>
DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM> wrote:
Fuad
We haven't been hit with Sarbaines-Oxley yet. I first heard of CoBIT in
Jared's posting this morning. Can you explain why staging cannot be a
duplicate of production under Sarbaines-Oxley requirements? ITIL requires
it.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]On
Behalf Of Fuad Arshad
Sent: Tuesday, June 08, 2004 10:24 AM
To: oracle-l_at_freelists.org
Subject: RE: CBO irregularity
Dennis,
the strategy is really good.
except as jared mentioned and one of the issues we all have is the
Sarbaines-oxley which is coming to effect and has the fact that staging
cannot be a copy of production.
Unless you have a way to change the data to the effect that it doesnt look
like production
Also i'm glad you get enough space to not only duplicate production as
staging but also get to test a production strategy. How fortunate of you.
DENNIS WILLIAMS 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.
-----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 9:44 AM
To: oracle-l_at_freelists.org
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
________________________________ __
-- 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 a t 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 ----------------------------------------------------------------- ---------------------------------------------------------------- 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 - 11:39:42 CDT
 |
 |