Solutions to age-old problems are often very hard to see, because of tradition, emotion, and plain old inertia. It takes a new perspective – sometimes, a visionary perspective – to see the issue clearly and to find a solution that’s better, easier, and kinder. You can just decide to be a visionary, but it’s just like any skill: it’s going to take a process and some practice.
In my house, we fought eternally about the toothpaste tube. We had different standards about how clean it should be, how important it was for the cap to be on, and so on. It was an ongoing, irritating, persistent problem, right up until we started buying individual toothpaste tubes for each of us.
It’s a small thing, but it was also absolutely visionary. Imagine how impactful it would be to solve ten of those ongoing, persistent problems in a data environment!
How to become a SQL visionary
Some folks have a natural (or even intuitive!) process of seeing problems for what they are and finding unique solutions. That’s an amazing skill, but it’s not necessary to be naturally or intuitively good. We can just work on it, step by step:
- Look for irritants.
- Define the real problem.
- Try a better solution.
- Find problems with that solution.
- Repeat from step 3 as needed.
Pretend that we’re on the data team at XYZcorp, and run through our first round of visionary practice.
Step 1: Actively look for irritants*
For a good week, keep a notebook (or sticky note, or OneNote) with you at work. Start writing down specific things: Anything personally irritating, anything that bothers those around you, and anything people complain about a lot.
At XYZcorp, we’ve taken some notes and talked to some folks. What we found is that the biggest irritant is how busy and rushed everything is. The SQL team never seems to get time for the big-ticket items…like preparing for that fall audit. Most people on the team complain about this, so we know it counts.
(*I mean things that bother you or others in business processes, standards, or thinking. I don’t mean Bob from Desktop Support, okay?)
Step 2: Define the real problem
What we say about the irritant isn’t always the actual problem. “Well, the problem is that YOU don’t know how to use a toothpaste tube!” No, the true problem was that the toothpaste users in my house had different standards for a shared resource.
So, XYZcorp’s SQL team is too rushed. But what’s the actual problem? There are probably several causes – the company culture, the development manager who likes to rush through projects, and so on – but we have to focus on the things that our team can control.
Let’s talk things out with our (hypothetical) team lead:
TL: Okay, so we’re always short on time. What’s actually taking up that time?
M: Tickets. Emergencies. A lot of it is checking on jobs and troubleshooting job failures.
TL: We’re manually checking on SQL Agent jobs?
M: Yeah, like we have jobs that run DBCC CheckDB, but we only get alerts if the job itself fails…not if it finds corruption.
TL: That’s……non-optimal.
M: Yep. And of course, sometimes when there are restarts or other issues, SQL Agent isn’t running on a server (or on six), and the jobs don’t fail, they just don’t run.
TL: That’s also a serious problem.
Jobs and job reporting should be as automated as possible, and right now they aren’t. When we dig down into the tickets and emergencies, we see the same theme: things that can be automated, that we’re doing manually instead. (The junior DBA is even running transaction log backups by hand…yeesh!)
Step 3: Try a better solution
The first solution might not be the best one available, and that’s fine. Never let “perfect” get in the way of “good”.
At XYZcorp, we have to implement some solutions immediately:
- Make sure DBA Jr. knows about job scheduling. Forbid them from running backups by hand ever again.
- Add a step to all CheckDB jobs to search the error log, and send an alert if it finds any corruption errors.
- Create and schedule a PowerShell script that checks the status of SQL Agent services throughout the environment, and alert on downed services.
That still leaves us with unsolved problems, but it’s much better than where we were before.
Step 4: Define any problems with that solution, and
Step 5: Repeat as needed
There are very few 100% perfect solutions in this imperfect world. But we can evaluate the solutions, and rate their shortcomings.
Before, we were rushed in part because SQL Agent jobs (and reporting) were under-automated. We’ve put in more automation: scheduling, automatic corruption alerts, and “SQL Agent down” checks. I find that I’m personally irritated to have to implement those corruption alerts on every single instance, and so I start looking for ways to improve that process.
And, so on.
Step N: Try an even better solution
Of course I picked examples that Minion Enterprise solves – M.E. has service alerts, checks for missing (not just failed) backups and CheckDB, smart alerts, and a lot more automation.
But of course, no DBA should have to wait for finance to approve this wildly important purchase. Start finding the problems and trying out solutions. The data world needs more visionaries.
Contact us to get a Minion Enterprise trial. Practice your data solving skills with a tool meant for SQL visionaries!