SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

What's a DBA? - An Overview

By Steve Jones,

What's a DBA? - My Overview


I've gotten this question more than a few times. Usually from someone wanting to be a DBA or just getting started, but I think managers are often wondering exactly what a DBA is and why one is needed. Why not just let a system admin handle the duties? Or a senior developer? There are lots of good reasons why not and I do think that DBAs provide a valuable service to companies.

I started this article last year, but it quickly got long and out of hand. I decide to then break it into a series of articles on what a DBA is (hopefully) along with feedback from you readers out there. This article will cover the overview of how I see the DBA role, with more detailed articles on the duties and roles of the different types of DBAs that I see in the world.

What's a DBA?

There are lots of different duties for a DBA and there is not good "job description". From what I have seen, there are a few basic types of DBAs:

  1. Administrative DBA - Work on maintaining the server and keeping it running. Concerned with backups, security, patches, replication, etc. Things that concern the actual server software.
  2. Development DBA - works on building queries, stored procedures, etc. that meet business needs. This is the equivalent of the programmer. You primarily write T-SQL.
  3. Architect - Design schemas. Build tables, FKs, PKs, etc. Work to build a structure that meets the business needs in general. The design is then used by developers and development DBAs to implement the actual application.
  4. Data Warehouse DBA - Newer role, but responsible for merging data from multiple sources into a data warehouse. May have to design warehouse, but cleans, standardizes, and scrubs data before loading. In SQL Server, this DBA would use DTS heavily.
  5. OLAP DBA - Builds multi-dimensional cubes for decision support or OLAP systems. The primary language in SQL Server is MDX, not SQL here.

Being a DBA (in general) is tedious. You have to plan for the future, anticipate places where your schema will be bent or stretched. Plan for growth and make very, very few mistakes. It's not like "C" or Visual Basic development where you will fly by the seat of your pants when building this application. Your decisions affect data that has far reaching effects. Also, since you work in a set-oriented environment, you can make mistakes quickly that affect more items. Unlike a class or structure where you have a small set of data (i.e., one customer), a single line in SQL can affect all customers in a structure. How many of you have issued a "delete <table name> without a where clause?

Who takes care of the "System"?

Well, it varies. In general, in smaller companies, the DBA might perform all the roles above and apply service packs, upgrades, etc. In larger shops, the DBA might not do anything on the NT/UNIX side and only handle the application (SQL/Oracle/DB2, etc.). In my company, I handle all SQL related items, including service packs for SQL. NT/2000 service packs and patches are applied by the sysadmin. HE also replaces/adds hard drives, memory, etc. Performs tape backups. I merely ensure SQL Server keeps running and let him know if I need something.

I can't really speak about Oracle or other RDBMSs, since I have only developed applications against the DB and then through ODBC (many years ago). Oracle in general, from my limited knowledge, requires more of a hand's on, command line approach to management (which is a good thing, IMHO). So shell programming can really help you here.

It's tough to decide if you want to be a DBA. On one hand it can be boring if everything runs well (for me its kind of boring now). But when something breaks, there is tremendous pressure and stress. Ever had a database go down and the President of the company walk into your office or the computer room to "inquire" about the status? Not something you can simulate in school.

Preparing for DBA-dom

I'd learn about relational and database theory. Read about it and see what people think. IMHO, there is no "right" way, but lots of trade-offs in any design. Learn as much as you can and then make a decision that fits your situation. I have a broad range of experience in networking as well as software development and I think that really helps me. I understand how to build an operating system, so I have a feel for what occurs inside the machine. Knowing how networks move data also helps to design a better system as well as troubleshoot problems. In today's world, I think understanding how networks connect is very important. In the MS world, I think systems programming is only required if you want to be a systems programmer. In the *nix world, knowing how to develop system utilities is helpful, but I don't think it's required.


This is my opinion and my feelings based on personal experience and reading. I am sure some people disagree, but I'd love to have feedback to alter this article. I would especially like to hear from the non-SQL Server DBAs. If you know someone who is an Oracle, DB2 or other DBA, please send them this article and ask them to send me feedback at sjones@sqlservercentral.com.

Steve Jones
┬ędkRanch.net July 2001

Total article views: 8849 | Views in the last 30 days: 4
Related Articles

A Reporting System Architecture

This article describes one method of implementing a reporting system in SQL Server 2005


Five Rules For Successful Conversations With Developers

In this piece, Josh follows up on his earlier article about smoothing DBA/Developer interactions, th...


701: There is insufficient system memory to run this query

701: There is insufficient system memory to run this query


DBMS vs File Management System

This is a high level article that compares the use of a DBMS with file management systems. Interesti...


Agile Development with Scrum

We've all been there: the project that never ends and no light at the end of the tunnel. Nothing is ...