RE: Development guidelines between DBA & developer
- From: "Boivin, Patrice J" <BoivinP@xxxxxxxxxxxxxxxxx>
- To: "Oracle-L (oracle-l@xxxxxxxxxxxxx)" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 14 Apr 2005 08:07:50 -0300
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.
Patrice.
-----Original Message-----
From: mhthomas [mailto:qnxodba@xxxxxxxxx]
Sent: April 14, 2005 1:27 AM
To: AmihayG@xxxxxxxxx
Cc: Oracle-L (oracle-l@xxxxxxxxxxxxx)
Subject: Re: Development guidelines between DBA & developer
Hi,
in-line
On 4/12/05, Amihay Gonen <AmihayG@xxxxxxxxx> wrote:
> Hi all,
>=20
...
> I'm looking for an optimal way for defining the work between the developm=
ent
> 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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
