Re: ad-hoc update check

I agree with Rachel.

I worked in one environment that had these sorts of "zaps" (as they called them) happening so often that the DBAs built a "zaptool". The "zaptool" was implemented in X-windows and took a SQL statement as input. It recorded everything possible about the SQL statement: who used it, when, where, duration, etc. The "zaptool" was available only to DBAs who were part of the 24x7 "on-call" rotation, and usually one was referred directly to the DBA currently "on-call". Those DBAs, knowing that they were being held accountable for its use (and that bending the rules might result in a sleepless night), demanded written sign-off from a director-level manager before the tool could be used, certifying that the "zap" was necessary and that it was "safe". That's all. They just said "No. Not without a director-level signature -- any director-level signature" and their manager backed them up. And as it turned out, this chain of accountability was all that was needed...

It didn't take long for all of the other good things to fall into place: a realistic test environment, some real concern by upper-management over "safety" and accuracy, working harder on app design to prevent "zaps", etc.

Most immediately, it brought home to the director who took full responsibility the full range of things that could go wrong, and made them place their own career and reputation into the hands of a 20-something who was hired only last month. It provided the flexibility for a director to take a chance in the event that a real crisis was brewing, but that same type of reckless behavior also spawned a culture among the other directors of trying to prevent the crisis, instead of letting the crisis ride you into the abyss...

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Wednesday, May 29, 2002 7:08 AM

> One thing to add to that:
>
> they must supply some sort of change request doc with MANAGEMENT/USER
> sign-off on it before you run the changes.
>
> just supplying a piece of paper doesn't do it for me. I've had
> developers (yes, developers not duhvelopers) who still say "oh I tested
> it" but I want something that proves someone other than the developer
> looked at the results.
>
> If this is going to be an ongoing process, create change control forms
> for it.
>
> Rachel
>
> --- Jared Still <jkstill_at_cybcon.com> wrote:
> >
> > Dennis,
> >
> > If management is Ok with this ( have you asked? ) you need to
> > take some steps to protect your database, your job and your
> > reputation.
> >
> > 'cuz the duhvelopers will do their best to destroy all three.
> >
> > 1. You need a test database with a reasonable amount of test data
> >
> > 2. Your duhvelopers need to develop their data massage routines
> > against the test database.
> >
> > 3. When they think they have it right, run the query on the QA
> > database.
> > If resource/time constraints demand it, this might be your test
> > database.
> >
> > 4. They need to check their results. This means that an actual user
> > that is very familiar with the application will use the
> > application
> > against the QA database, and sign off on the results.
> >
> > 5. Don't give them an account on the production database. They must
> > supply you the DBA with script that you will run. They must
> > supply
> > documentation with the script. If the docs are imcomplete, don't
> > run
> > the script until the docs are complete.
> >
> > Anyway, this is what makes me happy. :)
> >
> > Jared
> >
> >
> > On Tuesday 28 May 2002 15:25, dmeng_at_focal.com wrote:
> > > Hi folks -
> > > I have received a stream of requests from developers/production
> > support (
> > > yep, same group, dont ask ) to do ad-hoc data massaging in the
> > production
> > > databases. Since I don't know the applications that well, it's hard
> > for me
> > > to push back these requests when told that if the script don't get
> > run
> > > today, marketing department won't be able to use the system etc. I
> > wonder
> > > if other people on the list have the same problem and I am thinking
> > about
> > > coming up with a document for the developers to fill out making
> > sure the
> > > request won't hose up the database. I wonder how other shops deal
> > with
> > > issues like these and can you let me know what you can do to check
> > for
> > > potential issues with a sql script.
> > >
> > > TIA
> > >
> > > Dennis Meng
> > > Database Administrator
> > > Focal Communications Corp.
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Jared Still
> > INET: jkstill_at_cybcon.com
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing
> > Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like subscribing).
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Rachel Carmichael
> INET: wisernet100_at_yahoo.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Tim Gorman
  INET: Tim_at_SageLogix.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).