The back cover of this book talks of the importance of a DBA
knowing what the developers are trying to accomplish and of
developers knowing how to exploit the DBA's data management
strategies. It's certainly true that the most successful
information systems are based on a symbiotic relationship between
the DBA and the application developer. In this section I just
want to give a developer's perspective on the division of work
between developer and DBA (assuming that every serious
development effort has a DBA team).
As a developer, you should not necessarily have to know how to
install and configure the software. That should be the role of
the DBA and perhaps the SA (System Administrator). Setting up
Net8, getting the listener going, configuring MTS, enabling
connection pooling, installing the database, creating the
database, and so on — these are functions I place in the
hands of the DBA/SA.
In general, a developer should not have to know how to tune the
operating system. I myself generally leave this task to the SAs
for the system. As a software developer for database applications
you will need to be competent in use of your operating system of
choice, but you shouldn't expect to have to tune it.
Perhaps one of the biggest concerns of the DBA is how to back up
and restore a database, and I would say that this is the sole
responsibility of the DBA. Understanding how rollback and redo
work — yes, that is something a developer has to know.
Knowing how to perform a tablespace point in time recovery is
something a developer can skip over. Knowing that you can do it
might come in handy, but actually having to do it — no.
Tuning at the database instance level, figuring out what the
optimum SORT_AREA_SIZE should be — that's typically the job
of the DBA. There are exceptional cases where a developer might
need to change some setting for a session, but at the database
level, the DBA is responsible for that. A typical database
supports more than just a single developer's application. Only
the DBA who supports all of the applications can make the right
Allocating space and managing the files is the job of the DBA.
Developers will contribute their estimations for space (how much
they feel they will need) but the DBA/SA will take care of the
Basically, developers do not need to know how to run the
database. They need to know how to run in the database. The
developer and the DBA will work together on different pieces of
the same puzzle. The DBA will be visiting you, the developer,
when your queries are consuming too many resources, and you will
be visiting them when you cannot figure out how to make the
system go any faster (that's when instance tuning can be done,
when the application is fully tuned).
This will all vary by environment, but I would like to think that
there is a division. A good developer is usually a very bad DBA,
and vice versa. They are two different skillsets, two different
mindsets, and two different personalities in my opinion.
Here we have taken a somewhat anecdotal look at why you need to
know the database. The examples I have given are not isolated
— they happen every day, day in and day out. I observe a
continuous cycle of this happening over and over again and again.
Let's quickly recap the key points. If you are developing with
- You need to understand the Oracle architecture. You don't
have to know it so well that you are able to rewrite the server
if you wanted but you should know it well enough that you are
aware of the implications of using a particular feature.
- You need to understand locking and concurrency control and
that every database implements this differently. If you don't,
your database will give 'wrong' answers and you will have large
contention issues — leading to poor performance.
- Do not treat the database as a black box, something you need
not understand. The database is the most critical piece of most
applications. To try to ignore it would be fatal.
- Do not re-invent the wheel. I've seen more then one
development team get in trouble, not only technically but on a
personal level, due to a lack of awareness what Oracle provides
for free. This will happen when it is pointed out that the
feature they just spent the last couple of months implementing
was actually a core feature of the database all along.
- Solve problems as simply as possible, using as much of
Oracle's built-in functionality as possible. You paid a lot for
- Software projects come and go, programming languages and
frameworks come and go. We developers are expected to have
systems up and running in weeks, maybe months, and then move on
to the next problem. If we re-invent the wheel over and over, we
will never come close to keeping up with the frantic pace of
development. Just as you would never build your own hash table
class in Java — since it comes with one — you should
use the database functionality you have at your disposal. The
first step to being able to do that, of course, is to understand
what it is you have at your disposal. Read on.