Re: Pre-Approved database changes
- From: Michael Thomas <mhthomas@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Thu, 17 Jun 2004 18:32:56 -0700 (PDT)
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
-----------------------------------------------------------------
Other related posts:
