| 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)
Rama,
I've also worked with some top-notch consultants and contractors. Unfortunately, I don't always have input into the hiring and purchasing process. Sometimes you get blind-sided. My job is to make whatever comes in the door work. It's tough when you're faced with this kind of lunacy from a vendor.
David A. Barbour
Oracle DBA, OCP
AISD
512-414-1002
Rama Malladi
<rama_at_toyota. To: Multiple recipients of list ORACLE-L
<ORACLE-L_at_fatcity.com>
com> cc:
Sent by: Subject: Re: Griping about auditing (not
the Oracle Kind)
root_at_fatcity.
com
06/25/2001
06:40 PM
Please
respond to
ORACLE-L
David,
"This is about what I've come to expect from consultants/contractors" in
your mail does not speak very well of
you. Most of the Critical projects that I worked on are/were run by top
consultants and good employees.
So it is too vague and broad to generalize certain job types. If you hired
an incompetent consultant, fault
also lies with you in not knowing the stuff that you are hiring ...
Just a thought...
Rama
DBarbour_at_austin.isd.tenet.edu wrote:
> 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).
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rama Malladi INET: rama_at_toyota.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). -- 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 Tue Jun 26 2001 - 12:51:41 CDT
 |
 |