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
[EMAIL PROTECTED]
L To: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
Sent by: cc:
root@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@TDWater To: Multiple recipients of
list ORACLE-L <[EMAIL PROTECTED]>
house.com> cc: (bcc: Jack van
Zanen/nlzanen1/External/MEY/NL)
Sent by: Subject: Griping about
auditing (not the Oracle Kind)
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
