SQL Server Reference Guide

I was recently asked by a technical professional about how they could become a database professional. It was an interesting question, because I've answered it verbally many times but even in the four books and hundreds of articles I've written, I've never directly addressed it. Throughout this article I'll use the term "DBA" to refer not only to the administrator role, but also to development, data analysis and other database professions as well.

I think it's great to be a DBA for several reasons. You're normally in a small group of technical professionals. While there may be dozens of developers, administrators and other computer professionals in a company, there are often only a few or even one DBA. You also get to deal with not only the computing side of the organization but also its business. The variety of skills you need to have makes for a varied, interesting day.

But before I explore how to become a DBA, I probably need to define what that means. It's a bit difficult to quantify a complete job description for a DBA since each job environment is a little different. In other jobs, a role is often quite generic across companies. If you are a programmer, there are common tasks that you will perform at each and every job, whether you're writing software for the health industry or for a gaming shop. If you are a manager, your role is to attract, motivate and effective engage your workers to accomplish a goal.

Don't misunderstand — in each of these examples, there are plenty of differences in the job roles. Perhaps in the gaming example the focus is more on polygons and user interfaces, and in the health care example the focus is on process flow. One managerial position might be under harsh conditions with lots of direct-reports, another might be working in a less stressful environment with fewer employees. The point is that if you're a good software developer in one location you are usually a good developer in general, and if you're able to adapt to managerial challenges in one environment you can often do that in another.

But the DBA role is a bit different. Some of the skills I've learned as a DBA at one organization are not as useful at another. The differences are driven by several factors, including the work the shop ultimately does, the number and types of servers, and so on. But the primary factor is the company itself.

Yes, there are certain tasks that every shop needs, especially around the maintenance areas. I've detailed a list of these tasks and intervals in a SQL Server maintenance checklist in another tutorial. Whether you are a large shop or small, whether you have one server on a cruise ship or hundreds of servers in a data center, these kinds of tasks are required. But once the basic maintenance is completed manually or runs automatically, the job changes. Let's examine a few examples from my own career.

I've worked at several companies, from large to small. I've also contributed to a few open-source projects, and even been a consultant interacting with multiple other companies. One of my jobs was in the United States Air Force. In this environment, we used an Oracle database on a DEC VAX cluster in a large project-tracking system. In this environment, I was only allowed to do database work — I had no control over the operating system at all. In fact, I had to request new user accounts from the system operator.

In this job, my DBA duties focused on storage, performance, and object security. Because storage was expensive to procure and maintain, I made storage decisions at design time, rather than by tweaking things after the fact. This means that my job duties and skills were in the design of database systems, programming, and even business requirements. Quite a far cry from just maintenance!

In another role I had, I worked at a small software firm. Like most other employees, I wore "multiple hats," meaning that I didn't have a single title. In this situation money was always a primary factor, so I had to learn a great deal about licensing, open-source database systems, and deciding the best technology for use in a given situation. Once again, these are different skills than just knowing a lot about a particular database system.

In a couple of other jobs, I worked as a Business Intelligence developer. One was a small-scale system with a single source of data, and another was in a very large organization with dozens of data sources, including two SAP instances. The skills here involved everything from data visualization to archival strategies.

With all this variety, is there a single way to "become a DBA?" No, there is no single way, but there are some things you can do if you want to get and keep a job in one or more of these areas. Over the years I've been a manager of a DBA group or two, and I've been able to observe what skills and traits made a good database professional. I'll define "good" here as someone who seemed to enjoy the job, and was proficient at it.

Required Skills

To be a "good" DBA, there are a few skills and even traits that are necessary or at least useful.

The first trait I've found that is a requirement for a good DBA is attention to detail. Since you're often in a small group or even by yourself as the DBA, you aren't going to have a lot of people to check your work. You'll have to make sure you edit your own tasks to ensure that nothing is missed. Along with this skill is the trait of having a high-level of professionalism. If something needs to get done, there's a good chance you alone are the one that has to do it. Unless you have a lot of self discipline, your work will suffer.

Along with these traits, of course it helps to have an interest in technology. Interestingly, I've met people in this career fields who aren't "geeks," and don't care much about tech in general. While you don't have to build computers and attend Star Trek conventions in your spare time to be a good DBA, having an interest in technical matters other than just databases has been something I've observed in skilled database professionals.

