Re:RE: WILL YOU GIVE PROGRAMMERS DBA ACCOUNT IF WE SAID YES?

From: Jack van Zanen <nlzanen1_at_ey.nl>
Date: Thu, 3 Aug 2000 09:10:22 +0100
Message-Id: <10578.113689@fatcity.com>

Horror story here:

Our developers team and management had decided that juli 1 the project must go live, however there was much work to do before go-live, hence my requests for "accurate" predictions on table size and activity where brushed away due to lack of time. They had decided in their infinite wisdom that we would have to set extents to unlimited monitor the space usage of the tablespaces (add space when neccesary) and after a certain time of production predict the yearly growth and reorganise. Besides that I had to inform them that indexes should be seperate from their tables and that temporary tables should not be created in temporary tablespace (And this is a serious company I was told)

I'm now faced with this daunting task of wasting a good weekend one day to do all this and all the while have management breathing down my neck to hurry it up (it's a live production system now).

Think twice before signing over control (or in my case be pushed over by higher authority because I was just the junior DBA "senior has left the building"), I know I will kick and scream and put up more of a fight next time they try this.

Jack

"Rachel Carmichael" <carmichr_at_hotmail.com>@fatcity.com on 08/03/2000 01:04:13 AM

Please respond to ORACLE-L_at_fatcity.com

Sent by: root_at_fatcity.com

To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> cc:
Subject: Re:RE: WILL YOU GIVE PROGRAMMERS DBA ACCOUNT IF WE SAID YES?

Please plan to be overworked, stressed and at fault for everything.

You are letting the programmers create things and then saying you will manage them.. not a good thing.

Objects will be created wherever, i/o contention will not be thought of, initial and next extents will not be sized properly....

this is a disaster waiting to happen.

Yes, some (many) developers understand what they are doing with Oracle and how to plan object placement... most don't

