Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Development guidelines between DBA & developer

RE: Development guidelines between DBA & developer

From: Boivin, Patrice J <>
Date: Mon, 18 Apr 2005 10:42:08 -0500 (EST)
Message-id: <1A4AC4BAB9C50A42854582B69B08C0340828FC42@MSGMARBIO05>

This is an interesting question, where is the overlap between developers and DBAs...

After applications have been written and are in production, sometimes developers want to administer the applications.

That may or may not be appropriate, depending on your shop.

The grey area begins when they want control over the underlying database. Watch out when managers start talking about "Application DBAs", instead of "Application Administrators." (not the same as "Oracle Applications Suite Administrators", that's another beast)

One of the things application administrators like to request is the ALTER SYSTEM system privilege in order to be able to kill wayward user sessions.

Pre-Oracle 8i developers also like to define storage parameters for the objects that are created, then wonder why the objects don't have the sizes they specified when you are using locally managed tablespaces with uniform extents.

One point I would enforce is that as long as SQL is not tuned properly, there is no point in granting more privileges. If they haven't decided they require a copy of a good SQL tuning manual (like the SQL High-Performance Tuning book by Guy Harrison), keep an eye on the SQL going through your databases.

Not all performance issues are SQL related, but when SQL is not tuned, it can be disastrous. I tuned an SQL statement once and brought it from taking hours to under a minute. The end user was ecstatic.

First code properly, then maybe.

In my opinion Application Administrators need to be SQL tuning, application architecture, and application design pro's. They have to be competent, experienced developers who have good intuition about what might be causing problems.

I would start with the basics: Do they know what the EXPLAIN PLAN command is? You'd be surprised how many have no idea what it is, or how to read an execution plan.


-----Original Message-----
From: mhthomas [] Sent: April 14, 2005 1:27 AM
Cc: Oracle-L (
Subject: Re: Development guidelines between DBA & developer



On 4/12/05, Amihay Gonen <> wrote:
> Hi all,

> I'm looking for an optimal way for defining the work between the developm=
> team and the DBA teams.

I don't know about writing documents about these topics. How about some practical tips?

I like to create metalink (dev) accounts for developers, but not give tars. Also, I try to point out good books to developers regarding Oracle. If successful, I don't have to answer many questions about re-inventing referential integrity and sequences. ;-)

Also, I download all the Oracle docs we might be using in a couple directory paths. Then I use acrobat to create indexes and teach the developers how to use reader version 7 and acrobat indexes to search the docs. I add the installation docs to the fat pdf libraries, and include multiple platforms. My indexes include more stuff than Oracle's acrobat indexes. Then I put the files on a windows server share, and shortcuts with //server/file paths as icons in another directory. The developer's can map the drive once, copy the shortcuts to their desktop, and drop the mapped drive.

It paid off this week when they found out how to check open cursors, and it wasn't their application (like I thought, oops) but rather EM sessions opening hundreds (thousand+) of cursors. We have our warning level set low on 10g alerts, and I didn't check because I was lazy and they caught me. It feels good to get good questions, and especially good to be caught in a mistake.

If the development database is safely isolated then more freedom can be given developers. If servers are shared, I'd lock the servers down harder. Have a backup and recovery plan for development, different than production.

HTH Regards,

Mike Thomas

Received on Mon Apr 18 2005 - 11:44:25 CDT

Original text of this message