Not only should you be interested in technology, one of the most defining characteristics of a successful DBA is an interest in business. I don't mean just interest in the business of where you work now, but in business in general. Even if you work at a non-profit or volunteer organization (I've done both), we're all in the business of business. In your role as a database professional you'll often stand in between technology and what the business is ultimately trying to do. Don't be surprised to find yourself in as many business meetings as technical ones.

On the technical skills side, one of the most useful is pattern recognition. This means that you should be able to recognized patterns not only in data, but in functions. This helps tremendously with database design and program flow.

Finally, I've found that the ability to abstract is another defining characteristic of a great database professional. We all do abstraction, and I've found it to be useful in all its definitions.

Formal Education

With all of these required skills and traits in place, there is also a place for formal education. But this is where things become a little more difficult.

Most colleges and universities don't have a degree program in "database professional." And interestingly enough, a Computer Science degree doesn't always guarantee a good DBA. To be sure, I think that computer science classes help, and are in fact a requirement. But I would argue that a better path for a DBA is to get a Business degree, with a minor in computer science, especially with a heavy emphasis on database courses. Why?

The primary reasons are the skills and traits I mentioned earlier. As you may have noticed, there's a lot of business and non-technical skills that you need to become a good database professional. By taking business courses, you'll prepare yourself well in those business meetings you attend. Some of the best DBAs (and developers and managers) I know are able to "do an ROI" with the best of the CFO's in the meeting.

This isn't to say if you have a CompSci degree (or no degree at all) that you can't become a DBA. I've seen people with even journalism degrees make fantastic DBAs. It's just that having a sound foundation in business fundamentals along with your technical knowledge makes for one formidable combination.

What about Certifications?

I've talked about certification in another tutorial, so suffice it to say that I think that certifications are a great tool to do two things: they prove to others you're at least partially interested in the field and they've force you to do a little study on your own. I have a few myself, but they are ancillary to my other knowledge, not the core.

Job Experience

Many DBA's start out in other parts of information technology. Others are brand-new to technology, and want to break in to the job. There are different strategies for both groups of people to move into the DBA role.

Getting Job Experience for the First Time

So you're fresh out of college with that business degree and with a minor in Computer Science and a focus on databases, or you haven't attended college yet but you did well in school and have all the traits and skills I mentioned earlier. But you don't have experience in the role yet. Since there are only a few DBAs in an organization, the hiring staff doesn't want to bring you in with no experience, but you can't get experience because no one will bring you in. What to do?

Don't despair — there are lots of ways you can get experience. The first is to set up a system of your own, write an application, maintain the database system, and break and fix it as often as you can. Although this might not sound like experience on the surface, it is. I've got lots of resources on Informit that will help you do that.

Second, volunteer at a charity or church to help with their database tasks. Almost everyone uses technology today, and these organizations usually have a current professional that volunteered to help, but would love to train you to do the job.

Now you've got a little experience, and you're in a similar place as a current technical professional that wants to move into the role.

Progressing as a DBA

Perhaps you have a lot of experience as a technical professional, but you want to become a DBA. How do you start?

Begin by taking on a project that requires a small database. Learn about how to design and develop databases by looking at the various sections I have at this site, and put that knowledge to use. As you complete one project, seek out new, larger ones. Eventually you'll work right into the role.

That might sound a bit too simplistic, but it does work — as long as you follow two simple rules.

The first rule is that you treat each of these projects — regardless of how small or importance — like it's the most important, delicate thing you've ever done. Make notes, create lots of automation, and log the process. The key here is to use each project to learn something new.

The second rule is to ensure that others (especially other managers) know that you're doing this kind of work, and that you're interested in doing more of it. Be ready to move positions when approached, and even to move locations if needed to get the experience.

So is all this training and work worth it? I think so. I've enjoyed my career as a database professional, and look forward to not only using exciting new technology, but contributing to the industry as well. I just love this stuff.

Informit Articles and Sample Chapters

In this tutorial I've alluded to multiple kinds of database jobs. And in this article I explain that concept a little further.

Online Resources

Another great resource to learn more about the job is this link from Database Journal.