>From: Cyril Thankappan <cyril_thank_at_india.com>
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: Re:RE: WILL YOU GIVE PROGRAMMERS DBA ACCOUNT IF WE SAID YES?
>Date: Wed, 02 Aug 2000 12:36:09 -0800
>
>Hi!
>
>Sorry if I am adding too many 'opinions'!
>
>At our site, DBAs used to create database objects
>because tablespace creation was DBA's responsibilty
>and tablespace was created by DBA because backup
>was DBA's responsibility and backup was done by
>DBAs because restoration and recovery was DBAs
>responsibility.....
>
>
>But I am planning to put everything on its head....
>by allowing object creation and tablespace
>creation to be done by programmers with
>information being passed to DBAs
>so DBA can accordingly plan/arrange for backup.
>
>Can someone (experienced person!) pls suggest
>as to what are the likely problems to be faced
>in such a set up?
>
>Kindly note this will be the suggested sequence
>
>a. the tablespace creation
>will be given as request to DBA
>
>b. After the tablespace is created by DBA
>he will include it in his backup scripts.
>
>c. after the steps a and b the programmer
>can go on merrily creating the objects
>in which ever tablespace he chooses..
>and the DBAs' expertise lies in continously
>monitoring to anticipate problems and take
>corretive action
>
>Howzzat?
>
>
>Thanks
>
>PS: On 2nd thoughts should I patent the above idea!!!!!!
>But more seriously... some of the advice and help
>I have received here is very precious to me..
>
>
>
>
>------Original Message------
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Sent: July 31, 2000 3:16:27 PM GMT
>
>
>To ALL,
>
>Now that I've returned from a restful vacation. Cultivating/mentoring good
>developers is an art that I cannot claim to have mastered, but one that is
>imperative to a stable and productive environment. Having good and
>responsive
>developers is true heaven on earth. Regrettably I have a number of good
>and
>responsive tenants and some real dirt bags as well. The answer here is to
>monitor your DB on some regular basis, put as much self correction in place
>as
>possible, be proactive, and learn what you can about the apps. Namely be a
>good
>DBA and a fair developer at the same time. OH, BTW: one easy way to not
>have
>space problems is to get reasonable space estimates up front and then add
>about
>50% to that. It's hard, but essential. And to the original question, NO
>WAY, NO
>HOW.
>
>Dick Goulet
>Senior Oracle DBA
>Vicor Corporation
>____________________Reply Separator____________________
>Author: Kimberly.smith_at_gmd.fujitsu.com
>Date: 7/27/00 8:22 AM
>
>Actually at our site the developers are the first line of contact as
>well. They rarely have to call me. I used to be on a site that no
>matter what went wrong they always blamed the database. Sometimes
>they would not even be accessing the database and they would still
>blame it. That is the difference between working with well trained
>and experienced developers as opposed to those who are not so well
>trained. By the time I left the other site I had some of them actually
>checking their code first. Its a hard battle but one I think is
>worth going though at least once in your career so that you can
>appreciate this environment so much more. But I still don't give
>developers DBA...
>
>-----Original Message-----
>Elkins
>Sent: Wednesday, July 26, 2000 6:24 PM
>To: Multiple recipients of list ORACLE-L
>
>
>Larry,
>
>And some landlords let their properties deteriorate so badly that they are
>uninhabitable ;-) Sorry, I couldn't resist since the analogy presented such
>a sitting duck target. I am *not* taking potshots at DBA's (FWIW, I used to
>be one), though I have run into a *couple* that might be called
>"slumlords",
>just as we have all run into some/many/all developers who are horrible
>"tenants".
>
>With regards to your comment on getting calls in the middle of the night,
>I've been involved with a handful of sites where the lead *developer*
>responsible for an application is the first contact. The thinking there was
>that if an error occurred, it was probably due to an application issue and
>the lead developer was better equipped at trouble-shooting the problem (the
>DBA's were typically overworked and had no time to learn about the
>individual apps). There was one site, though, were 99.9% of the failures
>were due to insufficient space issues (the DBA was *very* stingy about
>allocating space). The only problem was that he never monitored or trended
>space usage to know when to allocate more (and I kid you not, his response
>was "Why should I monitor space usage since we will find out when something
>fails. We will take care of it then". His manager backed him on this.
>Uggh!). After I received numerous 3:00 AM calls over a few months, all due
>to insufficient space, the *DBA* became the first contact for any problems.
>After a while, space problems never cropped up. Imagine that ;-).
>
>I have had the good fortune to work with a number of great DBA's over the
>years. I am working with some right now. It's a good thing when the
>barriers
>are broken down and the development, DBA, and systems staff all work as a
>team. And the DBA staff does not have to give in to outrageous requests for
>the groups to get along and work well together. The ones I'm working with
>right now are pretty tough and tight; but, they are also very responsive
>and
>helpful. Everyone's roles are very well defined, everyone understands, and
>no one complains. A very enjoyable and productive environment.
>
>I've gone one too long. I hope everyone has a good week. Oh yeah, in
>response to the original question in this thread, no way!
>
>Regards,
>
>Larry G. Elkins
>The Elkins Organization Inc.
>elkinsl_at_flash.net
>214.954.1781
>
>An analogy might be tenant / landlord. Developers "occupy" the
>database, but the DBA "owns" it. Some tenants will take care of
>the place and treat it as well as if they owned it; others will
>do whatever they like for the short haul and if something breaks
>due to neglect, hey that's the landlord's problem, let him/her
>come fix it. As if we have a two-second fix for everything.
>
>
>Larry Holder
>Senior Systems Analyst, Oracle Database Administrator
>The University of Tennessee at Martin Computer Center
>lholder_at_utm.edu (901) 587-7890 www.utm.edu/~lholder
>Saved by grace <>< Romans 8:38-39
>
>--
>Author: Larry G. Elkins
>INET: elkinsl_at_flash.net
>
>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).
>
>--
>Author:
>INET: Kimberly.smith_at_gmd.fujitsu.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).
>--
>Author:
>INET: dgoulet_at_vicr.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).
>
>
>______________________________________________
>FREE Personalized Email at Mail.com
>Sign up at http://www.mail.com/?sr=signup
>
>--
>Author: Cyril Thankappan
> INET: cyril_thank_at_india.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).

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

--
Author: Rachel Carmichael
  INET: carmichr_at_hotmail.com

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





===================================================================
De informatie verzonden met dit E-mail bericht is uitsluitend bestemd voor
de geadresseerde. Gebruik van deze informatie door anderen dan de
geadresseerde is verboden. Openbaarmaking, vermenigvuldiging, verspreiding
en/of verstrekking van deze informatie aan derden is niet toegestaan.
Ernst & Young staat niet in voor de juiste en volledige overbrenging van de
inhoud van een verzonden E-mail, noch voor tijdige ontvangst daarvan.
===================================================================
The information contained in this communication is confidential and may be
legally privileged. It is intended solely for the use of the individual or
entity to whom it is addressed and others authorised to receive it. If you
are not the intended recipient you are hereby notified that any disclosure,
copying,  distribution or taking any action in reliance on the contents of

Received on Thu Aug 03 2000 - 03:10:22 CDT