When I was prepping for the PASS Summit last year, I wanted to unveil something awesome and free that would help you analyze your SQL Server's performance. I ended up building the Power BI Dashboard for DBAs, an easy way for you to visualize your server's wait stats. When we started building SQL ConstantCare®, our…
When we started designing SQL ConstantCare® (back before we had a name for it), I listed out the main components at the beginning of the design doc: The collector (which later became ConstantCare.exe) was the only piece that would run client-side. I wanted to keep end user support work to a bare minimum - if…
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.
In our behind-the-scenes posts about building SQL ConstantCare®, I've written about how we picked serverless architecture for the application layer, and how we picked AWS Aurora for the database layer. Hosting costs were a big driving factor in those decisions - so how has that worked out?
Presented for your enjoyment, here are our total SQL ConstantCare® hosting costs (including both production and development environments) from AWS Billing Explorer for a rolling 30-day period as of when I'm writing this post:
XML Delenda Est
Last week, I talked about how we're going to be collecting query plans from users who opt to have us do so (and only users who opt in! No surprises, here) by leveraging code we already have written in sp_BlitzCache, and how we're going to do the XML analysis on our end using a Real Programming Language®.
Coming Soon
In an upcoming release, we'll start collecting query plans from your servers. Since this may result in the transmission of PII, it will be opt-in only. We won't be getting this by default, because we don't want anyone to be uncomfortable with the level of data we're collecting from their servers. This is an important goal.
In SQL ConstantCare®, you send in your SQL Server's diagnostic data, our systems analyze it, and we email you a list of tasks you should perform to make your SQL Server faster and more reliable. Some recommendations are really straightforward: for example, hey, you should turn off Priority Boost. It's really easy to determine if Priority…
When Microsoft first talked about Query Store, I was wildly excited. It's basically a black box flight data recorder for SQL Server, tracking which queries run over time, how much work they do, and how their execution plans change.
And then it came out, and...hardly anybody used it.
When we first launched SQL ConstantCare®, the workflow was:
You sent in data about your SQL Servers daily
Our systems sent us (not you) recommendations on what to do
Once a week, we reviewed those recommendations, made sure they made sense, adapted them when necessary, and then forwarded 'em on to you
You know what my biggest regret is about sp_Blitz?
No unit tests.
The short story: if you drop an index on an indexed view, queries on the Always On Availability Groups replicas that point to that indexed view will cause memory dumps. The long story: to reproduce - AND DO NOT DO THIS IN PRODUCTION - on the primary, create a couple of tables, an indexed view,…
One of the fun things about building SQL ConstantCare® as a cloud-based service is that we can iterate fast, making improvements based on the data we find. We can assess the population as a whole, figure out what people are doing well, and look more closely at the rules they're struggling with.
What checks are everyone passing?
Let's look at a sample day from last week when 562 servers sent in data (out of the users who agreed to share their data to improve recommendations):
When we started building SQL ConstantCare®, one of my early decisions was to focus on a text-based interface. I wanted to just simply tell you what I'd do in your shoes. If users wanted to see more evidence behind the recommendations, I'd show it - but otherwise, I'd hold off and let them ask. The experience has…
I bet, dear reader, that this is the post you've been really curious about in my behind-the-scenes posts. Back in the post about the data we collect, you may remember that our initial goal was to analyze high-priority issues like missing backups or corruption check, priority boost on, offline NUMA nodes, etc. To do that,…
One of my favorite things about my job is being able to take the pulse of how real companies are managing their databases. I don't wanna be locked in an ivory tower, preaching down to you, dear reader, about how you should be doing five million things a day - when in reality, you're struggling to get an hour of real work done because you've got so many meetings.
When you wanna build something, how early do you let the public in? Where do you draw the lines with the features you absolutely have to have - versus the stuff you just want? Code is never really done. The lines are so blurry these days with labels like Alpha, Beta, Private Preview, Public Preview,…
Next up in my series of behind-the-scenes posts about our new SQL ConstantCare®, let's talk about the kinds of SQL Server diagnostic data we're gathering, why, and what data we're steering clear of for now. (Psst - read through to the end for a huge, crazy discount today, too.) We - you and I - are…
Our new SQL ConstantCare® is our first paid online service - it tells you what you should do next on your SQL Servers. I've written about the vision and the architecture design, and this week I'm continuing to share the behind-the-scenes planning.
When you buy it, how exactly should we charge you? There's a few options:
Our new SQL Constant Care® is an online service that analyzes your SQL Server's diagnostic data, then gives you personalized advice on what you should do to make your database app faster and more reliable. I blogged about the vision last week, and today let's talk about the things that drove our architecture decisions way back in 2015.
We're starting to roll out a new product, SQL ConstantCare®, and now that we've got over 50 customers, it's time to start sharing some behind-the-scenes details about what we've built. Over the next several Mondays, I'll be writing about the decisions we made along the way - architecture, packaging, pricing, support, and more. Lemme start…
