Home


Professional Services











Subscribe To This Site




Becoming a DBA - through a newcomer�s eye


Become a DBA By Justin Hostettler-Davies (c) 2008

Career Centre - Becoming a DBA



Becoming a DBA - First of all, what is a DBA? Since nowadays it depends on what kind of DBA you're talking about.
In the purest sense, a database administrator takes care of the maintenance and other administrative tasks on a database server, or set of servers.Not only are there different roles that a DBA fills, the experience required in these areas varies.

So the skills required to become a DBA are quite difficult to pin down. Nevertheless, there are certain skills, knowledge and experience that all DBA's share. And hence all Newbie DBAs strive for.It's great to be a DBA for several reasons. Like me, you're normally in a small group of �technical professionals�. While there may be dozens of other computer professionals in a company, there are often only a few or even one DBA. I�m lucky, I also get to deal with not only the computing side of my organisation but also its business. The variety of skills I need to have makes for a varied, interesting day � or at least it should do.
I�m going to tell you a little bit about myself, how I came to be a DBA.

This paper aims to describe my early experiences as a novice SQL Server DBA and how I found the best places to seek help and advice.

Becoming a DBA - So how do you become a �good� Newbie? What does that mean?

Most DBAs, don�t plan to become DBAs, they fall into it because they were working within a technical department or on a related project. For example, perhaps they were NT administrators, or maybe they became a Microsoft Access wizard, and then decided to trade up. In other words, they don�t start out with any formal training or experience either, but when the opportunity arises to use SQL Server in some way, they take the opportunity to gain as much experience as they could, and then leverage it to become full-time DBAs. That�s what I did.

I began my working life as a general support analyst, servicing both hardware and minor OS / applications. I was hired straight from Uni and thrown into the big �working� world.I did this for a while, then got a bit bored and started to �play� around, wanting to learn more. As my department grew and the organisation as a whole branched out into the database arena, my eagerness to learn and develop new skills became apparent.

I got what I consider to be my �break� when my department were looking for someone with any database skills, or interest in databases to help bring in new releases of major applications. I couldn�t express my interest fast enough!

I got to work on configuring and maintaining some �noddy� databases at first � but this allowed me to play a bit more!After constantly asking �why�, or �how does that work� I learned a lot in a short space of time.

About a year later (during which time I continued to play and ask �why�) I became an established member of the team � on my way to becoming a true DBA.That was when I learned what Baptism of Fire meant!

That was 3 and a half years ago.In that time I�ve moved from being a complete database Newbie, to slightly less of a Newbie who is now the SQL Server lead for my team and responsible for maintaining many critical applications and their underlying SQL databases.

So that�s me, so why am I writing this article?

I�ve read numerous technical papers on various aspects of SQL Server and its functionality etc I got to thinking, wouldn�t it be great if someone wrote something straightforward and non-daunting (hence non-technical) for new SQL Server administrators � Newbies.

And here it is! What I want to achieve with this article is to help other newbies in the infancy of their SQL Server journeys. I will aim to identify pitfalls to avoid and tips to use in the �nursery years�

So, it�s your first day in your new role of DBA. Where do you start?

The first thing you need to do is familiarise yourself with the systems you will be working on.

Learn about the databases you will be working on � and what they will be used for.How many production systems are there, are they running 24x7 � how many users are there, any data warehouses etc? What are the backup & restore policies?You might be surprised by the lack of information your company holds on its SQL databases � this could be a great place for you to start.

They never existed when I first started but now we use �runbooks� to keep details of each server and its databases, with all the necessary details & log information etc. This allows you to have a quick reference that you can look up when required.Even if you just jot down as much detail on the databases as you can to start with until you become more familiar with them.If, like I do, you work in an environment with a lot of varying systems, a lot different hardware, software platforms, database types, database versions� it�s quite useful � not just for newbies!

Secondly � watch. This is of more benefit to those of you who will be working amongst a team or with a mentor. Watch what your peers do, ask to get involved or observe if they have a particular task you are unfamiliar with.This is probably the most useful thing I did as a newbie.

