When we built SQL ConstantCare® as a mentoring – not monitoring – product, I really meant the word mentoring.
A lot of us are loners – the only SQL Server person in the office. Nobody really understands what we’re doing, and … we’re not even sure we understand, either. We were self-taught, and we didn’t have anybody around to bounce ideas off of.
I wanted to build a mentoring service that acted as a peer to:
- Reviewed your database server configs
- Told you where your blind spots were
- Gave you personalized training recommendations on what to learn next
- If you didn’t have SQL Server problems, told you to move on with your day and focus on other stuff
- And most importantly, listened and discussed when you hit reply
Mentoring is a conversation.
Customers can hit reply to ask clarification questions about a recommendation, or tell me about extenuating circumstances. Maybe max memory is set to only half of the memory on the VM because you’re preparing to install another instance on there soon.
It’s a two-way street, though: sometimes customers are surprised that I would push back and say, “No, I’m not muting that alarm. You need to fix it, and here’s why, and I’m not going to send you further recommendations until you fix that first.” I’ve also had plenty of tough-love conversations where people thought they knew something, but were wildly incorrect. Examples:
- Lots of folks believed they didn’t ever need to run CHECKDB on read-only databases because they can’t possibly become corrupt – the data can’t be changing, right? It makes sense – until you realize that storage doesn’t obey your silly read-only rules.
- People weren’t bothering to back up system databases believing they’d never need to restore them. Ideally, that’s true – but in reality, folks have a nasty habit of sticking tables in databases where they’re not supposed to, especially when everyone’s a sysadmin. (Besides, those databases are tiny – just do it.)
- And no, frequent memory dumps will not go away on their own.
Some of my favorite value-providing moments are just telling stories of my own history – times when I’ve thought the same way the customer thought, and how I got burned. Telling those personal stories helps folks understand where the advice comes from – and helps get those recommendations implemented.
I don’t think we’ll ever be able to fully automate the process. People believe their situation is different – and sometimes it is – and they want to be able to have that conversation about why a particular recommendation really applies to them.
