| 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: Griping about auditing (not the Oracle Kind)
One of the ways around this is to have "Executive Delegation" set up within your change management procedures. Generally this boils down to recognizing that there are some areas where your "experts" (generally the SA and DBA) have more knowledge and need more flexibility than developers, contractors and the like.
Interestingly enough, I'm proposing a change management procedure for my current employer. This is in response to a contractor who changed the TEMP tablespace on three instances to contents permanent late Thursday night. Friday, users started having problems with their reports. Here was their explanation:
"-- [Contractor] says: [Application]assumes that there is a tablespace called "temp".
We create all of our "temporary" tables there, so that it isn't too
difficult to clean them out at some point. This is necessary because
Oracle does not support the "temporary table" concept we use under
Informix.
-- So instead of creating temp tables, under Oracle we create
permanent
tables in the "temp" tablespace, then remove them when we are done
(assuming the program does everything correctly and doesn't crash).
-- They need to add a tablespace called "temp", which should be at
least
a few hundred MB (similar to the Informix temp dbspace).
-- I think you can't specify TEMPORARY when creating the
tablespace, because Oracle won't allow tables to be created in a
temporary tablespace. The size they used may not be large enough;
normally we allocate 500 MB or more (it needs to be big enough to hold
the largest "temporary" tables that [Application]would ever create).
Also, they
should make the "next extent size" large than 256k because they could
run out of extents -- probably something in the 1-5 MB range would be
better."
I don't think their company has an Oracle DBA on staff (Yosi - you interested?). Global Temporary tables notwithstanding, this is about what I've come to expect from consultants/contractors. My change management procedure has under it's "Executive Delegation" section, the following caveats:
The Executive can delegate authority to appropriately qualified people (referred to in this document as the Delegated Authority) to authorize a change. The delegation will be documented and will form part of the Managed Product List, and will state as a minimum:
· specification of the areas covered by the delegation;
· the extent of the delegation and any restrictions on the authority;
· the period for which the delegation applies;
· that the Delegated Authority has had the appropriate education and
training to carry out the delegated task;
· any reporting actions required of the Delegated Authority;
· any review period for the delegation.
Documented administrative procedures that have been approved as such by the Executive can be implemented without individual approvals from the Executive as long as each change is implemented according to the authorized procedure. However, changes to the administrative procedures require reauthorization by the Executive.
David A. Barbour
Oracle DBA, OCP
AISD
512-414-1002
nlzanen1_at_EY.N
L To: Multiple recipients of list ORACLE-L
<ORACLE-L_at_fatcity.com>
Sent by: cc:
root_at_fatcity. Subject: Re: Griping about auditing (not
the Oracle Kind)
com
06/25/2001
10:22 AM
Please
respond to
ORACLE-L
Hi,
Been there recently
We had change management here breathing down our necks at one point. They wanted everything documented and approved. I flooded them with change request forms (even for changing a users password on the test database) and within two days they wanted a meeting about what we ,DBA's, thought should be approved and documented.
We now only have to make sure no other stuff is scheduled by the UNIX boys on the same machine if we do something that could conflict with OS stuff.
Jack
PS: The funniest thing is that the reviewers in general have no clue about what's going on.
"Miller, Jay"
<JayMiller_at_TDWater To: Multiple recipients of
list ORACLE-L <ORACLE-L_at_fatcity.com>
house.com> cc: (bcc: Jack van
Zanen/nlzanen1/External/MEY/NL)
Sent by: Subject: Griping about
auditing (not the Oracle Kind)
root_at_fatcity.com
25-06-2001 16:31
Please respond to
ORACLE-L
We've been through an internal audit and I was just wondering if anyone
else
has to deal with the rather ludicrous requirements I now have. In order to
add or resize a datafile I now need to fill out a form and get Senior VP
approval and the alert logs must be reviewed every day by a non-DBA in
order
to be certain that I didn't make any database changes without such
approval.
The auditors were horrified to discover that not only did I do such things
whenever I thought them necessary but that we didn't have a non-DBA review
everything I did after an Oracle upgrade to ensure I didn't install any
other software.
Fortunately I managed to convince them that yes, I really did need a Unix
login (they were skeptical).
So, any similar horror stories?
Jay Miller
Sr. Oracle DBA
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Miller, Jay INET: JayMiller_at_TDWaterhouse.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). ===================================================================== De informatie verzonden in dit e-mailbericht is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is, behoudens voorafgaande schriftelijke toestemming van Ernst & Young, niet toegestaan. Ernst & Young staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor tijdige ontvangst daarvan. Ernst & Young kan niet garanderen dat een verzonden e-mailbericht vrij is van virussen, noch dat e-mailberichten worden overgebracht zonder inbreuk of tussenkomst van onbevoegde derden. Indien bovenstaand e-mailbericht niet aan u is gericht, verzoeken wij u vriendelijk doch dringend het e-mailbericht te retourneren aan de verzender en het origineel en eventuele kopieën te verwijderen en te vernietigen. Ernst & Young hanteert bij de uitoefening van haar werkzaamheden algemene voorwaarden, waarin een beperking van aansprakelijkheid is opgenomen. De algemene voorwaarden worden u op verzoek kosteloos toegezonden. ===================================================================== The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed. You should not copy, disclose or distribute this communication without the authority of Ernst & Young. Ernst & Young is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. Ernst & Young does not guarantee that the integrity of this communication has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies. In carrying out its engagements, Ernst & Young applies general terms and conditions, which contain a clause that limits its liability. A copy of these terms and conditions is available on request free of charge. ===================================================================== -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: nlzanen1_at_EY.NL Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: DBarbour_at_austin.isd.tenet.edu Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Mon Jun 25 2001 - 13:41:22 CDT
 |
 |