If you missed the earlier installments, check out part 1 and/or part 2.
Getting Proactive
SQL Server is a large product and it’s getting bigger every day. Within it we have engine performance, query tuning, encryption, disaster recovery, report writing, data analysis, ETL processing…the list is a lot like the Energizer Bunny in how long it is. Trying to know all of that is pretty much impossible, so the database administrators who truly excel in the field become experts on a certain area of SQL Server and rely on their SQL family to help with the areas they may not know so well.
It’s hard to do, because in our jobs we’re usually only one of a couple folks who do what we’re do and we are expected to handle whatever gets thrown at us. I typically have to touch 4-5 distinctly different areas of our discipline just to fight the fires of the day. Like all fires, they need to be solved quickly. I can’t spend a lot of focused time learning about those different areas, because the system can’t be down or running slowly.
This, of course, ends up being a very reactive approach to learning. We only learn what we need in order to solve the problem at hand, then move on to the next one. Even then, we usually don’t learn much, just copy a script or grab a job, verify that it won’t break anything, then implement and get going. It’s continually preached (rightfully so!) that managing our databases in a reactive fashion is a recipe for disasters, all-nighters, and RGE’s, why do we think it would be any different with our education?
The challenge to myself is to stop being reactive in my learning. While it’s cool to be like a sponge in a sink, soaking up whatever is available, I’m only able to scratch the surface of whatever happens to be the topic du jour. To do that I need to take a discipline within SQL Server, focus on it, and make it my own.
Focus, Daniel-san!
Unfortunately, there’s no crane kick or leg sweep that is the magic key to my DBA success. Any number of areas would be valuable, I just have to pick one. My decision, which really only came to me in the last month, is to focus on SQL Server monitoring. The reasons are simple:
- In order to have the most stable environment, you need to know what’s going on in your environment. To do this, you need established baselines and systems to monitor your environment.
- To stop problems before they become serious, you need to have systems in place to watch for issues and deviance in your operations.
- You can’t start corrective action, such as adding hardware resources or query tuning, without first understanding the problem. Proper monitoring will give you the signposts to indicate what your problem is.
- If you want to impress the boss, the easiest way is to create reports and display the data on your environment and how it is changing. While I tend to think that doing your job well is the best way to impress the boss, your boss may not always understand how good of a job your doing unless you show him the data.
Over the next year, much of this blog will be about researching and implementing monitoring. It will include planning elements such as service level agreements (SLAs), third party monitoring tools, and reporting queries, along with other items as I come across them. Hopefully it will become more than just my brain dump area, but it might not. Either way, you should be able to follow along with the solutions and methodologies I develop and learn along with me.
Look out 2012, it’s gonna be a wild ride!