RE: Griping about auditing (not the Oracle Kind)

Okay, my situation doesn't seem so bad now. Thanks!

The rules are mitigated by a number of sensible managers here and there who do their best to see that things hold together.

And I won't comment in a public forum as to whether something necessary has occasionally been done while paperwork is still being processed...

-----Original Message-----
Sent: Tuesday, June 26, 2001 1:20 AM
To: Multiple recipients of list ORACLE-L

I can supply the commiseration! You have my sympathies. I just left my last job (also at a major online brokerage) because of exactly the same sort of nonsense. In the "good old days" things ran fairly smoothly, technical people made technical decisions, and the job was great. Then we got very big fast, hordes of new clueless managers and executives came in and gradually started insisting on micro-managing everything. (e.g. "Check your database files into the configuration management system and update them whenever they change." After some discussion and determining that they REALLY meant the database files, not the model, I explained that this was an absurd request. We had 42 production Oracle databases with terabytes of datafiles! Another example, someone had come up with an 40+ page list of items that should be documented for every database system. Not 40+ pages of documentation, a 40+ page list of items to be documented! It included everything they had ever heard of, whether even remotely relevant or not. Much of it was very specific to IBM mainframes - their previous environment. Pages of stuff like "CPU temperature" was to be statically documented in MS Word! When I started sending them dynamically generated ASCII reports on things like space utilization, datafile lists, and the like, I was told that the format was unacceptable - it had to be MS Word in the format that they had dictated or Power Point (!) also in a format that they dictated. My "failure to comply" and "lack of the teamwork spirit" on this insanity was duly noted. It was like Dilbert's worst nightmare.)

For almost two years I tried to get them to see the error of their ways. No luck. It only got progressively worse. Not all, but the majority of management absolutely insisted on complete authority, but just as adamantly denied any responsibility. The concept that the two go together seemed entirely foreign to them. A month ago, I decided I couldn't take it anymore - that even sleeping in a refrigerator box and eating from a dumpster would be preferable. Where there is no professional respect and no accountability, there is no hope.

I am not saying that this is your situation. I am just saying that what many others are recommending works only if the decision makers have some modicum of logical reasoning capability and some sense of responsibility. Most do, but it is highly dependent on the "corporate culture". Yours environment sounds a lot like the one I just escaped from was about a year ago. Perhaps it is more prevalent in that particular industry. Brokerages tend to be a bit stodgy. Up until last November, we still had a dress code that included "long sleeve dress shirt, preferably white, tie, dress slacks, polished shoes, ...", etc. When I started there in 1997, they had a corporate dress code that included "no beards" and "women can't wear slacks, only dresses or skirts"! When they wanted to hire me, the major point of the negotiation was over their insistence that I shave off my beard! This "negotiation" lasted over three weeks! I refused. They insisted. I said I wasn't interested if it involved shaving. They called back and upped the offer. I still refused. There were about a dozen rounds of this before they finally they gave in and hired me anyway. I guess I did make at least one significant and lasting change there - they long ago abolished the "no beards for men. no slacks for women" policy! Of course, that was long before the current management took over!

I never let, and would not recommend letting, a system suffer because of bad management. I would just do what actually needed to be done and suffer the political consequences. It is the lesser evil by far.

-Don Granaman
[certifiable and temporarily "semi-retired" OraSaurus]

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Monday, June 25, 2001 11:06 AM

> Frankly, I can understand the concern about data (we're a brokerage and
have
> lots of customer account information). But having a non-technical person
> approve adding a datafile? And then another non-technical person review
> that the adding was done according to an approved form? Is it obvious
that
> a non-technical person was setting the audit requirements and not
listening
> when I said it was pointless?
>
> A DBA on another database had his request to increase the next extent size
> on a table refused on the grounds that "what if this change causes the
> database to go down?". His explanation that having a table that was over
> 5,000 extents and growing rapidly was far more likely to cause problems
was
> rejected on the grounds of "if it ain't broke don't fix it. If you say it
> is broke then why is it we aren't having any problems?"
>
> I wasn't looking for confirmation that this is silly (I know it is) so
much
> as just wondering if anyone else has had to deal with this level of
> bureaucracy. And maybe a little commiseration :)
>
> Thanks for helping me get it off my chest,
> Jay Miller
>
> -----Original Message-----
> Sent: Monday, June 25, 2001 11:07 AM
> To: Multiple recipients of list ORACLE-L
>
>
> One of the reasons DBA's are paid well is that they have total control
over
> the production data. No matter what rules the auditors put in place, a
DBA
> could manipulate the data if they wanted to. The company should trust you
> to do your job and not put up read blocks that prevent you from
maintaining
> the database and making changes in a timely manner.
>
>
>
> -----Original Message-----
> Sent: Monday, June 25, 2001 9:32 AM
> To: Multiple recipients of list 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).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Smith, Ron L.
> INET: rlsmith_at_kmg.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: 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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Don Granaman
  INET: granaman_at_home.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: 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).