Related to the question about what project managers do all day...
I have asked this amongst my colleagues at work who are all web developers. Part of our job is to basically be part DBA for our own projects.
But we spend most of our time developing in .NET not SQL.
So what does one do when one is working full time as a DBA?
You administrate databases.
Which means:
Basically, think of a DBA as a mechanic that works to keep your car running at peak performance at all times.
You need DBA when you have large databases and a lot of applications accessing them.
On architectural level, DBA gets to be the one who 'allows' access paths, creates stored procedures, makes sure that naming of database objects is consistent, etc.
On sysadmin level, DBA track the disk space usage, memory usage and CPU usage of DBMS, changes settings for database cache, writes scripts to move data between databases, etc. With large systems which have multiple databases and a lot of programmers that need to access them, DBAs have enough to do for a full time job.
Please note that DBAs are mostly employed to work with production systems, while you work with development systems.
Here are some of the things a DBA might do that supports your project:
Here are some other things a DBA might do beyond supporting your project:
These are just a few of the things a DBA does. I'm sure other posters will have more suggestions. In the meantime, please try to view the DBA as a member of your team.
Live in terror of data corruption or loss while we all enjoy the correct data asking what are they paid for. Have you ever seen what a faulty RAM DIMM can do to a live database in a couple of hours? A DBA makes sure things like that never happen.
Optimizing stored procedures. Study the execution plan. Test various alternative SQL and indexes, perhaps table normalization or denormalization, to speed things up.
As far as I'd seen in my (incredibly) limited experience, this is probably the most important part of being a DBA. I guess this would mean that if your company employed DBA's, there would be an incredible drive on their part to make absolutely all database access go via stored procedures?
As a developer, I couldn't think of anything worse. IMHO a database is part of an application, not something in it's own right. A DBA won't know how the rest of the application works, so how does that put them in any position to control how the database part works?
I used to work in a shop where the DBAs, in addition to some of the other replies posted here, would be the owner of the database architecture.
All physical/structural changes are done in coordination with the DBA team, who is the only group allowed to make these changes in any environment other than development. They create the scripts, work with the developers, and serve as a change management control board.
For interfaces (SPs, UDFs, etc), they manage them in the production environment, and check them for consistency and quality (in a larger shop, a lot of different types of programming style can exist from one SP to the next, depending on author). They maintain the library of production interface code (and keep a version control history of production).
Additionally, large clustered databases require management, not just involving replication (this enterprise has databases in different parts of the world, for redundancy and fault tolerance).
Lastly, performance, optomization (indexing) and tweaking grow as an effort as the size of the databases on the server grow (num databases, amount of data, amount of structure, etc). Even a perfectly architected database will have more of these things to manage, if it is successful.
I'm sure Google, for example, has a good number of people employed just to keep the data farm operating efficients and reliably.
The #1 most important job a dba has is to make sure the data is recoverable (have you tested those backups lately?) and available.
After that, the lists that lassevk, codeguru, and DOK wrote are the secondary priorities.