I’ve been noticing some interesting trends on inquiries at SSWUG.ORG – and perhaps even more intriguing, the sessions being proposed for the upcoming May Virtual Conference.
The difference, and the trends, seem to be edging toward debugging from the application, back. Rather than what I would often call SQL Server forward. It seems the assumption, to start the troubleshooting process, is that SQL Server is less likely to be the issue (and particularly in a cloud-hosted based environment) and people are tending to dig first into the applications.
It’s not absolute, of course. But where I was sort of in a “guilty until proven innocent” mode with a good number of environments (“check SQL Server, see what’s up”), now it’s “what can SQL Server tell us about what the application is having issues with?” Quite a different approach.
I think it points to the overall really solid implementation options we all have, and the history of SQL Server as a solid tool. But I’m not here (just) to extol the virtues of solid SQL Server. I wanted to mention a couple of things about SQL Server in the cloud that have stung us a few times (or at clients).
First, the throughput controls on the database engine have surprised us more than once. Specifically, when you set up your instance, one of the metrics is processing power (and even data transfer in some cases). These are often enforced, at the levels you purchase, in a rather absolute way. When you hit the limit, you can get timeouts, blocked connections, etc.
Where in the olde days (sounding dated here, but hang in there with me) your server would slow down and be less responsive, but it wouldn’t just outright block operations. With some hosted environments, and some database engines (this is my nice way of not committing – please check with your particular provider), you can hit the wall, hard.
We’ve seen cases where the fault, the recovery and generally the management of that limit is just managed in a fairly brutal way. Make sure you have a good grip on what you’re buying, but also what happens if you blow out the top.
Second, maintenance windows, and specifically the application of minor updates and in some cases, major updates. Make sure you know how, and when, updates and maintenance are performed. You typically have control over this. Don’t overlook it or just accept defaults if it doesn’t work for you. Make sure you know what may happen in those windows and what the process is for applying updates.
Troubleshooting is more complex than it may seem. Yes, things are stable, easy to run, easy to spin up, etc. But there are “the rest of the story” type items you want to make sure you have a good handle on too. It’s not even a “warning” but rather a friendly reminder.