16

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?

12 accepted

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.

7

Here are some of the things a DBA might do that supports your project:

  1. Write ETL (DTS, SSIS packages) to transfer production data to your development database, and to migrate your dev database tables, sprocs and data to QA, UAT and production databases.
  2. Perform backups of your databases. And restore last night's copy of the dev database when somebody makes a big mistake.
  3. Database optimization on your database. Performance tuning, indexing.
  4. Optimizing stored procedures. Study the execution plan. Test various alternative SQL and indexes, perhaps table normalization or denormalization, to speed things up.
  5. Establish database permissions for developers and users.
  6. Assist in SQL design to handle complex business logic. Work out the database schema, suggest SQL that will accomplish the application's objectives. Sometimes there's a choice in performing complex calculations in the app vs. in the database. Architectural decisions are important here, but sometimes there are real performance issues to consider.
  7. Advise on issues such as setting primary and foreign keys, unique constraints, indexes and other "macro" kinds of issues.

Here are some other things a DBA might do beyond supporting your project:

  1. Production support for your last project and other people's projects. Including sometimes 24/7 support for when the database becomes unresponsive.
  2. Migrate databases to newer versions of the RDBMS. Apply software updates, service packs and patches. Test all of these before they are applied.
  3. Study industry trends and technological advances as carefully as you do. Follow blogs and other websites dedicated to important database issues such as security.

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.

4

You administrate databases.

Which means:

  • Keep tabs on the databases on your servers
  • Monitor the servers, cpu usage, memory usage, disk utilization
  • Monitor workloads, see if there are issues with the databases that might need to be resolved, like missing indexes, different ways to organize the data
  • Data import/export/merge/mirroring/replication

Basically, think of a DBA as a mechanic that works to keep your car running at peak performance at all times.

3

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.

1

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?

1

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.

0

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.