Home > Articles > Data > SQL Server

SQL Server Reference Guide

Hosted by

DBA Levels

Last updated Mar 28, 2003.

The boom years of tech seem to be behind us now, at least for the foreseeable future. Of course, firms will always need technology, and they'll need professionals to implement that technology. However, as it is new technology that gives most businesses their competitive edge, and the pace of change in technology, you've got the ingredients for an increase in professional demand.

While that's true, two factors mitigate a resurgence in hiring here in the U.S., especially in short term.

The first is the type of work that is required by most firms. Most of the work at the "higher" levels in IT has been filled by people who aren't moving around anymore. That leaves a few choice jobs, with the rest of the positions in the automated and entry levels of work.

The second factor is the recent trend in outsourcing, especially to overseas firms. It's simply cheaper to have automated steps and entry-level work performed by a labor pool in another country than here in the U.S.

I won't argue the merits and the drawbacks of these developments, since they are simply factors in today's technical landscape. What I've done in my personal career to insulate myself from an adverse job market is to educate myself to make my credentials more marketable. I've gotten certifications and college degrees, and continue to research as much as I can about my chosen profession.

I've also worked in just about every area of technology there is. I've soldered integrated circuits on various boards, taught computer courses, worked the helpdesk, written technical manuals, swapped tapes on a mainframe, been a systems administrator, and even wrote code here and there. For a while, I was the Oracle Database Administrator on an HP-9000 midrange system running UNIX. I worked as a database consultant for a few years. After that, I became involved with a few large IT projects and eventually became an IT manager.

I enjoyed being a DBA, and I've returned to that line of work. I've learned a great deal, and along the way I've developed a few ideas about the DBA profession.

I group DBAs into three levels. I say "levels" since that implies a range of knowledge and experience within each one, and one level depends on another.

The Maintenance DBA

At the first level is the maintenance DBA. This technical professional performs most of the tasks that keep a database server operational. The maintenance DBA gains proficiencies with security accounts, implementing database and server security at the application, platform, or server level. This requires a working knowledge of how the different security methods interact.

In addition, maintenance DBAs understand the server software and hardware. They learn about the various hardware technologies regarding Central Processing Units, memory, network cards and storage technology. They know about file groups and how to use them. They also understand various networking protocols and how they affect speed and encryption.

Of course the most visible tasks a maintenance DBA performs involve disaster recovery. While many DBAs are well versed in backup strategies, fewer have actually developed a plan for testing the efficacy of restoration. Most shops have a backup plan; few have a recovery plan. Good maintenance DBAs ensure that their shops have both.

Maintenance DBAs also implement standard database maintenance tasks such as re-indexing. They help develop the strategy for optimizing the database within the time constraints of the applications.

While most DBA's start at this level, it certainly isn't a purely entry level position. If you consider yourself a higher-level DBA, ask yourself if you know the difference between an AMD and an Intel processor, and how those differences affect SQL Server. Also ask yourself which vendor has the best hardware strategy for a Storage Area Network, and which protocols can be used for encryption. An accomplished maintenance DBA knows the answers.

Development DBAs

The next level into which I group DBAs is the Development DBA. These technologists are very familiar with Transact-SQL, the SQL language dialect spoken by SQL Server. The knowledge at this level involves the best interface to use to get at the data the database stores, when an N-tier solution is superior to 3-tier, and when to use stored procedures versus dynamic SQL.

Development DBAs also design the indexes in a system. They understand when to use a clustered versus a non-clustered index.

It's in development that a DBA begins to interact more with the business side of the company. The development DBA often serves as the bridge between what the users desire and what is technically possible to deliver.

You might think that the two levels I've just mentioned can be separate jobs. It could be argued that you don't really have to understand processors to write effective stored procedures. While that's true, I believe that to make the proper design choices you need to have a background in the day-to-day operations of a system. Too often, I've seen development shops create a design that can't be supported on the hardware platforms available at the firm. The old saying holds true here: "In theory, there is no difference between theory and practice. But in practice there is."

Often a database developer has formal programming skills, and it's best to have them in more than one language. This helps with those decisions I mentioned earlier, regarding stored procedures and tier choices.

The Data Architect

At the next level is the Data Architect. In this position the technologist provides guidance to the business about data and platform strategies. To adequately perform this task, a Data Architect needs a very good understanding of how the firm does business. While certain concepts are generic across an industry, some details can change the database landscape a great deal. For example, while all companies use a general ledger, a medical firm has requirements that aren't seen in a financial company.

The Data Architect also understands data retention strategies. How long should you keep each piece of data, where it should be stored and in what format, how it should be disposed of? These are questions that the Data Architect deals with.

In addition, the Data Architect also designs data integration strategies. Companies and organizations create a lot of data, especially when they are quite large. Making sure that this data has a "single version of the truth" somewhere and is consistently reportable often creates the need for Enterprise Data Warehouses and Online Analytical Processing systems at the corporate level. If the firm is subject to public accounting rules this type of strategy is essential.

So where are you in your career? If you're interested in progressing in the IT world, Database Administration is a great place to be. Beyond the maintenance tasks, most companies don't like to outsource their databases, since they hold the very data they need to survive. Senior DBAs are viewed as on the "business side of the house," and as such are often insulated from outsourcing troubles.

To make sure you progress, never stop learning. That doesn't mean you have to implement the latest thing – far from it. Having a good understanding of database options helps you and your business manage their data.

Online Resources

You can find a lot of training for level 1 and level 2 on the Web, but Microsoft has the authoritative info.

InformIT Tutorials and Sample Chapters

There are tons of links here on Safari and all throughout the site.