Welcome to 2018 and the first T-SQL Tuesday of the year. T-SQL Tuesday was created by Adam Mechanic (b|t) and this month is hosted by Arun Sirpal (b|t). The New Year is a time when people are making resolutions and setting new goals. What better T-SQL Tuesday topic for the New Year than discussing technical challenges that you overcame. It is usually those challenges that we have throughout our life that drive us to set new goals and resolutions.
Working with SQL Server Failover Clusters
During a job interview I had when making the leap from Junior DBA to Senior SQL DBA, one of the questions they asked was about working with clustered servers and SQL Server Failover Clustered instances. I had not worked with them before and said so during the interview. When I was offered the job, I knew I would have to work with clustered servers and they scared me to death. I started my new job as a lone DBA and I was responsible for four SQL Server Failover Clusters. No problem I said shaking in my sneakers.
When I arrived at the job, almost all of the SQL instances had not been updated in at least 6 months, some had not been updated in as long as two years. I had to bring everything up to date. That was the first order of business. I got everything up to date except the SQL Server Failover Cluster Instances. Working with a new technology for the first time can be scary and I was saving the best for last.
Step 1 – Research
The first thing I did to figure out SQL Server Failover Clusters was a lot of online research. I have always been pretty good at Google so I started in. I Googled and read, Googled and read, Googled and read. I dug into the articles and compared the information I was reading with the clustered servers we had in house. That is all well and good, but it is hard to ‘test’ clustered servers without letting others know that you are not knowledgeable in this area. I became very familiar with the SQL Server Failover Cluster Manager.
After a lot of reading, I hoped I had learned everything there is to know about SQL Server Failover Clusters. Hoped was the key word here. I had taken the reading part of my training as far as I could. I needed to move forward and talk to the people who were managing the Failover Clusters.
Step 2 – Work with VM and Windows team
The second part of my SQL Server Failover Cluster training was to work with the Windows and VM teams. They had both been part of team who set up the Clustered servers. There also had not been a SQL Server DBA on hand for a few months so they had managed the SQL instances until I came on board. I questioned a couple of the guys from the Windows team who had ‘managed’ the SQL Server instances in the absence of a DBA. They gave me a lot of good information and explained why the instances were in the state they were in and decisions that had been made prior to my arrival. They were very helpful and provided a lot of good information, probably because they were happy to have a SQL Server DBA in house and to remove that from their job description.
The SQL Server instances for our VM Console were located on the SQL Server Failover Clusters, so I worked with the VM team lead to understand the process to take when failing over the nodes in the cluster. He was very helpful and very patient with me. He walked me through the steps and reviewed the process I needed to take to fail over the SQL clusters.
Step 3 – Jump In
The next step was the biggest. I had to jump into SQL Server Failover Clustered Instances. One, two, three…go! Failing over the SQL instance is not hard but you still hold your breath waiting for everything to come up on the other node. With a lot of nervous energy flowing through me, I failed over my first SQL Server instance. It worked! That was so much easier than I ever expected. I was able to apply the most recent SQL Server Service Packs on all of the SQL Server Failover Cluster instances with no fallout. Everything worked smooth. Why was I so nervous?
Step 4 – Lessons Learned
One of the things that I was told when interviewing for this job was that everyone is not expected to know everything. If you don’t know something, ask. We work as a team to manage this data center and we help each other. Asking for help when you are not sure about something is preferred over running ahead full steam with no idea where you are going. I thought this would be a problem for me since I was the lone SQL DBA. Who else could I ask for help?
Some of our best resources are right under our nose. I had only been on the job for a few months and was working with a technology that I was not familiar or comfortable with. There were a couple of co-workers who had information that I needed and they were great at sharing that information and teaching me this new technology. Between reading documentation on SQL Server Failover Clusters and working with my co-workers, I was able to learn a new technology and successfully apply that knowledge.