RE: Pre-Approved database changes

From: Fuad Arshad <fuadar_at_yahoo.com>
Date: Thu, 17 Jun 2004 21:00:02 -0500
Message-Id: <20040618013927.B2AF672C11C@turing.freelists.org>

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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Michael Thomas
Sent: Thursday, June 17, 2004 8:33 PM
To: oracle-l_at_freelists.org
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.

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_at_radisys.com wrote:
> oracle-l-bounce_at_freelists.org 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_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 Thu Jun 17 2004 - 20:56:56 CDT