How to Grow Your SQL Server DBA Career
I am starting as a junior DBA and I'd like to know how I can grow my DBA career successfully down the road?
If you Google "How to be a successful DBA", you will see quite a few articles/blogs telling you what traits/habits you should cultivate to be a successful DBA. They are all correct in one way or another. As a DBA with 15+ years experience, I do have some other personal points that may be of help to you.
1. Script, Script and Script Everywhere
As a SQL Server DBA, one basic requirement is T-SQL skills. So try to do everything via T-SQL as much as possible, such as backup/restore, create/drop login/user accounts, writing views/SPs/triggers for either business or your own administration work, etc. Once you are an expert in T-SQL, you will find your work quality/efficiency skyrocketing while your burnout/tiredness stone-falling. Of course, sometimes, exceptions exist, like when creating SQL Server Agent Jobs, it may be more efficient to be done with SSMS than a script.
The importance of T-SQL knowledge and skills cannot be over-stated for a successful DBA, and those miracle T-SQL solutions to tough problems will make you outstanding in your career. I highly recommend reading everything Itzik Ben-Gan has published, including his articles, blogs, sessions and books.
2. Adopt The "Good Enough" Rule
In the real world, for almost everything we do, and no matter how long we have been working on it, there is always room for improvement. However, the benefit will diminish quickly as our tasks pile on. For example, if I want to create a database backup stored procedure, it can be as easy as just one line of code. However, we can also add various enhancements to make this stored procedure "unbelievably resilient to errors", like checking whether there is enough free disk space on the backup drive. Then we check whether the folder exists before starting. We can also check whether the user has permission to do the backup or check whether the database status is suitable for a backup, or whether the database exists, or whether the CPU/Disk IO performance is too high before the backup starts, etc. For all these valid condition checks, why bother if you will only encounter them once a year? In a worst case scenario, the backup fails. So what? Just fix the issue according to the error message, and then re-run the stored procedure, that's it.
The "Good Enough" rule will enhance the ROI on our time and the time saved can be used towards better-deserved areas. I think this is another way of applying the 80/20 rule in our work priorities or not over-architect a solution.
3. Be Conservative to New Features (except for T-SQL)
When learning a newly released feature, consider the opportunity cost. Numerous limitations (or pitfalls) in the first version of many new features also means a high cost of your time and energy spent on troubleshooting and debugging. In the end, the issue can be a bug that will be fixed in a later release. Yet, your time has already been spent and will never come back. I learned this lesson the hard way in my early DBA life and I was extremely disappointed at the time. For example, Notification Service was launched in SQL Server 2005 and was depreciated in SQL Server 2008.
So let any brand new features grow and mature for at least one version before committing yourself to learning them seriously.
4. Work in Different Environments
For junior DBAs, especially when you are in your 20's or early 30's, IMHO, you have to change your job to grow professionally. Different companies, especially in different industries have different database environments and also different database administration cultures. For example, in one company, high availability may be considered more important than performance, or performance more important than stability, or cost is more important than scalability, etc. While in another company, it is the opposite. Only after you go through several different administration cultures / teams will you be more mature in your visions and critical thinking toward your daily DBA work.
I have one example here, from time to time, I will see someone posting online some best practices, such as "never setting max degree of parallelism = 1". Indeed, even Microsoft has an article for this configuration. I think it is true in most cases, but using the word "never" is too extreme. Just as all Senior DBAs know, the best answer is always "It Depends" and it is justified to be so. In my case, setting the MAXDOP = 1 ensured performance stability, and stability was more important than performance from the user experience perspective (actually setting DOP > 1 did not generate any constant and reliable performance improvements in that SQL Server 2005 system). We verified this during a few month-long tests and finally decided to set MAXDOP=1. This is the preferred setting for our product. I guess if I never experienced this myself, I would simply follow those so-called "best practices", but after I experienced this case, I am more confident to say "It Depends".
With this said, I discourage frequent job changes because it is hard for you to fully digest a company's administration culture and make your own contribution to this culture if you do not stay long enough which is 3 years at a minimum to me.
5. Avoid Career ABC
ABC = Arrogance, Bureaucracy and Complacency (I borrowed this term from
annual letter 2015, on top of page 37).
To me, ABC is part of human nature and it grows out of long term success to the point that we start to ignore the changes around us and blindly believe what we know/practice is always right or better. Once ABC controls our thought and behavior, our career will be doomed. It is really hard to describe or evaluate ABC symptoms, but it is not hard to feel it. For example, when we say "I know it because I did it this way before". Yes, if you did it this way one month ago, it is totally fine. But if you did it 3 years ago in an older version of SQL Server, but you still try to do it that way today in a new version, you should ask yourself "Can there be new ways to do it?".". For example, with SQL Server 2012 if we still check SQL executions via SQL Trace, we may need to challenge ourselves by asking "How can we do this using Extended Events?".
The only way to fight career ABC is through learning so we know there is some other better way out there. Another way is through an intentional reminder of ourselves to be open-minded. Hopefully both of these techniques can prevent the ABCs from crawling into our daily decisions.
Managing one's career is somewhat like an art, different people may have different styles with different interests in different aspects. I personally try to maximize my time to benefit not only myself, but also my team and my employer.
You may read other similar articles below:
- Enhance Your SQL Server Career
- Managing SQL Server via Management Studio vs. TSQL Commands
- How to Become a SQL Server DBA
- SQL Server DBAs' Value to the Organization
- What are the key qualities for a SQL Server DBA?
- What does it mean to be a SQL Server DBA
- All SQL Server Professional Development Tips
About the author
View all my tips