Also document. I used to watch my peers and make notes along the way and then document the procedures. My organisation wasn�t too good with documentation when I first arrived. (this has improved somewhat over the years though!) A good example here is to delete or mimic corruption of a DB and then test the recovery techniques (in a test environment first of course !)By documenting the steps in the recovery, it highlights any part of the task you don�t fully understood, so you can then ask questions afterwards. Once you have compiled your documentation, you can then go and redo the test yourself, following your notes� this has proved very valuable in certain circumstances in my time as a DBA, it also gave me good practice of backup and recovery techniques. I still have the documents and use them regularly.

The learning element is an important part of the process, �how, where and what� to learn.

So how do you learn?

A very important trait is the ability to learn on your own. You can become a successful DBA by attending courses and learning from others, but in most organisations, there are few other database professionals, sometimes just one or two. You need to be able to pick up a book or magazine and browse a web site or two to learn by reading and experimenting. At some point, you'll be the expert in your team, and there won't be anyone there for you to ask questions � you'll just have to find the answer yourself. In fact, at some point, the rest of your team will be asking you how to do things.I�ve already highlighted one way with the documentation, and this also includes the important element of practice.

Practice, practice, practice. It can�t be iterated enough.Get access to a test server or test database and try things out, tinker.

Don�t worry if you don�t always get it right first time. That�s what learning is all about. Breaking a few things, sometimes is the only way to really learn something. And trust me you probably will get to break something in the early days!

You can guarantee that breaking something, and having to work to put it right, is one way of making sure you don�t do it again!DISCLAIMER: Don�t go out of here and trash your prod systems then say �Justin told me to do it!�

Get signed up on some training courses. Although hands on training is very effective, you also need the theory to back it up. You need to be able to understand the �whys� of what you are doing.I was very fortunate when I was starting out to be sent on the MCDBA track of courses for SQL Server 2000 (and further down the line SQL 2005)Intensive courses that covered the theory, but was also very hands on. And on courses you�re amongst other newbies with their own experiences to share etcGuaranteed, when I returned from a course I got straight onto a test server to put the theory into practice.

Get CertifiedI 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 forced 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. A great way of revising for the exams to perform hands-on, real-life scenarios on your test (& sometimes production) kit.

Take some time out to read - books, websites, and papers whatever. I�ve named some good examples of these later in the article.

Some companies may implement a mentoring program, if not use your peers.

Now that I�ve described a few ways in how to learn, the next question is what do you need to learn? So what does a Newbie need to worry about?(But how do you know, what you don�t know??)

Newbies need to learn the basics to form a level of knowledge on which to build.What has worked well for me the last few years is to firstly try and gain a broad understanding of all areas of DBA work, without going into too much detail, and without trying to specialise.I've also tended to learn on a 'need to know' basis.

Here's what I would recommend as a starting point:
1) Learn the structure of an SQL database.Know the different 'parts' that make up a database, and what each of them does.What are indexes and how do the benefit your DB, what are Stored Procedures & how are the users configured etc?


2) Learn how the different parts work together.Know the different processes that exist and what they do.What are SQL Jobs, what does DTS allow you to do?
3) Learn the concepts of backup and recovery.Full, Differential & transaction log backups? Attaching/Detaching databases?

Once you have a good grounding in the above areas, you will be able to build on your knowledge.Knowing how things are supposed to work will also make it easier to troubleshoot when things don't work.Think about what you don�t need to learn just yet � things your company may not be using, Reporting Services, Replication, SQL Clustering etc.If you try and take in too much it won�t stick or will get jumbled up.Too much information at once can be a bad thing, it can result in Newbie overload.

Newbie overload is a technical term for when your brain has turned to mush!A symptom of this is having to remember T-SQL syntax on a regular basis!

Along with everything you learn along the way about the technology, it is vital that you also learn the business. As a DBA I am currently responsible for the company's most intimate data, so it is important that the people who trust me with that data believe I understand how important it is to the organisation.

There is no better way to become a good DBA than to thoroughly understand the business. Or at least attempt to understand the business!

These are some of the places a Newbie can go to get help.

Peers � Use people you work with.If you�re stuck, ask a colleague to explain it, or verify your decision.

There are many books out there, all aimed at different levels and covering different areas.

