RE: Griping about auditing (not the Oracle Kind)
As you might have gathered from my previous e-mail I'm not a big fan of functional division as opposed to project division. Since I was moved to a different building from the developers much of the time I don't spend dealing with the new paperwork and bureaucracy I spend on the phone. I can see the temptation that people have to just say, 'don't think about working *with* the developers, just put their stuff into production and send it back if it doesn't compile' (this is my current job description), but I'm still holding onto doing some review, helping them with SQL, recommending hints, etc. Don't know how much longer I'll be able to keep doing it (though the appreciation and thanks from the developers helps a lot). My impression (this is confirmed by a friend who was a product manager at his company and is now leading a consulting team) is that this is the latest management fad. According to my friend this goes in waves, with everyone moving to functional division, then project division, then back again. He's been through a few shifts back and forth in his time. This is my first one. Jay Miller -Original Message- Sent: Thursday, June 28, 2001 7:52 PM To: Multiple recipients of list ORACLE-L On June 28, 2001 11:51 am, Miller, Jay wrote: > Yep, I've dealt with incredibly incompetent consultants (Because of > our new division of responsibilties, all programming must come from > the development team. I This brings up an interesting point - I've noticed that recently division of responsibilities is increasing and becoming more polarized. For example, in past incarnations, I was the dba, unix sysadmin, configuration manager, and responsible for software licenses for all software in the plant (in addition to whatever else the boss needed at that exact moment in time... :). Lately, however, I have started working on another project (in addition to my usual stuff) that has the sysadmin, development, "System" dba, and "Application" dba responsibilities spread across different group. Sysdba is handled by an Infernal Beuracratic Monster, sysadmin by somewhat Ejectable Data Sources, and Application dba stuff handled by we keaners. Very strange to have development arrive, review it for application impact, then send off any physical database change requests to another group. I don't seem any valid reason to stratify the various responsibilities in this manner as it only seems to add several more layers of beauracracy without adding any addition value. So, a) am I alone, or have others seen this sort of stratification, and b) is my griping simply the loss of turf and the slowly broiling coup to get it back, or is it somewhat valid? Cheers, GC -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Gregory Conron 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: 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).
Re: Griping about auditing (not the Oracle Kind)
On June 28, 2001 11:51 am, Miller, Jay wrote: > Yep, I've dealt with incredibly incompetent consultants (Because of > our new division of responsibilties, all programming must come from > the development team. I This brings up an interesting point - I've noticed that recently division of responsibilities is increasing and becoming more polarized. For example, in past incarnations, I was the dba, unix sysadmin, configuration manager, and responsible for software licenses for all software in the plant (in addition to whatever else the boss needed at that exact moment in time... :). Lately, however, I have started working on another project (in addition to my usual stuff) that has the sysadmin, development, "System" dba, and "Application" dba responsibilities spread across different group. Sysdba is handled by an Infernal Beuracratic Monster, sysadmin by somewhat Ejectable Data Sources, and Application dba stuff handled by we keaners. Very strange to have development arrive, review it for application impact, then send off any physical database change requests to another group. I don't seem any valid reason to stratify the various responsibilities in this manner as it only seems to add several more layers of beauracracy without adding any addition value. So, a) am I alone, or have others seen this sort of stratification, and b) is my griping simply the loss of turf and the slowly broiling coup to get it back, or is it somewhat valid? Cheers, GC -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Gregory Conron 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).
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" <[EMAIL PROTECTED]> 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
RE: Griping about auditing (not the Oracle Kind)
Yep, I've dealt with incredibly incompetent consultants (Because of our new
division of responsibilties, all programming must come from the development
team. I'd send pl/sql code to him, he'd change it so it didn't work and
send it back to me. I'd change it back. Fortunately his contract wasn't
renewed.), incredibly competent consultants (I'm still annoyed they didn't
renew the contract for our Unix SA, he was amazing. He had loads of Oracle
and Sun experience and redesigned our disk layout to vastly improve
performance, I knew enough to see what he was doing and give a little hints
because I knew where the i/o was, but he did most of the work), and those in
between.
As you say, a lot like people :).
-Original Message-
Sent: Tuesday, June 26, 2001 3:27 PM
To: Multiple recipients of list ORACLE-L
Rama;
Well, I also have to say I have worked with some very good and
knowledgeable consultants. But I have also worked with many more that were
as ou descibe. Unfortunately, I have also worked with many non-consultants
who could also be described that way.
I don't think its 'consultants' that are the culprit here. It more
'people'.
-Original Message-
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 26, 2001 10:51 AM
To: Multiple recipients of list ORACLE-L
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
com> cc:
Sent by: Subject: Re: Griping about
auditing (not the Oracle Kind)
root@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
[EMAIL PROTECTED] 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'
RE: Griping about auditing (not the Oracle Kind)
You mean you're not in on the conspiracy? You will be receiving a visit very soon... You know who had to train the non-DBA how to read the alert logs... In the end it's not so bad, primarily because my immediate manager (started as a good SQL server DBA and is now slowly going insane since he has to attend 3 Change Management meetings a day, at 7am, 2pm and 4pm) decided to use it as a training experience. The responsibility was given to one of the SQL Server DBAs as part of my training them in Oracle DBA work. So I no longer have the frustration of looking at it as a complete waste of time. Of course I suppose that once she is fully trained on Oracle and has joined the conspiracy someone else will have to take over reviewing the alert logs :). -Original Message- Sent: Monday, June 25, 2001 11:46 AM To: Multiple recipients of list ORACLE-L A non-DBA? Is that because we stick together like the Mafia or something?! g -Original Message- Sent: Monday, June 25, 2001 3:32 PM 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: [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: Guy Hammond 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: 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).
RE: Griping about auditing (not the Oracle Kind)
That's actually a good idea. We can control the world by taking over all the data. We will be so powerful. :) >>> [EMAIL PROTECTED] 06/25/01 11:45AM >>> A non-DBA? Is that because we stick together like the Mafia or something?! g -Original Message- Sent: Monday, June 25, 2001 3:32 PM 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: [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: Guy Hammond 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: Richard Ji 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).
RE: Griping about auditing (not the Oracle Kind)
Rama;
Well, I also have to say I have worked with some very good and
knowledgeable consultants. But I have also worked with many more that were
as ou descibe. Unfortunately, I have also worked with many non-consultants
who could also be described that way.
I don't think its 'consultants' that are the culprit here. It more
'people'.
-Original Message-
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 26, 2001 10:51 AM
To: Multiple recipients of list ORACLE-L
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
com> cc:
Sent by: Subject: Re: Griping about
auditing (not the Oracle Kind)
root@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
[EMAIL PROTECTED] 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
RE: Griping about auditing (not the Oracle Kind)
Kimberly; Absolutely. And I did not take ANY of your comments as Rude or Presumptuous. I am sorry my comments in my note drove someone to think that of you. -Original Message- Sent: Tuesday, June 26, 2001 11:22 AM To: Multiple recipients of list ORACLE-L This is the line I was commenting on... "I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend." I never once said that you should ignore the process put in place. What I said is that waiting until there is an issue is not doing your job. Fill in the paper work. If you are being proactive you have more then enough time to get that done before failure. Now if a manager fails to approve it despite your best attempts to get it approved that is another matter all together. But at least you have it documented that you knew it was an issue and that you attempted to fix it but your management would not let you. If, after all that, they try and tell you that you are not doing your job correctly then get the hell out. So I do not think I was either rude or presumptuous. Just failed to point out that I was really only commenting on that one line (which really stood out to me). -Original Message- Sent: Tuesday, June 26, 2001 1:15 AM To: Multiple recipients of list ORACLE-L Excuse me but you are a little presumptious and rude with that last mail. If a process is put in place that requires a form to be signed and authorisation to be given before action can be taken then I would be going totally against the grain and would get into trouble for not adhering to the company guidelines (as some of the UNIX S.A's did when they went in and made changes without filling out the necessary paperwork !!). On the contrary to your mail, I am a good DBA and I do take pride in my work and prior to the ridiculous rules that were put in place all work was done proactively and we never suffered because of it. What the managers (and "Quality Team", who had no bloody idea what their process would do to us) failed to realise was exactly how well I was doing my job, in that they were never bothered in the past. Once the mistakes were made and there was reactive form filling processes for certain things put in place, then things went back to normal. I think thats whats called a bite on my behalf!! -Original Message- Sent: 25 June 2001 18:16 To: Multiple recipients of list ORACLE-L I say that if you wait until you database has an error you really aren't proving much except that you are not proactive in your job. Which, in my book, makes you not a very good DBA. Dealing with a dumb process is one thing (we have our fair share on this account) but I take to much pride in my work to let things fail because I need to fill in a piece of paper. -Original Message- Sent: Monday, June 25, 2001 9:43 AM To: Multiple recipients of list ORACLE-L Wahey !!! The answer I was going to provide. We started calling the manager up quite frequently at home to authorise changes - he eventually saw sense. Not quite as bad as 2am in the morning but inconvenient enough for him to put a stop to it. Best of Luck. -Original Message- Sent: 25 June 2001 17:07 To: Multiple recipients of list ORACLE-L Jay; I have had to go thru the same thing a couple times on a previous job with Auditors. Every time those kind of restrictions were placed on us it brought things to a snails pace or, in some conditions, a complete halt. Sooner or later they realized that it was unreasonable and lifted them. But it was a pain until they did it. It took them a while to realize that we HAD to work the way we did in order to keep things running smoothly. I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend. At that time, call up the Sr. VP at 2 am in the morning and tell him that you have a crisis but you can not proceed until you get his permission because of the restrictions placed on you by the Auditors. Repeat this process as many times as neccessary for them to lift the restrictions. Kevin -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
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 com> cc: Sent by: Subject: Re: Griping about auditing (not the Oracle Kind) root@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 [EMAIL PROTECTED] 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'
RE: Griping about auditing (not the Oracle Kind)
Full authority and no responcibility - looks like very much an HMO. I don't think I would survive in this environment for so long. Maybe if I did not have where to go and had small children to feed. This is exactly what I posted. This is no win game and possible only if payd by the hour and payd very well. Alex Hillman -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" <[EMAIL PROTECTED]> 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 ha
RE: Griping about auditing (not the Oracle Kind)
Different situations . different solutions. Its all subjective. What will work at one location is like using a feather to stop an elephant at another. rather useless. -Original Message- Sent: Monday, June 25, 2001 1:31 PM To: Multiple recipients of list ORACLE-L Sorry but there are better ways. -Original Message- Sent: Monday, June 25, 2001 11:00 AM To: Multiple recipients of list ORACLE-L Well Kimberly, sometimes you have to do what you have to do to get a point accross. Depending on the type of employer you have, sometimes you have to take drastic measures that you would not normally take. -Original Message- Sent: Monday, June 25, 2001 12:16 PM To: Multiple recipients of list ORACLE-L I say that if you wait until you database has an error you really aren't proving much except that you are not proactive in your job. Which, in my book, makes you not a very good DBA. Dealing with a dumb process is one thing (we have our fair share on this account) but I take to much pride in my work to let things fail because I need to fill in a piece of paper. -Original Message- Sent: Monday, June 25, 2001 9:43 AM To: Multiple recipients of list ORACLE-L Wahey !!! The answer I was going to provide. We started calling the manager up quite frequently at home to authorise changes - he eventually saw sense. Not quite as bad as 2am in the morning but inconvenient enough for him to put a stop to it. Best of Luck. -Original Message- Sent: 25 June 2001 17:07 To: Multiple recipients of list ORACLE-L Jay; I have had to go thru the same thing a couple times on a previous job with Auditors. Every time those kind of restrictions were placed on us it brought things to a snails pace or, in some conditions, a complete halt. Sooner or later they realized that it was unreasonable and lifted them. But it was a pain until they did it. It took them a while to realize that we HAD to work the way we did in order to keep things running smoothly. I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend. At that time, call up the Sr. VP at 2 am in the morning and tell him that you have a crisis but you can not proceed until you get his permission because of the restrictions placed on you by the Auditors. Repeat this process as many times as neccessary for them to lift the restrictions. Kevin -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: [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: Kevin Lange 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). The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. I
RE: Griping about auditing (not the Oracle Kind)
This is the line I was commenting on... "I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend." I never once said that you should ignore the process put in place. What I said is that waiting until there is an issue is not doing your job. Fill in the paper work. If you are being proactive you have more then enough time to get that done before failure. Now if a manager fails to approve it despite your best attempts to get it approved that is another matter all together. But at least you have it documented that you knew it was an issue and that you attempted to fix it but your management would not let you. If, after all that, they try and tell you that you are not doing your job correctly then get the hell out. So I do not think I was either rude or presumptuous. Just failed to point out that I was really only commenting on that one line (which really stood out to me). -Original Message- Sent: Tuesday, June 26, 2001 1:15 AM To: Multiple recipients of list ORACLE-L Excuse me but you are a little presumptious and rude with that last mail. If a process is put in place that requires a form to be signed and authorisation to be given before action can be taken then I would be going totally against the grain and would get into trouble for not adhering to the company guidelines (as some of the UNIX S.A's did when they went in and made changes without filling out the necessary paperwork !!). On the contrary to your mail, I am a good DBA and I do take pride in my work and prior to the ridiculous rules that were put in place all work was done proactively and we never suffered because of it. What the managers (and "Quality Team", who had no bloody idea what their process would do to us) failed to realise was exactly how well I was doing my job, in that they were never bothered in the past. Once the mistakes were made and there was reactive form filling processes for certain things put in place, then things went back to normal. I think thats whats called a bite on my behalf!! -Original Message- Sent: 25 June 2001 18:16 To: Multiple recipients of list ORACLE-L I say that if you wait until you database has an error you really aren't proving much except that you are not proactive in your job. Which, in my book, makes you not a very good DBA. Dealing with a dumb process is one thing (we have our fair share on this account) but I take to much pride in my work to let things fail because I need to fill in a piece of paper. -Original Message- Sent: Monday, June 25, 2001 9:43 AM To: Multiple recipients of list ORACLE-L Wahey !!! The answer I was going to provide. We started calling the manager up quite frequently at home to authorise changes - he eventually saw sense. Not quite as bad as 2am in the morning but inconvenient enough for him to put a stop to it. Best of Luck. -Original Message- Sent: 25 June 2001 17:07 To: Multiple recipients of list ORACLE-L Jay; I have had to go thru the same thing a couple times on a previous job with Auditors. Every time those kind of restrictions were placed on us it brought things to a snails pace or, in some conditions, a complete halt. Sooner or later they realized that it was unreasonable and lifted them. But it was a pain until they did it. It took them a while to realize that we HAD to work the way we did in order to keep things running smoothly. I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend. At that time, call up the Sr. VP at 2 am in the morning and tell him that you have a crisis but you can not proceed until you get his permission because of the restrictions placed on you by the Auditors. Repeat this process as many times as neccessary for them to lift the restrictions. Kevin -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: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 53
RE: Griping about auditing (not the Oracle Kind)
When I worked for a large Oracle Office install for the state I was the technical ops mgr. (Largest distributed Oracle Office install in the US.) One of the rules we had in place is every one was given 3 meg of storage for email. If you needed more, you had to ask the Oracle Office Administrator, then the DBA also had to approve the increase before it could be done. This was politics at its best. One day one of the commissioners ran out of email space. It took two days to get his increase of storage, and I believe they took him to 10 meg. I thought this doesn't seem right for someone who is like the VP of this state agency. I calculated the disk space in relation to the 2 gig disk drive. Mind you, disks were so expensive back then. I also took into consideration the possible $25-50 per hour for two people to have to be involved to make this decision. It turned out the "VP" had waited two days to get about $3.45 worth of disk space and his salary was probably in the $55-75,000 range back when he was probably one of the highest paid officers in the agency... The payroll overhead for this $3.45 was probably in the $25-50 range. The lost time for the VP may have been $45-75... Once this was made "public" among OUR group, the policy was immediately revoked and if you wanted more space, you ask, you got it, period. When "politics" are involved, often you have to find a kind word and "make the business case". When I had to do the PO's for the state, I usually had about a 97% approval factor because I always made the business case. I included return on investment, cost, hidden costs, break even time, savings on maintenance, the works. Management thinks money(the 2.3 million budget), and anything that positively affects the bottom line gets their attention. Michael Kline ThinkSpark Richmond, VA 804-744-1545 > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Don > Granaman > Sent: Tuesday, June 26, 2001 1:20 AM > To: Multiple recipients of list ORACLE-L > Subject: Re: Griping about auditing (not the Oracle Kind) > > > 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.) (...) -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Michael Kline 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).
RE: Griping about auditing (not the Oracle Kind)
Title: RE: Griping about auditing (not the Oracle Kind) My point precisely. I'm not putting my neck on the line because someone won't allow me to do my job. Let them be the one who takes the hit when the s**t hits the fan. Thanks Chris, good point well made (better than my knee jerk reaction to Kimberleys mail anyways !! Cheers Lee -Original Message-From: Bowes, Chris [mailto:[EMAIL PROTECTED]]Sent: 25 June 2001 22:06To: Multiple recipients of list ORACLE-LSubject: RE: Griping about auditing (not the Oracle Kind) In a perfect world or even a sucky world, yes. But the nightmare scenerio that was laid out wouldn't allow proactivity on their part. The inconvenient time thing was due to the fact that the proactive items they wanted to to do were rejected. They had a table that was diagnosed with too small extents and they wanted a bigger extent size. They submitted paperwork and a non-tech management type said 'no'. Does he disobey the rules and risk getting fired? They made other requests for day-to-day events and possible problems. They were rejected because "you cannot do that many changes". Do they risk their jobs and do what is needed, knowing eventually someone *WILL* find out and at that point they can/will be terminated for insubordination and failure to follow process or at least slapped down big for it? In all situations I had seen until here, I would say, yes, proactivity is a must and I know that we can look at any one item and get around rules that get our way. When it becomes a corporate culture, you really need to get the policy eliminated. The way to do that is to allow the people who can make these stupid decisions suffer. He simply said "OK, if that's the way you want to play it, then I'll do what you say. I will follow your rules and not fix things I see wrong because *you say I can't*. Of course, you wouldn't know a database problem if it jumped up and bit you and said, 'Hi I am a database problem', but that's irrelevant. I will do it your way and fix it when it breaks and you're franticly signing off on the same paperwork you rejected x days/months ago. Just don't expect a friendly call at 2 am when it happens..." I agree, we need to be proactive, however, the way I read this issue, they were proactive and lots of times when they made suggestions, they were rejected and their proactivity was rendered moot by people who have no clue. When that happens, it is wise to make them feel some pain for the decisions they make. --Chris [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 4:01 PM To: Multiple recipients of list ORACLE-L Subject: RE: Griping about auditing (not the Oracle Kind) Kimberly, We're on the same wavelength, as I was thinking the same thing. Procrastinating on something that you know needs to be done is not an ethical way of dealing with this, IMO. Jared Kimberly Smith <[EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> jitsu.com> cc: Sent by: Subject: RE: Griping about auditing (not the Oracle Kind) [EMAIL PROTECTED] 06/25/01 10:15 AM Please respond to ORACLE-L I say that if you wait until you database has an error you really aren't proving much except that you are not proactive in your job. Which, in my book
RE: Griping about auditing (not the Oracle Kind)
Excuse me but you are a little presumptious and rude with that last mail. If a process is put in place that requires a form to be signed and authorisation to be given before action can be taken then I would be going totally against the grain and would get into trouble for not adhering to the company guidelines (as some of the UNIX S.A's did when they went in and made changes without filling out the necessary paperwork !!). On the contrary to your mail, I am a good DBA and I do take pride in my work and prior to the ridiculous rules that were put in place all work was done proactively and we never suffered because of it. What the managers (and "Quality Team", who had no bloody idea what their process would do to us) failed to realise was exactly how well I was doing my job, in that they were never bothered in the past. Once the mistakes were made and there was reactive form filling processes for certain things put in place, then things went back to normal. I think thats whats called a bite on my behalf!! -Original Message- Sent: 25 June 2001 18:16 To: Multiple recipients of list ORACLE-L I say that if you wait until you database has an error you really aren't proving much except that you are not proactive in your job. Which, in my book, makes you not a very good DBA. Dealing with a dumb process is one thing (we have our fair share on this account) but I take to much pride in my work to let things fail because I need to fill in a piece of paper. -Original Message- Sent: Monday, June 25, 2001 9:43 AM To: Multiple recipients of list ORACLE-L Wahey !!! The answer I was going to provide. We started calling the manager up quite frequently at home to authorise changes - he eventually saw sense. Not quite as bad as 2am in the morning but inconvenient enough for him to put a stop to it. Best of Luck. -Original Message- Sent: 25 June 2001 17:07 To: Multiple recipients of list ORACLE-L Jay; I have had to go thru the same thing a couple times on a previous job with Auditors. Every time those kind of restrictions were placed on us it brought things to a snails pace or, in some conditions, a complete halt. Sooner or later they realized that it was unreasonable and lifted them. But it was a pain until they did it. It took them a while to realize that we HAD to work the way we did in order to keep things running smoothly. I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend. At that time, call up the Sr. VP at 2 am in the morning and tell him that you have a crisis but you can not proceed until you get his permission because of the restrictions placed on you by the Auditors. Repeat this process as many times as neccessary for them to lift the restrictions. Kevin -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: [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: Kevin Lange 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 i
Re: Griping about auditing (not the Oracle Kind)
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" <[EMAIL PROTECTED]> 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 commi
RE: Griping about auditing (not the Oracle Kind)
In this I would always make sure that a hard copy and an email was sent for such a request and when the application is rejected ask him to reply thru mail. So you have documented proof that your suggestions were rejected in the first place. I only see one reason why the manager would like to do this. It is because he is one of those who says why the hell did this little pip squeak think of this before me.. So before anyone comes to know ( especially his boss ) he would rather present the request from his side and get a upper hand with his boss before he will approve. Ravinder = "Rachel Carmichael" To: Multiple recipients of list ORACLE-L mail.com>cc: Sent by: Subject: RE: Griping about auditing (not the root@fatcity.Oracle Kind) com 26-Jun-2001 09:50 AM Please respond to ORACLE-L Sender Info: No Sender Info found in the address Book in situations like that, you can and should document the fact that you made the proactice request and had it turned down. and then call that person's manager at 2AM to get permission to fix the problem when it becomes an emergency >From: "Bowes, Chris" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> >Subject: RE: Griping about auditing (not the Oracle Kind) >Date: Mon, 25 Jun 2001 13:05:46 -0800 > >In a perfect world or even a sucky world, yes. But the nightmare scenerio >that was laid out wouldn't allow proactivity on their part. The >inconvenient >time thing was due to the fact that the proactive items they wanted to to >do >were rejected. They had a table that was diagnosed with too small extents >and they wanted a bigger extent size. They submitted paperwork and a >non-tech management type said 'no'. Does he disobey the rules and risk >getting fired? They made other requests for day-to-day events and possible >problems. They were rejected because "you cannot do that many changes". >Do >they risk their jobs and do what is needed, knowing eventually someone >*WILL* find out and at that point they can/will be terminated for >insubordination and failure to follow process or at least slapped down big >for it? >In all situations I had seen until here, I would say, yes, proactivity is a >must and I know that we can look at any one item and get around rules that >get our way. When it becomes a corporate culture, you really need to get >the policy eliminated. The way to do that is to allow the people who can >make these stupid decisions suffer. He simply said "OK, if that's the way >you want to play it, then I'll do what you say. I will follow your rules >and not fix things I see wrong because *you say I can't*. Of course, you >wouldn't know a database problem if it jumped up and bit you and said, 'Hi >I >am a database problem', but that's irrelevant. I will do it your way and >fix it when it
RE: Griping about auditing (not the Oracle Kind)
in situations like that, you can and should document the fact that you made the proactice request and had it turned down. and then call that person's manager at 2AM to get permission to fix the problem when it becomes an emergency >From: "Bowes, Chris" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> >Subject: RE: Griping about auditing (not the Oracle Kind) >Date: Mon, 25 Jun 2001 13:05:46 -0800 > >In a perfect world or even a sucky world, yes. But the nightmare scenerio >that was laid out wouldn't allow proactivity on their part. The >inconvenient >time thing was due to the fact that the proactive items they wanted to to >do >were rejected. They had a table that was diagnosed with too small extents >and they wanted a bigger extent size. They submitted paperwork and a >non-tech management type said 'no'. Does he disobey the rules and risk >getting fired? They made other requests for day-to-day events and possible >problems. They were rejected because "you cannot do that many changes". >Do >they risk their jobs and do what is needed, knowing eventually someone >*WILL* find out and at that point they can/will be terminated for >insubordination and failure to follow process or at least slapped down big >for it? >In all situations I had seen until here, I would say, yes, proactivity is a >must and I know that we can look at any one item and get around rules that >get our way. When it becomes a corporate culture, you really need to get >the policy eliminated. The way to do that is to allow the people who can >make these stupid decisions suffer. He simply said "OK, if that's the way >you want to play it, then I'll do what you say. I will follow your rules >and not fix things I see wrong because *you say I can't*. Of course, you >wouldn't know a database problem if it jumped up and bit you and said, 'Hi >I >am a database problem', but that's irrelevant. I will do it your way and >fix it when it breaks and you're franticly signing off on the same >paperwork >you rejected x days/months ago. Just don't expect a friendly call at 2 am >when it happens..." > I agree, we need to be proactive, however, the way I read this issue, >they were proactive and lots of times when they made suggestions, they were >rejected and their proactivity was rendered moot by people who have no >clue. >When that happens, it is wise to make them feel some pain for the decisions >they make. > >--Chris >[EMAIL PROTECTED] > > >-Original Message- >Sent: Monday, June 25, 2001 4:01 PM >To: Multiple recipients of list ORACLE-L > > > > >Kimberly, > >We're on the same wavelength, as I was thinking the same thing. > >Procrastinating on something that you know needs to be done >is not an ethical way of dealing with this, IMO. > >Jared > > > > > > Kimberly Smith > > <[EMAIL PROTECTED]To: Multiple >recipients of list ORACLE-L <[EMAIL PROTECTED]> > jitsu.com>cc: > > Sent by: Subject: RE: Griping >about auditing (not the Oracle Kind) > [EMAIL PROTECTED] > > > > > > 06/25/01 10:15 AM > > Please respond to > > ORACLE-L > > > > > > > > > >I say that if you wait until you database has an error you really >aren't proving much except that you are not proactive in your job. >Which, in my book, makes you not a very good DBA. Dealing with a >dumb process is one thing (we have our fair share on this account) >but I take to much pride in my work to let things fail because I >need to fill in a piece of paper. > >-Original Message- >Sent: Monday, June 25, 2001 9:43 AM >To: Multiple recipients of list ORACLE-L > > >Wahey !!! The answer I was going to provide. We started calling the manager >up quite frequently at home to authorise changes - he eventually saw sense. >Not quite as bad as 2am in the morning but inconvenient enough for him to >put a stop to it. > >Best of Luck. > > >-Original Message- >Sent: 25 June 2001 17:07 >To: Multiple recipients of list ORACLE-L > > >Jay; > I have had to go thru the same thing a couple times on a previous job >with >Auditors. Every time those kind of restrictions were placed on us it >brought things to a snails pace or, in some conditions, a complete halt. >Sooner or later they realized that it
Re: Griping about auditing (not the Oracle Kind)
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 [EMAIL PROTECTED] 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 > > > [EMAIL PROTECTED] > LTo: 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
RE: Griping about auditing (not the Oracle Kind)
Title: RE: Griping about auditing (not the Oracle Kind)
Alex,
Touche` , I didn't think about the
managers CYA ability. Most don't get their jobs by being good, they
get there by knowing how to blame people and look good by
comparison... They were most definitely in a lose-lose
situation. I am glad for them that they got their point across
finally.
--Chris [EMAIL PROTECTED]
-Original Message-From: Hillman, Alex
[mailto:[EMAIL PROTECTED]]Sent: Monday, June 25, 2001
5:45 PMTo: Multiple recipients of list ORACLE-LSubject:
RE: Griping about auditing (not the Oracle Kind)
I
suggest CYA as much as possible and escalate the issue and begin search
for another job. Also if you are an FTE - now is a good time to go on
vacation or become sick. Because if something breaks damagement knows
much better how to avoid responsibility than we (at least most of us) are. For
example it can be said that you did not explained an issue well enough etc.
And you will show your e-mail to the damager of the damager who knows even
less about Oracle.
Alex
Hillman (incredibly rude and cinical)
-Original Message-From: Bowes, Chris
[mailto:[EMAIL PROTECTED]]Sent: Monday, June 25, 2001 5:06
PMTo: Multiple recipients of list ORACLE-LSubject: RE:
Griping about auditing (not the Oracle Kind)
In a perfect world or even a sucky world, yes. But the
nightmare scenerio that was laid out wouldn't allow proactivity on their
part. The inconvenient time thing was due to the fact that the proactive
items they wanted to to do were rejected. They had a table that was
diagnosed with too small extents and they wanted a bigger extent size.
They submitted paperwork and a non-tech management type said 'no'.
Does he disobey the rules and risk getting fired? They made other
requests for day-to-day events and possible problems. They were
rejected because "you cannot do that many changes". Do they risk their
jobs and do what is needed, knowing eventually someone *WILL* find out and
at that point they can/will be terminated for insubordination and failure to
follow process or at least slapped down big for it?
In all situations I had seen until here, I would say, yes,
proactivity is a must and I know that we can look at any one item and get
around rules that get our way. When it becomes a corporate culture,
you really need to get the policy eliminated. The way to do that is to
allow the people who can make these stupid decisions suffer. He simply
said "OK, if that's the way you want to play it, then I'll do what you
say. I will follow your rules and not fix things I see wrong because
*you say I can't*. Of course, you wouldn't know a database problem if
it jumped up and bit you and said, 'Hi I am a database problem', but that's
irrelevant. I will do it your way and fix it when it breaks and
you're franticly signing off on the same paperwork you rejected x
days/months ago. Just don't expect a friendly call at 2 am when
it happens..."
I agree, we need to be proactive,
however, the way I read this issue, they were proactive and lots of times
when they made suggestions, they were rejected and their proactivity was
rendered moot by people who have no clue. When that happens, it is
wise to make them feel some pain for the decisions they make.
--Chris [EMAIL PROTECTED]
RE: Griping about auditing (not the Oracle Kind)
Title: RE: Griping about auditing (not the Oracle Kind) The way I read it was that they aren't letting it fail because they want to make a point. They are letting it fail because they were told they could not fix it. Then when it did fail, they made sure it was real inconvenient for those who said "no you cannot fix it before it breaks". If it is the case that they were letting it fail to make a point, then yes, that is not acceptable. That is failing to do the job. However, if they watch it fail because they were *told to by the boss* (after pointing out the future failure in advance), then you have to do what the boss says. You just make sure s/he feels it when the decision goes bad. It is easy for me to say I would risk my job and not obey the bosses that tell me they can do my job better. Especially for a slap in the face like this. Hey, I'll just fill the paperwork and let you reject my suggestion and I'll do it anyway. You know it's easier to get forgiveness than permission. The base won't go down. The users will be happy. All will be well. Until the boss finds out that I am ignoring his authority. Especially when it is pointed out to him/her by someone else (possibly on a followup audit). Then I am in trouble. Big trouble. Then maybe being the rebel wasn't so good. I disobeyed the boss who was responding to auditors and that is the definition of insubordination. It doesn't matter that as a point of database operations and administration I was right. I disobeyed the pointy haired ones. Now I will pay. Auditors have a "terror" streak in their name. The mere mention of "the auditors" sets off those ominous tones in the minds of bosses. It sends them into panic since the very essence of their job (management) is being exposed for the whole world to see. Get a bad mark and they want that mark removed. Fast. Because of that, most bosses refuse to argue with the auditors findings and fight for what is correct. That's where stupid policies like having a data entry clerk verify that the DBA added a new file correctly. The same data entry clerk that couldn't log on when because the login screen changed colors and s/he got confused. Or having the same VP who opened the I*LOVE*YOU* virus (because he really thinks people out there love him) for the 16th time, approve or disapprove your database maintenence plans. In this case, I think my recommendation to Jay (I think he started this thread) would be to dust of the ol' resume and find a place where you're at least looked on with awe if not outright worshipped for your power and knowledge... --Chris [EMAIL PROTECTED] -Original Message- From: Rachel Carmichael [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 4:46 PM To: Multiple recipients of list ORACLE-L Subject: RE: Griping about auditing (not the Oracle Kind) I just always figure that if I am doing my job properly, they will be wondering why they pay me what they do (too little, but more than they think they should, considering "nothing ever goes wrong") deliberately letting something fail so as to point out a problem is definitely NOT the way to get things done. >From: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> >Subject: RE: Griping about auditing (not the Oracle Kind) >Date: Mon, 25 Jun 2001 12:00:58 -0800 > > > >Kimberly, > >We're on the same wavelength, as I was thinking the same thing. > >Procrastinating on something that you know needs to be done >is not an ethical way of dealing with this, IMO. > >Jared > > > > > Kimberly Smith > <[EMAIL PROTECTED] To: Multiple >recipients of list ORACLE-L <[EMAIL PROTECTED]> > jitsu.com> cc: > Sent by: Subject: RE: Griping >about auditing (not the Oracle Kind) > [EMAIL PROTECTED] > > > 06/25/01 10:15 AM > Please respond to > ORACLE-L > > > > > > >I say that if you wait until you database has an error you really >aren't proving much except that you are not proactive in your job. >Which, in my book, makes you not a very good DBA. Dealing with a >dumb process is one thing (we have our fair share on this account) >but I take to much pride in my work to let things fail because I >need to fill in a piece of paper. > >-Original Message- >Sent: Monday, June 25, 2001 9:43 AM >To: Multiple recipients of list ORACLE-L > > >Wahey !!! The answer I was going to provide. We started calling the manager >up quite frequently at home to authori
RE: Griping about auditing (not the Oracle Kind)
Title: RE: Griping about auditing (not the Oracle Kind) I suggest CYA as much as possible and escalate the issue and begin search for another job. Also if you are an FTE - now is a good time to go on vacation or become sick. Because if something breaks damagement knows much better how to avoid responsibility than we (at least most of us) are. For example it can be said that you did not explained an issue well enough etc. And you will show your e-mail to the damager of the damager who knows even less about Oracle. Alex Hillman (incredibly rude and cinical) -Original Message-From: Bowes, Chris [mailto:[EMAIL PROTECTED]]Sent: Monday, June 25, 2001 5:06 PMTo: Multiple recipients of list ORACLE-LSubject: RE: Griping about auditing (not the Oracle Kind) In a perfect world or even a sucky world, yes. But the nightmare scenerio that was laid out wouldn't allow proactivity on their part. The inconvenient time thing was due to the fact that the proactive items they wanted to to do were rejected. They had a table that was diagnosed with too small extents and they wanted a bigger extent size. They submitted paperwork and a non-tech management type said 'no'. Does he disobey the rules and risk getting fired? They made other requests for day-to-day events and possible problems. They were rejected because "you cannot do that many changes". Do they risk their jobs and do what is needed, knowing eventually someone *WILL* find out and at that point they can/will be terminated for insubordination and failure to follow process or at least slapped down big for it? In all situations I had seen until here, I would say, yes, proactivity is a must and I know that we can look at any one item and get around rules that get our way. When it becomes a corporate culture, you really need to get the policy eliminated. The way to do that is to allow the people who can make these stupid decisions suffer. He simply said "OK, if that's the way you want to play it, then I'll do what you say. I will follow your rules and not fix things I see wrong because *you say I can't*. Of course, you wouldn't know a database problem if it jumped up and bit you and said, 'Hi I am a database problem', but that's irrelevant. I will do it your way and fix it when it breaks and you're franticly signing off on the same paperwork you rejected x days/months ago. Just don't expect a friendly call at 2 am when it happens..." I agree, we need to be proactive, however, the way I read this issue, they were proactive and lots of times when they made suggestions, they were rejected and their proactivity was rendered moot by people who have no clue. When that happens, it is wise to make them feel some pain for the decisions they make. --Chris [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 4:01 PM To: Multiple recipients of list ORACLE-L Subject: RE: Griping about auditing (not the Oracle Kind) Kimberly, We're on the same wavelength, as I was thinking the same thing. Procrastinating on something that you know needs to be done is not an ethical way of dealing with this, IMO. Jared Kimberly Smith <[EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> jitsu.com> cc: Sent by: Subject: RE: Griping about auditing (not the Oracle Kind) [EMAIL PROTECTED] 06/25/01 10:15 AM Please respond to ORACLE-L
RE: Griping about auditing (not the Oracle Kind)
Title: RE: Griping about auditing (not the Oracle Kind) In a perfect world or even a sucky world, yes. But the nightmare scenerio that was laid out wouldn't allow proactivity on their part. The inconvenient time thing was due to the fact that the proactive items they wanted to to do were rejected. They had a table that was diagnosed with too small extents and they wanted a bigger extent size. They submitted paperwork and a non-tech management type said 'no'. Does he disobey the rules and risk getting fired? They made other requests for day-to-day events and possible problems. They were rejected because "you cannot do that many changes". Do they risk their jobs and do what is needed, knowing eventually someone *WILL* find out and at that point they can/will be terminated for insubordination and failure to follow process or at least slapped down big for it? In all situations I had seen until here, I would say, yes, proactivity is a must and I know that we can look at any one item and get around rules that get our way. When it becomes a corporate culture, you really need to get the policy eliminated. The way to do that is to allow the people who can make these stupid decisions suffer. He simply said "OK, if that's the way you want to play it, then I'll do what you say. I will follow your rules and not fix things I see wrong because *you say I can't*. Of course, you wouldn't know a database problem if it jumped up and bit you and said, 'Hi I am a database problem', but that's irrelevant. I will do it your way and fix it when it breaks and you're franticly signing off on the same paperwork you rejected x days/months ago. Just don't expect a friendly call at 2 am when it happens..." I agree, we need to be proactive, however, the way I read this issue, they were proactive and lots of times when they made suggestions, they were rejected and their proactivity was rendered moot by people who have no clue. When that happens, it is wise to make them feel some pain for the decisions they make. --Chris [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 4:01 PM To: Multiple recipients of list ORACLE-L Subject: RE: Griping about auditing (not the Oracle Kind) Kimberly, We're on the same wavelength, as I was thinking the same thing. Procrastinating on something that you know needs to be done is not an ethical way of dealing with this, IMO. Jared Kimberly Smith <[EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> jitsu.com> cc: Sent by: Subject: RE: Griping about auditing (not the Oracle Kind) [EMAIL PROTECTED] 06/25/01 10:15 AM Please respond to ORACLE-L I say that if you wait until you database has an error you really aren't proving much except that you are not proactive in your job. Which, in my book, makes you not a very good DBA. Dealing with a dumb process is one thing (we have our fair share on this account) but I take to much pride in my work to let things fail because I need to fill in a piece of paper. -Original Message- Sent: Monday, June 25, 2001 9:43 AM To: Multiple recipients of list ORACLE-L Wahey !!! The answer I was going to provide. We started calling the manager up quite frequently at home to authorise changes - he eventually saw sense. Not quite as bad as 2am in the morning but inconvenient enough for him to put a stop to it. Best of Luck. -Original Message- Sent: 25 June 2001 17:07 To: Multiple recipients of list ORACLE-L Jay;
RE: Griping about auditing (not the Oracle Kind)
I just always figure that if I am doing my job properly, they will be wondering why they pay me what they do (too little, but more than they think they should, considering "nothing ever goes wrong") deliberately letting something fail so as to point out a problem is definitely NOT the way to get things done. >From: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] >To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> >Subject: RE: Griping about auditing (not the Oracle Kind) >Date: Mon, 25 Jun 2001 12:00:58 -0800 > > > >Kimberly, > >We're on the same wavelength, as I was thinking the same thing. > >Procrastinating on something that you know needs to be done >is not an ethical way of dealing with this, IMO. > >Jared > > > > > Kimberly Smith > <[EMAIL PROTECTED]To: Multiple >recipients of list ORACLE-L <[EMAIL PROTECTED]> > jitsu.com> cc: > Sent by: Subject: RE: Griping >about auditing (not the Oracle Kind) > [EMAIL PROTECTED] > > > 06/25/01 10:15 AM > Please respond to > ORACLE-L > > > > > > >I say that if you wait until you database has an error you really >aren't proving much except that you are not proactive in your job. >Which, in my book, makes you not a very good DBA. Dealing with a >dumb process is one thing (we have our fair share on this account) >but I take to much pride in my work to let things fail because I >need to fill in a piece of paper. > >-Original Message- >Sent: Monday, June 25, 2001 9:43 AM >To: Multiple recipients of list ORACLE-L > > >Wahey !!! The answer I was going to provide. We started calling the manager >up quite frequently at home to authorise changes - he eventually saw sense. >Not quite as bad as 2am in the morning but inconvenient enough for him to >put a stop to it. > >Best of Luck. > > >-Original Message- >Sent: 25 June 2001 17:07 >To: Multiple recipients of list ORACLE-L > > >Jay; > I have had to go thru the same thing a couple times on a previous job >with >Auditors. Every time those kind of restrictions were placed on us it >brought things to a snails pace or, in some conditions, a complete halt. >Sooner or later they realized that it was unreasonable and lifted them. >But >it was a pain until they did it. > >It took them a while to realize that we HAD to work the way we did in order >to keep things running smoothly. > >I personally think that you should wait with resizing any of your >production >data files until you get oracle errors saying that things can not extend. >At that time, call up the Sr. VP at 2 am in the morning and tell him that >you have a crisis but you can not proceed until you get his permission >because of the restrictions placed on you by the Auditors. Repeat this >process as many times as neccessary for them to lift the restrictions. > >Kevin > >-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: [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 info
RE: Griping about auditing (not the Oracle Kind)
Kimberly, We're on the same wavelength, as I was thinking the same thing. Procrastinating on something that you know needs to be done is not an ethical way of dealing with this, IMO. Jared Kimberly Smith <[EMAIL PROTECTED]To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> jitsu.com>cc: Sent by: Subject: RE: Griping about auditing (not the Oracle Kind) [EMAIL PROTECTED] 06/25/01 10:15 AM Please respond to ORACLE-L I say that if you wait until you database has an error you really aren't proving much except that you are not proactive in your job. Which, in my book, makes you not a very good DBA. Dealing with a dumb process is one thing (we have our fair share on this account) but I take to much pride in my work to let things fail because I need to fill in a piece of paper. -Original Message- Sent: Monday, June 25, 2001 9:43 AM To: Multiple recipients of list ORACLE-L Wahey !!! The answer I was going to provide. We started calling the manager up quite frequently at home to authorise changes - he eventually saw sense. Not quite as bad as 2am in the morning but inconvenient enough for him to put a stop to it. Best of Luck. -Original Message- Sent: 25 June 2001 17:07 To: Multiple recipients of list ORACLE-L Jay; I have had to go thru the same thing a couple times on a previous job with Auditors. Every time those kind of restrictions were placed on us it brought things to a snails pace or, in some conditions, a complete halt. Sooner or later they realized that it was unreasonable and lifted them. But it was a pain until they did it. It took them a while to realize that we HAD to work the way we did in order to keep things running smoothly. I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend. At that time, call up the Sr. VP at 2 am in the morning and tell him that you have a crisis but you can not proceed until you get his permission because of the restrictions placed on you by the Auditors. Repeat this process as many times as neccessary for them to lift the restrictions. Kevin -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: [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
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
[EMAIL PROTECTED]
LTo: 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
RE: Griping about auditing (not the Oracle Kind)
Sorry but there are better ways. -Original Message- Sent: Monday, June 25, 2001 11:00 AM To: Multiple recipients of list ORACLE-L Well Kimberly, sometimes you have to do what you have to do to get a point accross. Depending on the type of employer you have, sometimes you have to take drastic measures that you would not normally take. -Original Message- Sent: Monday, June 25, 2001 12:16 PM To: Multiple recipients of list ORACLE-L I say that if you wait until you database has an error you really aren't proving much except that you are not proactive in your job. Which, in my book, makes you not a very good DBA. Dealing with a dumb process is one thing (we have our fair share on this account) but I take to much pride in my work to let things fail because I need to fill in a piece of paper. -Original Message- Sent: Monday, June 25, 2001 9:43 AM To: Multiple recipients of list ORACLE-L Wahey !!! The answer I was going to provide. We started calling the manager up quite frequently at home to authorise changes - he eventually saw sense. Not quite as bad as 2am in the morning but inconvenient enough for him to put a stop to it. Best of Luck. -Original Message- Sent: 25 June 2001 17:07 To: Multiple recipients of list ORACLE-L Jay; I have had to go thru the same thing a couple times on a previous job with Auditors. Every time those kind of restrictions were placed on us it brought things to a snails pace or, in some conditions, a complete halt. Sooner or later they realized that it was unreasonable and lifted them. But it was a pain until they did it. It took them a while to realize that we HAD to work the way we did in order to keep things running smoothly. I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend. At that time, call up the Sr. VP at 2 am in the morning and tell him that you have a crisis but you can not proceed until you get his permission because of the restrictions placed on you by the Auditors. Repeat this process as many times as neccessary for them to lift the restrictions. Kevin -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: [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: Kevin Lange 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). The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Robertson Lee - lerobe INET: [EMAI
RE: Griping about auditing (not the Oracle Kind)
Well Kimberly, sometimes you have to do what you have to do to get a point accross. Depending on the type of employer you have, sometimes you have to take drastic measures that you would not normally take. -Original Message- Sent: Monday, June 25, 2001 12:16 PM To: Multiple recipients of list ORACLE-L I say that if you wait until you database has an error you really aren't proving much except that you are not proactive in your job. Which, in my book, makes you not a very good DBA. Dealing with a dumb process is one thing (we have our fair share on this account) but I take to much pride in my work to let things fail because I need to fill in a piece of paper. -Original Message- Sent: Monday, June 25, 2001 9:43 AM To: Multiple recipients of list ORACLE-L Wahey !!! The answer I was going to provide. We started calling the manager up quite frequently at home to authorise changes - he eventually saw sense. Not quite as bad as 2am in the morning but inconvenient enough for him to put a stop to it. Best of Luck. -Original Message- Sent: 25 June 2001 17:07 To: Multiple recipients of list ORACLE-L Jay; I have had to go thru the same thing a couple times on a previous job with Auditors. Every time those kind of restrictions were placed on us it brought things to a snails pace or, in some conditions, a complete halt. Sooner or later they realized that it was unreasonable and lifted them. But it was a pain until they did it. It took them a while to realize that we HAD to work the way we did in order to keep things running smoothly. I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend. At that time, call up the Sr. VP at 2 am in the morning and tell him that you have a crisis but you can not proceed until you get his permission because of the restrictions placed on you by the Auditors. Repeat this process as many times as neccessary for them to lift the restrictions. Kevin -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: [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: Kevin Lange 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). The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Robertson Lee - lerobe INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mail
RE: Griping about auditing (not the Oracle Kind)
I say that if you wait until you database has an error you really aren't proving much except that you are not proactive in your job. Which, in my book, makes you not a very good DBA. Dealing with a dumb process is one thing (we have our fair share on this account) but I take to much pride in my work to let things fail because I need to fill in a piece of paper. -Original Message- Sent: Monday, June 25, 2001 9:43 AM To: Multiple recipients of list ORACLE-L Wahey !!! The answer I was going to provide. We started calling the manager up quite frequently at home to authorise changes - he eventually saw sense. Not quite as bad as 2am in the morning but inconvenient enough for him to put a stop to it. Best of Luck. -Original Message- Sent: 25 June 2001 17:07 To: Multiple recipients of list ORACLE-L Jay; I have had to go thru the same thing a couple times on a previous job with Auditors. Every time those kind of restrictions were placed on us it brought things to a snails pace or, in some conditions, a complete halt. Sooner or later they realized that it was unreasonable and lifted them. But it was a pain until they did it. It took them a while to realize that we HAD to work the way we did in order to keep things running smoothly. I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend. At that time, call up the Sr. VP at 2 am in the morning and tell him that you have a crisis but you can not proceed until you get his permission because of the restrictions placed on you by the Auditors. Repeat this process as many times as neccessary for them to lift the restrictions. Kevin -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: [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: Kevin Lange 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). The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Robertson Lee - lerobe 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 r
RE: Griping about auditing (not the Oracle Kind)
Jay, 'you can't put that many changes through' I love it! see, how it works! follow the dumb process they establish, and it gets even dumber!eventually, it breaks and they see the folly of the process. it reminds me of almost every "M*A*S*H" episode I ever saw. "Want me to arrest him too, since I'm already here, no charge." Tom Mercadante Oracle Certified Professional -Original Message- Sent: Monday, June 25, 2001 12:12 PM To: Multiple recipients of list ORACLE-L Close, it's a brokerage. But regarding flooding the SVP, one of my favorite Dilbert moments came about a month after the new procedures were in place. They were getting forms from multiple sources (me, the developers on our OLTP database and the developers from our datawarehouse). All those were being funneled through me to my SVP to be put into the database. The business side was able to provide the specs and requests, the developers wrote the code, I did a basic review of it and verified it compiled on our QC database and put it in production (despite DBA staff being down 50% due to a hiring freeze). The Change Request department wasn't able to keep up. Their solution was to say 'you can't put that many changes through'. We talked them out of it but... Jay Miller Sr. Oracle DBA -Original Message- Sent: Monday, June 25, 2001 11:32 AM To: Multiple recipients of list ORACLE-L Jay, You did not say what type of an employer you are currently at, so it is tough to comment. I have seen *very* strict controls put into place at various places of employment. It sounds like you are at a gov't facility where audit and control is serious business. You have three choices: 1). try and work thru the system to show why this is a bad idea - like let the system go to hell and explain that you would have fixed it, but have been waiting for a signature from the VP. 2). flood the VP with so many requests that he/she sees how ridiculous the requirement is. 3). if all else fails, start looking for another job. at exit interview time, explain that the audit process is NOT conducive to business standards. hope this helps Tom Mercadante Oracle Certified Professional -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: [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: Smith, Ron L. 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: Mercadante, Thomas F INET: [EMAIL PROTECTED] Fat City Network Services-
RE: Griping about auditing (not the Oracle Kind)
Wahey !!! The answer I was going to provide. We started calling the manager up quite frequently at home to authorise changes - he eventually saw sense. Not quite as bad as 2am in the morning but inconvenient enough for him to put a stop to it. Best of Luck. -Original Message- Sent: 25 June 2001 17:07 To: Multiple recipients of list ORACLE-L Jay; I have had to go thru the same thing a couple times on a previous job with Auditors. Every time those kind of restrictions were placed on us it brought things to a snails pace or, in some conditions, a complete halt. Sooner or later they realized that it was unreasonable and lifted them. But it was a pain until they did it. It took them a while to realize that we HAD to work the way we did in order to keep things running smoothly. I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend. At that time, call up the Sr. VP at 2 am in the morning and tell him that you have a crisis but you can not proceed until you get his permission because of the restrictions placed on you by the Auditors. Repeat this process as many times as neccessary for them to lift the restrictions. Kevin -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: [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: Kevin Lange 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). The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Robertson Lee - lerobe 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).
RE: Griping about auditing (not the Oracle Kind)
Alex, that was the result of an "inexperienced" DBA. an experienced DBA would know that there is a load placed on the server during datafile addition time. if you have a server with extra "oomf", then the users should not see any difference. it sounds like you had a very sensitive database that the DBA should have known to schedule the file addition with management. don't get me wrong, the real issue with your example and with Jay's is education. management (or was it damagement?) needs to be educated about what DBA's do, how to establish proper procedures for database tuning and changes, what is "change management" and what kind of (DBA) freedom is appropriate for the organization. generally, we should be considered System Administrators, and such, we can have a very large impact (good and bad) on the system. Tom Mercadante Oracle Certified Professional -Original Message- Sent: Monday, June 25, 2001 12:12 PM To: Multiple recipients of list ORACLE-L I agree with you, however in one of my previous contracts one guy decided to add datafile to the database. He aadded a 2G file and database for several minutes did only one thing - created datafile. Application servers were shut down because they checked DB every 5 sec or something like that. There was a big fass because even several minutes of downtime were not acceptable for this app. This guys even considered to sue Oracle (this guy was Oracle consultant). Alex Hillman -Original Message- Sent: Monday, June 25, 2001 11:32 AM To: Multiple recipients of list ORACLE-L Jay, You did not say what type of an employer you are currently at, so it is tough to comment. I have seen *very* strict controls put into place at various places of employment. It sounds like you are at a gov't facility where audit and control is serious business. You have three choices: 1). try and work thru the system to show why this is a bad idea - like let the system go to hell and explain that you would have fixed it, but have been waiting for a signature from the VP. 2). flood the VP with so many requests that he/she sees how ridiculous the requirement is. 3). if all else fails, start looking for another job. at exit interview time, explain that the audit process is NOT conducive to business standards. hope this helps Tom Mercadante Oracle Certified Professional -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: [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: Smith, Ron L. 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 (l
RE: Griping about auditing (not the Oracle Kind)
Jay; I have had to go thru the same thing a couple times on a previous job with Auditors. Every time those kind of restrictions were placed on us it brought things to a snails pace or, in some conditions, a complete halt. Sooner or later they realized that it was unreasonable and lifted them. But it was a pain until they did it. It took them a while to realize that we HAD to work the way we did in order to keep things running smoothly. I personally think that you should wait with resizing any of your production data files until you get oracle errors saying that things can not extend. At that time, call up the Sr. VP at 2 am in the morning and tell him that you have a crisis but you can not proceed until you get his permission because of the restrictions placed on you by the Auditors. Repeat this process as many times as neccessary for them to lift the restrictions. Kevin -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: [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: Kevin Lange 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).
RE: Griping about auditing (not the Oracle Kind)
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: [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: Smith, Ron L. 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: 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).
RE: Griping about auditing (not the Oracle Kind)
A non-DBA? Is that because we stick together like the Mafia or something?! g -Original Message- Sent: Monday, June 25, 2001 3:32 PM 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: [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: Guy Hammond 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).
RE: Griping about auditing (not the Oracle Kind)
Close, it's a brokerage. But regarding flooding the SVP, one of my favorite Dilbert moments came about a month after the new procedures were in place. They were getting forms from multiple sources (me, the developers on our OLTP database and the developers from our datawarehouse). All those were being funneled through me to my SVP to be put into the database. The business side was able to provide the specs and requests, the developers wrote the code, I did a basic review of it and verified it compiled on our QC database and put it in production (despite DBA staff being down 50% due to a hiring freeze). The Change Request department wasn't able to keep up. Their solution was to say 'you can't put that many changes through'. We talked them out of it but... Jay Miller Sr. Oracle DBA -Original Message- Sent: Monday, June 25, 2001 11:32 AM To: Multiple recipients of list ORACLE-L Jay, You did not say what type of an employer you are currently at, so it is tough to comment. I have seen *very* strict controls put into place at various places of employment. It sounds like you are at a gov't facility where audit and control is serious business. You have three choices: 1). try and work thru the system to show why this is a bad idea - like let the system go to hell and explain that you would have fixed it, but have been waiting for a signature from the VP. 2). flood the VP with so many requests that he/she sees how ridiculous the requirement is. 3). if all else fails, start looking for another job. at exit interview time, explain that the audit process is NOT conducive to business standards. hope this helps Tom Mercadante Oracle Certified Professional -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: [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: Smith, Ron L. 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: Mercadante, Thomas F 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 (lik
Re: Griping about auditing (not the Oracle Kind)
They afraid you'll add items you're not license for when installing software, and i'm still trying to figure out why if you resize something a SVP needs to know, talk about micro-managing. joe >>> [EMAIL PROTECTED] 06/25/01 10:31AM >>>We've been through an internal audit and I was just wondering if anyone elsehas to deal with the rather ludicrous requirements I now have. In order toadd or resize a datafile I now need to fill out a form and get Senior VPapproval and the alert logs must be reviewed every day by a non-DBA in orderto 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 thingswhenever I thought them necessary but that we didn't have a non-DBA revieweverything I did after an Oracle upgrade to ensure I didn't install anyother software.Fortunately I managed to convince them that yes, I really did need a Unixlogin (they were skeptical).So, any similar horror stories?Jay MillerSr. 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-5051San Diego, California -- Public Internet access / Mailing ListsTo REMOVE yourself from this mailing list, send an E-Mail messageto: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and inthe message BODY, include a line containing: UNSUB ORACLE-L(or the name of mailing list you want to be removed from). You mayalso send the HELP command for other information (like subscribing).
RE: Griping about auditing (not the Oracle Kind)
I agree with you, however in one of my previous contracts one guy decided to add datafile to the database. He aadded a 2G file and database for several minutes did only one thing - created datafile. Application servers were shut down because they checked DB every 5 sec or something like that. There was a big fass because even several minutes of downtime were not acceptable for this app. This guys even considered to sue Oracle (this guy was Oracle consultant). Alex Hillman -Original Message- Sent: Monday, June 25, 2001 11:32 AM To: Multiple recipients of list ORACLE-L Jay, You did not say what type of an employer you are currently at, so it is tough to comment. I have seen *very* strict controls put into place at various places of employment. It sounds like you are at a gov't facility where audit and control is serious business. You have three choices: 1). try and work thru the system to show why this is a bad idea - like let the system go to hell and explain that you would have fixed it, but have been waiting for a signature from the VP. 2). flood the VP with so many requests that he/she sees how ridiculous the requirement is. 3). if all else fails, start looking for another job. at exit interview time, explain that the audit process is NOT conducive to business standards. hope this helps Tom Mercadante Oracle Certified Professional -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: [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: Smith, Ron L. 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: Mercadante, Thomas F 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: Hillman, Alex INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists --
Re: Griping about auditing (not the Oracle Kind)
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" 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
RE: Griping about auditing (not the Oracle Kind)
Jay, You did not say what type of an employer you are currently at, so it is tough to comment. I have seen *very* strict controls put into place at various places of employment. It sounds like you are at a gov't facility where audit and control is serious business. You have three choices: 1). try and work thru the system to show why this is a bad idea - like let the system go to hell and explain that you would have fixed it, but have been waiting for a signature from the VP. 2). flood the VP with so many requests that he/she sees how ridiculous the requirement is. 3). if all else fails, start looking for another job. at exit interview time, explain that the audit process is NOT conducive to business standards. hope this helps Tom Mercadante Oracle Certified Professional -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: [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: Smith, Ron L. 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: Mercadante, Thomas F 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).
RE: Griping about auditing (not the Oracle Kind)
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: [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: Smith, Ron L. 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).
