My two cents on becoming a DBA


On various websites you can read how to become a DBA and there are several discussions how to start as a DBA. In this post I’ll tell my story how I became a DBA and some tips what you can do to become a DBA.

My first chance

I’ve had the privilege that I had the chance to start as a junior DBA at a company where I was introduced into pretty advanced features of SQL Server. Features like Clustering, Log shipping etc.
The only problem was that the person who was responsible for teaching me quit his job a few weeks later after my arrival.

The only knowledge I had was from the Microsoft books where I passed the SQL Server 2005 MCTS exam.

The company didn’t want to hire a new DBA so all the tasks were handed to me. I must say that was a very busy time.
Try to understand that my predecessor didn’t document anything and all the knowledge he transferred to me was not more than a simple one page of users and passwords to log in to the 40+ servers that the company had.

Finding documentation

The first thing I do at every jobsite I come in is, look through documentation that the department created. In my case the former DBA hadn’t documented anything so I went to the system engineers. Fortunately they had documentation how the servers were installed and where they were placed in the serverrooms (there were several serverrooms).

The thing I always tell people is to create documentation about everything on your server(s). There is no excuse to say that you don’t have the time, MAKE TIME!! In the end you’ll thank me because when the shit hits the fan you’ll have the information you need.

The documentation gave me a start but was not enough to get me fully started. What to do??

Where to start

In my situation I had more than 40 production servers and several configured to do Log shipping, Clustering services and Replication. None of these are mentioned in the certification I had so I decided not to start with these features until I got a good grasp on the configuration of all the servers. I had to maintain the services though but fortunately SQL Server is very robust and we had a few good system engineers that kept everything running smoothly.

For every server I created a document with the following information:

  • Servername
  • Server version (service packs etc)
  • Databases
    • Size of the data file (MDF)
    • Size of the log file (LDF)
    • Recovery model
    • Compatibility level
  • Security options
  • Server Objects
    • Backup devices
    • Linked servers
  • Maintenance plans
  • Jobs

I created a template for Word where all this information can be placed. You can download it at the bottom of the post.

The document comes in handy when you have to search for changes or other information. It may take some time to do this for all your servers but it helps. The document is ment as a start and you may want to add additional information and you’re welcome to do that.

Create baselines

The next thing I would recommend to do is to create a baseline for every server. A baseline is data that can be used to compare performance issues, test installations, can be used with the DTA (Database Engine Tuning Advisor).

The following articles can help you create good baselines. I don’t want to get this article to be huge, that’s the reason why I use other (good) articles.

Creating a Performance Baseline – Part 1

Creating a Performance Baseline – Part 1

Depending on the amount of data generated by the SQL Server Profiler (Nowadays I don’t use Profiler anymore but we’re talking about more than 10 years ago) I’d let the baseline run for 1 to two days. Keep in minds that at very busy systems this can cause performance problems.

Start learning

After I got myself adjusted to the situation, and I had a start with the information I needed, I could go on making an inventory of the situation.

In order to do this I had to learn a lot about High Availibility because this company did that in any way possible and nobody else had a clue how the former DBA created the solutions.

I started learning for the MCITP SQL Server Administrator. After I passed the exams I still didn’t have a good grasp on the situation. I had no experience in High Availibility and I wanted to familiar with it.

I learned the most by surfing the web, reading articles and answering questions on forums.
Answering questions on forums gave me the most experience. I saw questions that I’d never have thought of. While doing this I got further and further and after a good year I could finally say that if a problem existed I could at least find the solution to the problem or solve it right on the spot.

Due to the documentation of all the servers I was able anticipate on (possible) problems.

Monitor everything

As a DBA you’re not just solving problems when they occur. You’ve got to monitor your servers constantly. This not a task that’s done once a day.

You have to monitor the CPU’s, memory, growth of the databases etc etc. Anything that could possible create a problem needs to be monitored.

There are several products in the world that can help you with that. I don’t have shares in the products, these are just some I’ve used in the past:

If you’re starting somewhere and there is no logging on SQL Server level you’ve got the responsibility to advise your superior to get some kind of tool, free or commercial, that will help you do your work.

My predecessor didn’t have a tool that monitored everything. Instead he checked every server, several times a day by logging in into the server and check the errors logs to see if any problems occurred. This task was getting so time consuming that it took a good part of the day and didn’t leave him able to do anything else.


There’s nothing stronger than the community and being part of the SQL community makes it possible to meet new interesting people and learn from them. Everybody started as a beginner and you can probably help others get started.

Try helping people on forums makes you aware of issues that might happen to you and if your answer helped someone than you have a win.

Try getting in contact with people from the SQL Saturdays and see if you can volunteer.

Closing words

I’ve been a DBA for over 13 years now and I personally don’t like to call myself a senior DBA just because there are a lot of people so much further along the path than I am. But I do think the way I did things like I mentioned above helped me to work in a structured way and gave me the opportunities I have had untill this day.

I hope this helped you and if you have any comment please do 😉


Leave a Reply