Database Reference
In-Depth Information
The DBA-Developer Relationship
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 system administrator (SA). Setting up Oracle Net, getting the listener going,
configuring the shared server, 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 the
use of your operating system of choice, but you shouldn't expect to have to tune it.
The single largest DBA responsibility is database recovery. Note I did not say “backup.” I said “recovery,” 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 and figuring out what the optimum
PGA_AGGREGATE_TARGET
should
be—that's typically the job of the DBAs (and the database is quite willing and able to assist them in determining the
correct figure). 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 decision.
Allocating space and managing the files is the job of the DBA. Developers contribute their estimations for space
(how much they feel they will need), but the DBA/SA takes care of the rest.
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 work together on different pieces of the same puzzle. The DBA will visit you, the
developer, when your queries are consuming too many resources, and you will visit the DBA when you can't 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 all varies 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 skill sets, two different mind-sets, and two different personalities in
my opinion.
Summary
In this chapter, we have taken a somewhat anecdotal look at why you need to know the database. The examples
I presented are not isolated—they happen every day, day in and day out. I observe a continuous cycle of such issues
happening, over and over.
Let's quickly recap the key points. If you are developing with Oracle:
•
You need to understand the Oracle architecture. You don't have to know it so well that you
are able to rewrite the server, 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
these features
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. Trying to ignore it would be fatal.
