Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re:RE: WILL YOU GIVE PROGRAMMERS DBA ACCOUNT IF WE SAID YES?


From: Cyril Thankappan <>
Date: Thu, 3 Aug 2000 05:22:31 -0400 (EDT)
Message-Id: <>

Hi! Jack..

can you please tell me what are ur responsibilities as "junior" DBA and what r ur boss' responsibilites as "senior" DBA.

------Original Message------
From: "Jack van Zanen" <c>
To: Multiple recipients of list ORACLE-L <> Sent: August 3, 2000 8:43:51 AM GMT


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.


"Rachel Carmichael" <> on 08/03/2000 01:04:13 AM

Please respond to

Sent by:

To: Multiple recipients of list ORACLE-L <> cc:

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 <>
>To: Multiple recipients of list ORACLE-L <>
>Date: Wed, 02 Aug 2000 12:36:09 -0800
>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
>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
>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 <>
>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
>developers is true heaven on earth. Regrettably I have a number of good
>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
>possible, be proactive, and learn what you can about the apps. Namely be a
>DBA and a fair developer at the same time. OH, BTW: one easy way to not
>space problems is to get reasonable space estimates up front and then add
>50% to that. It's hard, but essential. And to the original question, NO
>Dick Goulet
>Senior Oracle DBA
>Vicor Corporation
>____________________Reply Separator____________________
>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-----
>Sent: Wednesday, July 26, 2000 6:24 PM
>To: Multiple recipients of list ORACLE-L
>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
>just as we have all run into some/many/all developers who are horrible
>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
>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
>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!
>Larry G. Elkins
>The Elkins Organization Inc.
>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
> (901) 587-7890
>Saved by grace <>< Romans 8:38-39
>Author: Larry G. Elkins
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
Received on Thu Aug 03 2000 - 04:22:31 CDT

Original text of this message