What's a DBA? - My Overview

Introduction

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.

Conclusions

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