Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Pre-Approved database changes

Re: Pre-Approved database changes

From: Michael Thomas <mhthomas_at_yahoo.com>
Date: Thu, 17 Jun 2004 18:32:56 -0700 (PDT)
Message-ID: <20040618013256.34110.qmail@web50603.mail.yahoo.com>


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


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_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 Thu Jun 17 2004 - 20:30:02 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US