And from personal experience, I would recommend SQL Server�s very own Books Online as a must have reference point.

While reading books is one of the best ways to learn much of the material you need to know, it is only one way to learn more about SQL Server. Since you are reading this article at a website, you already know that websites on SQL Server often include much content that can help you along your path of becoming a master DBA. Some of my favourites include:

www.gre-sql-solutions.com
www.sqlservercentral.com
www.sqlteam.com
and as you can imagine, Microsoft�s website has thousands of web pages devoted solely to SQL Server.

Other users are likely to have come across the same problem.On these sites there are searchable archives, helpful scripts and articles.

Blogs � the new thing. Reading blogs is a good way of picking up new �hints and tips�, but be warned, they can be highly addictive!

So we�ve looked at where to get help. Now we need to look at how to use these resources to get help.

The key to getting help is to learn how to help yourself first.Only then will people be willing to help you.

It is not true that more experienced users do not like to help Newbies. In fact it is quite the opposite.What you will find though is that there is a lack of tolerance towards Newbies who do not help themselves.

Once you are familiar with your systems, there are a few things you can look at straight away.

When I started in my DBA role, most of the sa passwords were still blank, despite those databases having been in place for 12 month!

If you can�t find any of the documentation you are looking for, produce it. This will also help you learn.

If in doubt � ask!

You will always have something to learn, and there will always be something new to you. New versions of SQL Server always come with �new features�. I haven�t even begun to start looking at what new functionality SQL Server 2008 brings yet.

Even DBAs with 10/15 years experience are continually learning!You need to have confidence in yourself and believe that you can do it. Remember everybody has started out as a Newbie.

Being a DBA is, without trying to scare you away, a highly responsible job where one false move can cause you, at best, a lot of explaining or a lot worse.

Here are some tips for what not to do as DBA � Newbie or not!

Rebuild an index in working hours
This will hit disk I/O very heavily. It is rarely useful to do this during normal working hours, so always schedule it for the evening or overnight - that is, during the period of lowest user activity. Difficult if you work in a 24/7 environment like myself.

Stopping the database engine without warning
Why? Lots of frustrated users and a telephone (helpdesk or yours) that won't stop ringing. Trust me I�ve been here � inadvertently shutting down database servers without informing the application users is a cardinal sin!

Performing a service pack upgrade during working hours
Usually this involves re-starting the core database engine. Don't do it, again it'll annoy many people. And besides that�s what overtime is for.

Running test queries against live servers
Do you really know how long they'll run for or how much disk I/O they will demand? I thought not! Again, past experience has led me to be extremely cautious in this department.

Being arrogant towards other teams in the department
Why? A few can be a complete pain, but explaining to them the issues and trying to work towards a good working compromise is usually more productive than treating them unsympathetically. Likewise the helpdesk guys - you need each other. Foster good relationships with your work colleagues, in the long term it pays dividends.

Backing up during working hours
Again it's all about disk I/O. It serves the backup or it serves your users. If you have to do it, look at differentials or transaction log backups: they take less time and reduce dropped connections as a result. I�ve recently had to change from full to differential backups because of space restrictions too. Alternatively, monitor the server and talk to your users/tape guys about the best time to perform one - but only if you really have to.

Executing patches/updates against live data
You are kidding, right? At the very least, test it against a live copy, and backup the live database before you apply it. And if possible have a regression script which will allow you to back out the updates if reverting to a backup is not possible. In my experience when users say they have confirmed and tested everything is ok � they haven�t really, give it 3/4 days later � they�ll spot something else!

Not securing your database servers
Get clued up on security. Your organisation may have its own Information Security Officers like mine; define user roles and password retention policies etc

Dropping a live database and the effect on your career
If you only engage your brain to do one thing as a DBA, make sure it kicks off extremely load alarm bells whenever you issue a DROP command or click the DELETE button in the GUI.

Good Luck�������.. But above all enjoy your work.

Signup to the GRE newsletter to keep up to date with the latest developments on the site and in the SQL Server world



Enter your E-mail Address
Enter your First Name (optional)
Then

Don't worry -- your e-mail address is totally secure.
I promise to use it only to send you GRE Newsletter.



footer for Becoming a DBA page