Sarbaines-oxley is a law which pretty much every unit in an organization has to deal with . This includes dba's as this law makes it tough for every company without a proper change control can be audited and fined. Most of US companies are dealing with this. Jared my addition would be Jared My Addition would b Database Upgeades/Critical Patch fixes Development and qa data migrations Creation of extra/new indexes. And the biggest of all Developer access to production Servers. -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Thomas Sent: Thursday, June 17, 2004 8:33 PM To: oracle-l@xxxxxxxxxxxxx Subject: Re: Pre-Approved database changes Hi, I'm confused (..as usual..I heard that..) because I have a basic problem with the subject. How does Sarbanes-Oakly (SO) define database changes that a DBA needs to document (general rule is sufficent)? Why would many of the tasks of a DBA administrator, w.r.t. CCG (change control group), be restricted to 'pre-approved database changes'? The business owns the data, the users change the data, and the DBA administers the data repository. Does the CCG pre-approve every user change to data through an application? Depends on the data, and there may be strange examples where the answer is yes. An DBA administrator is similarly operating an Oracle database application. Two exceptions, however. 1) Developers. If the application developers, or database developers wish to change/convert/transform/ translate data (application development changes involving data content type changes) then those tasks might require 'pre-approved database changes'. Depends on the data, really, just like data changes by the application users. Keep in mind its worthless to have a data controlled by a certified application with ID 10 T users (that's an acronym for idiot users). Every user of such application requires a system specific training or proof-of-competence certificate. This is the process to avoid pre-approval of every user data change via the application. 2) *Code* and *Data* changes. Tuning SQL that changes application *code* might or might not require CCG controls. If required, these could be pre-approved on a per-project basis with a pre-defined, pre-documented process, testing of results with data, and might include a document describing the implemented *code* changes (user *data* may not change). The 'might not' test for documenting a *code* change can apply if the original application code is not similarly documented, given valid reasons the original code is not documented. There should be little need to pre-approve any DBA 'discretion' for administration, unless you have ID 10 T DBAs. The same system specific training or proof-of-competence certificate applies to DBAs that applies to other application users. If the 'pre-approved' CCG process fails, no problem. Simply repeat if the the process fails. I say give'em pagers, too. ;-) This helps explain why 'database administration' is not in the 'task specific' CCG scope while some *data* and *code* changes would be. As an aside, just for fun: Say vendor XXXXXX's off-the-shelf Sarbanes-Oakly certfied product fails because of a RI constraint or uniqueness. Why would the DBA be required to fix the data? Doesn't vendor XXXXXX guarantee RI and uniqeness with SO certification? The rebellious DBA in me would not worry about documenting these type changes, either. Sorry if I'm Sarbanes-Oakly ignorant and I've just made it apparent. HTH. Regards, Mike Thomas --- Jared.Still@xxxxxxxxxxx wrote: > oracle-l-bounce@xxxxxxxxxxxxx wrote on 06/17/2004 > 04:05:18 PM: > > > .... > > True, but I have no desire to try and document when it should and > shouldn't be done. This is one if the areas that will still require > some DBA discretion. > > I don't want to go to CC to get approval to generate stats for a > single table that has had a lot of DML activity and now gets a useless > plan. Not too often but it does happen occasionally. > > Thanks, > > Jared > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail ---------------------------------------------------------------- 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 -----------------------------------------------------------------