Traits of a DBA – Part One – The Technical Side

I’m going to deviate from my normal how-to topic related to SQL Server, and focus more on a touchy feely topic.  In this article and my next article I’ll be exploring the traits of a DBA.  Over the years I’ve been asked a number of times what does it take to become a DBA, or what kinds of traits should I be looking for when I am hiring a DBA.  Those traits can be summarized it two categories: Technical and Personal.  In this article I will discuss the technical traits a DBA should have, and in my next article I will discuss the valuable personal traits that make a person an excellent DBA.

DBA Technical Traits

Technical traits are those skills a person uses to perform a particular task that is technical in nature.  These technical tasks fall into a wide range of categories related to managing and maintaining a SQL Server environment.   Below is a list of those technical traits or skills that would be beneficial for a SQL Server DBA to understand.   This list is in no particular order.

1. Understands Backup/Recovery and Disaster Recovery:

Being able to recover from a corrupted database is a DBAs #1 priority.  A DBA needs to fully understand all the different possible backup and recovery options available for SQL Server, as well as how different backup options support different recovery strategies.  He also needs to work with the business users to verify the business requirements regarding how much data the users can afford to lose, if any.  Additionally the business users will also identify how long they can live without the system being available.  Understanding these requirement will help the DBA develop a backup/recovery to meet the business user requirements. A good DBA will periodically test out the backup and recovery process to ensure they can restore business data to meet the business data loss and recovery requirements for their organization.

2. Has a Toolkit:

By toolkit I mean they have a set of T-SQL scripts to perform different DBA related tasks.  This tool kit should contain little snippets of code that allows them to quickly diagnose a problem, or perform a particular task.   This toolkit of scripts should be organized by types of DBA activities, such as backups, index maintenance, performance tuning, capacity management, etc.  A good DBA will constantly be adding new scripts to his tool kit as he performs new tasks, uncovers new problems, or finds useful scripts that others have developed.  He will also know where to find free tools and scripts on the internet.   Why re-invite the wheel.  A good DBA will know when to leverage the scripts others have written to optimize his time and enhance his toolkit.

3. Knows Where to Find Help:

There is no DBA that knows everything.  We all need to look for help or advice once and a while.   Knowing where to look for advice is important.  Being able to quickly find a solution to a new problem is critical when a database or SQL Server instance is not performing as expected.   A good DBA will know how to search the web quickly to find an answer to an unknown problem.  They will also already know the good websites, and recognize the world renowned SQL Server experts that offer good advice, as well as know when to ignore bad advice.  I know it’s hard to believe but there is bad advice out there. 

4. Understand how to Use the Native SQL Server Performance Tools:

SQL Server doesn’t always perform well, therefore a DBA needs to know how to troubleshoot and monitor performance problems.  Today there are many third party performance monitoring tools that help a DBA with performance.  A DBA can quickly fall victim to not understanding the native tools that come with SQL Server to monitor performance, if all they use is third party tools.   While it is nice to have these third party tools to monitor performance, it is important for a DBA to understand the out-of-the-box native tools that come with SQL Server, such as SQL Server Profiler, Database Engine Tuning Advisor, Dynamic Management Views/Functions, system/extended Stored Procedures, Extended Events, etc.   A lot of these third party tools use these underlying native tools.  Therefore understanding these out-of-the box third party tools will enhance a DBA’s experience in using third party tools.

5. Research New Releases:

Nothing ever stays the same in the technology area, and SQL Server is no exception.  Every two or so years Microsoft will be releasing a new version of SQL Server with new features.  A DBA should be keeping up and following the changes being placed in new releases.  They can do this a number of ways.  One of the best ways is to get involved early and have a firsthand experience using upcoming releases of SQL Server by downloading and installing the Community Technical Previews (CTP’s) as they become available. A good DBA will be ahead of the learning curve and will be installing and testing the CTP’s as they become available.   This will allow them to understand the new features so they can make reasonable recommendations on how their organization can benefit from these new releases of SQL server.

6. Understands T-SQL Coding Best Practices:

A DBA should know how to write efficient code.  There are a lot of bad coding practices that cause poor performance.  A good DBA will understand and recognize those bad coding practices and know how to re-write the bad code to make it more efficient.  They will also document T-SQL coding best practices and share those practices with others within their organization.

7. Continually Learning:

SQL Server and all its components is a very large topic.  It is hard for a DBA to understand every aspect of SQL Server.   A DBA needs to continually be learning about how to manage SQL Server.  There are a number of ways to do this.  One can go to formal training.  But not all of us have that luxury, or can be away from the office for extended periods of time for formal training.   There are other ways to obtain training and most of it is free.  A good DBA will make sure he subscribes to some of the community sites that regularly post new tips and articles related to SQL Server.   Additionally he will seek out SQL Server user groups in his or her area, as well as attend regional free SQL Saturday events.

8. Database Security:

These days security is a hot topic.   A DBA should fully understand the different aspects of how to secure access to SQL Server databases.  They should understand the difference between Windows authentication and SQL Server authentication, and when you should use one over the other.  They should understand the difference between a SQL Server login and a database user.   They should understand how to use SQL Server and database roles to help manage security profiles for different types of users.   They should understand port and protocols for connecting to SQL Server.  Additionally they should understand how to encrypt a whole database, or just a column in the table, within a database, as well as understanding the issue around encrypting data.

9. Database Design:

One of the keys to a database performing well is the database design.  A DBA needs to understand the different aspects of database design.  They need to be able to understand the differences between a good design and a poor design.  They need to understand how foreign key constraints, primary keys, check constraints and using data types can help maintain the data integrity of a database and help with retrieving and updating data efficiently.

10. Index Design:

Indexing a database is a key aspect to allow the application to retrieve and update data quickly.  A DBA needs to know how indexes work.  They should know the difference between a clustered and non-clustered index, and how these indexes are physically stored.  A DBA should know how this indexes are used within executing plans.  They should understand how to find index usage statistics, and understand index fragmentation, as well as how to identify missing indexes.  They should know how to maintain indexes, and how important index statistics are to the query engine in SQL Server.

11. Capacity Monitoring and Planning:

SQL Server uses lots of different resources; CPU, Memory, I/O as well as disk space.  A DBA should understand how to monitor the usage of the different machine resources that SQL Server requires.  They should be able to understand how these resources are used over time, and use these historical usage numbers to plan for future capacity needs.   As part of this monitoring effort they should be able to predict when capacity will be a problem in the future and then take the necessary proactive steps to ensure there are no database outages due to capacity limitations. 

12. SQL Server Licensing

There are a number of different ways SQL Server can be licensed.  Additionally there are a number of different editions of SQL Server.  A DBA should understand the different licensing modes that are available for each edition of SQL Server.  They should be able to provide guidance on how to license SQL Server to minimize the total cost of ownership for SQL Server today, as well as how to leverage licensing options to minimize upgrade costs for future releases.

13. Automates Everything

There are many routine tasks a DBA should perform.  Some of these tasks are daily tasks, while others are weekly, monthly, or yearly tasks.  A good DBA will understand the need to leverage their time efficiently.  One way to do that is to build processes to automate some of these routine tasks.  By automating the routine tasks a DBA will have more time to focus on the one off issues that arise in managing a SQL Server environment.

How Many of these Traits do You Have?

Keep in mind this is not a complete list of traits, but only my view on those important traits a DBA should have.  How many of these traits do you have?  The more of these traits you have and excel at the more senior a DBA you are.  The key to being a successful DBA is working toward understanding as many aspects as possible related to how to manage and maintain a SQL Server environment, and to never stop learning.

See all articles by Greg Larsen

Gregory Larsen
Gregory Larsen
Gregory A. Larsen is a DBA at Washington State Department of Health (DOH). Greg is responsible for maintaining SQL Server and other database management software. Greg works with customers and developers to design and implement database changes, and solve database/application related problems. Greg builds homegrown solutions to simplify and streamline common database management tasks, such as capacity management.

Latest Articles