I like tools. I have a whole toolbox I like to have handy of SQL Server goodies and such. Including but not limited to:
SQL Sentry Plan Explorer – Plans on steroids, as I like to call it. If you want more detail and views on your execution plans, this is the tool that you want.
Qure Workload Analyzer – My favorite tool for slicing and dicing SQL Server trace files. I am trying to make the leap to extended events, but let’s face it – there are still a lot of us running older versions of SQL Server out there, and Trace is still a well-used tool for a lot of us.
SQL Search – One of RedGate’s free tools. Much handier than me trying to export all that messy object definition text to a table where I can search it. ;-)
There are a few more, too, but I’ll confine detailed discussions of specific tools to other posts. What I primarily wanted to talk about today was a thought I had while perusing a toolset that someone brought to my attention a couple of weeks ago. I won’t mention the company or toolset because that’s just not my style. (Praise publicly, criticize privately.) However, I had mixed feelings about some of the tools in that toolset. Here’s why:
Often, in the SQL Server community, we have given the advice, “Don’t reinvent the wheel.” What we mean by that is, if you’re looking to accomplish a specific task, it’s likely that someone else has accomplished that task in the past. You should take a look at their work/script/blog post and build on that, rather than trying to come up with your own solution. When I give that advice, I am usually inclined to add, “…unless your goal is to understand the wheel.” Do you want to understand how index maintenance really works? Write your own maintenance script. Do you want to understand the complexities of a simple database backup? Write a script to backup all the databases on a server, *especially* if they have different requirements. Just try writing a script that will effectively backup a group of databases when you have some in SIMPLE recovery, some in FULL, maybe some filegroup backups, allowing for multi-file backups, etc… You will definitely learn a lot about taking a backup that way.
However, if the goal is not to learn, but to accomplish a task, then I say you should take the shortest path between point A and point B. Don’t spend the time on learning, but getting things done. In many cases, your boss isn’t paying you to learn on the job. (Though it’s pretty awesome when they do.) Instead, you’re being paid to get things done. If that’s not motivation enough for you, think of it in terms of time management. XKCD gives a fantastic example of what gains you actually get by trying to improve processes, rather than just getting them done.
Some tools do a great job of abstracting complex tasks into simple point-and-click routines. SQL Search, mentioned above, is a great one. Before I knew things like that existed, I was writing stored procedures and scripts that would go database by database, (Hi, there sp_MSForEachDB!), running queries on system tables – or worse yet – running sp_helptext on procedures, functions, etc… and looking for a search term in the resultant text. Messy, messy method. After I learned about that particular tool, I retired my search scripts.
I’m starting to wonder if some tools do a little too much abstraction, though. I came across a tool today that moves jobs from one server to another. And another one that moves both databases *and* their logins. My initial thought was, “That’s a lot of background tasks this thing has to do. I wonder how it’s doing it?” My guess is:
- Run a backup of the database to a user specified location.
- Get the list of users in the database.
- Install, if necessary, and run sp_help_revlogin to extract the appropriate logins and their passwords.
- Create, if necessary, those logins on the destination server.
- Restore the database to the destination server, placing the files in the location the user specifies.
Now this is a guess on my part, since I haven’t actually opened the tool. But, that’s the simplest way I can think of to move a database and it’s associated users from point A to point B. However, I also think that the skills involved in such a plan are simple enough that the average DBA should be able to do so without a tool. In fact, I would expect it. This is where I get into a quandry. At what point should a DBA be expected to have the skills to accomplish a task without a particular tool handy? I would fear for the DBA who has accomplished a lot of his tasks with tools, without understanding the method or action behind them. What happens when that DBA gets a new job? It’s all too easy for me to imagine the following conversation:
Boss: “We need you to move this database from serverA to serverB.”
DBA: “OK, I’ll need the SuperDBMoverTool.”
Boss: “Why? Our old DBA did it all the time without that tool.”
DBA: “But that’s the tool that I used at my last job.”
Boss: “How much is it?”
DBA: “It’s x Dollars.”
Boss: “That’s too much. Figure it out.”
Is this realistic? I’m not sure. What I do know is that understanding *how* and *why* things work has served me much better over the years than understanding *what* things work. To what extent this is true for everyone, I don’t know. But, I’m learning, and I now tend to shy away from tools that doo too much for me, until I understand the background a bit. The tools I really like are the ones that give me a lot more information, rather than accomplish tasks for me. I’ll handle just about any task, provided I have or can get enough information to accomplish it.
Is this true for you?
Thanks for reading.