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:
- 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.
- Development DBA - works on building queries, stored procedures, etc. that
meet business needs. This is the equivalent of the programmer. You primarily
- 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.
- 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.
- 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
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 firstname.lastname@example.org.
©dkRanch.net July 2001