Degree Seeker Week at SQL University, Extra Credit
Welcome back to Degree Seeker Week at SQL University. If you have returned for this extra credit session, you are trully an eager learner. I’m your guest professor for this course and today I will be presenting a lesson on non-SQL Server skills that will make you a better DBA and to what certifications those skills can roll up. Most DBA's perform other duties from time to time. Some of us find ourselves doing other duties more often than our DBA duties. In fact, one of the reasons I left my first DBA position is because I was spending more than 85% of my time perofrming other duties.
Although it was by no means the ideal situation for developing a career as a DBA, it did help me develop other skills along the way. Even today, I am a big believer in a DBA with additional skills. There are a couple of ways this can really help you. for one, it can speed up resolution for common tasks. Secondly, SQL Server depends so heavily on the external components of the system, that it trully takes someone that understands all components to some degree to get them to work optimally. I'll get into some examples below.
Hopefully you read the previous lessons. If not, I encourage to read them before continuing on.
As I mentioned above, one of the reasons that non-SQL Server skills are important is that it can speed up resolution of common tasks. Think of a scenario where you need something configured or fixed for SQL Server. If you have to engage other team members or other teams to get these common tasks performed, it slows down the process. The other reason is that someone with an understanding of how the other components of the system affect SQL Server will make better decisions about how to configure the system. I'll show you an example of each of these below.
We had an issue with one of our servers where the SAN was suddenly performing very bad. Throughput appeared almost as if it had been cut in half. We do not have access to the SAN, so we had to contact the Data Center Operations team to investigate. This request goes to their Tier 1 support guys who then have to escalate it to the Storage Utility Operations team. Before they can escalate to the SU Ops team, they have to first ensure that certain actions have been performed including making sure that the SAN Kit is at the current prescribed level. As it turns out, the SAN Kit and Emulex drivers were not up to date. As a result, DC Ops required that we supply them with a 4 hour downtime window so that they could update the SAN Kit and Emulex drivers.
The operations engineer informed DC Ops that he would have to contact the business owners of the application for a downtime request because it is a production server. At this point, I intervened. I told my colleague to tell business that we would only need to reboot the server one time, and that would be it. I updated the SAN Kit and HBA drivers myself, rebooted the server, and then replied back to DC Ops that we upgraded the SAN Kit and drivers ourselves and asked them to proceed with escalating to SU Ops. This saved us nearly 4 hours of waiting for the escalation to occur not to mention that it would have all been production downtime.
I followed this up by documenting for the team how to check the SAN Kit version and HBA driver version on the servers and where to check on the SU Ops website to see which level they should be at. It further documented how to upgrade the San Kit and HBA driver version and to do this before engaging DC Ops to minimize the turnaround time for an escalation request.
I was contacted by a colleague one day regarding the SAN configuration for the new application to which he had recently been assigned. They were preparing the production environment for the upcoming release to production. They were planning to implement failover clustering on a their own dedicated SAN. They even had their own SAN engineer for this application (no escalations to SU Ops via DC Ops for them). The problem was that neither the SAN engineer nor the Operations engineer knew enough about SQL Server's implementation of clustering to know exactly how to set up the drives for SQL Server. The SAN engineer thought he needed to present duplicate drives to each node of the SAN and neither engineer was sure about how big the quorum drive should be. In most points where their opinions differed, one of them was right, butneither one of them was right on every point.
They contacted me and told me what they wanted to do and what they thought was the right way to do it. I explained to them how SQL Server uses shared drives for a cluster and how the term active/active cluster is a misnomer and does not actually work the way the phrase implies. I guided them in making the right decisions for how to configure the SAN drives and helped them install clustering correctly. In this situation, if there had not been someone that knew enough about SQL Server failover clustering and SAN configurations to guide them, they would have ended up with a SAN configuration that was less than optimal.
Okay, enough lecturing. Let's get down to the meat. I'm going to list out the non-SQL Server skills of which I feel DBA's should have some level of understanding.The cool thing about a lot of these skills is that they roll up into certain non-SQL Server certificaitons.
Understanding Active Directory and Group Policy: helps you understand how SQL Server interacts with AD and how it is affected by Group Policy and domain permissions.
Understanding Windows Networking Infrastructure: helps you understand how SQL Server interacts with the network and its usage of TCP/IP and other networking protocols.
Understanding Windows Applications Infrastructure: helps you understand how SQL Server interacts with the OS layer and various applications within the Windows system such as web services.
Understanding how to install, configure, monitor, and update the Windows Server OS and the OS components: helps you understand how to configure the OS to ensure optimal operations of SQL Server.
Understanding Windows 2008 R2 Server Virtualization: helps you to effectively plan and implement a SQL Server consolidation effort.
Understanding how to configure and deploy SharePoint: helps you to understand how SharePoint uses SQL Server and how to configure SQL Server and SharePoint for optimal performance.