We’re about to undertake a mission to move some databases to a PaaS environment from a SQL Server database server. Sizing is proving to be more art than science thus far…
I think sometimes that SQL Server folks invented the consulting response of “it depends.” It’s the catch-all response when someone asks “how long…” or “how much…” or “why is it acting like this?!”
It comes back to the fact that there’s not a simple answer in so many cases. You’d think we’d learn by now how to formulate better responses and get down to more science and less “it depends” type answers. I realize that it truly does depend on many factors, but it seems to me that some of this, at least SOME of it, should be answerable based on fact and usage and such.
As we go through the process of sizing a SQL Server instance and getting things ready to cut over, we’re finding that we’re completely and entirely back in the “it depends” space.
What size instance do we need? What type of instance? Do you want to have some in SQL Server and some in other engines???
Sheesh.
This application has been around for nearly a decade. We have historical usage data for that time. We’ve been dutifully logging it, analyzing it and using it to predict growth. But we’re finding that that’s not enough to be absolutely sure. Most of the guidance has been along the lines of…
“well, based on that, and these factors, and the other things we’ve seen, you should be good to go with this type of instance… but we’ll deploy first and test. You can always grow or shrink the instance if we’re off by a bit.”
Off by a bit? With all sorts of usage and capacity and utlization information on-hand? Yep. It seems a little like the days as storage really started to get inexpensive. It was easy to talk with customers and explain that growth was no longer a big deal, really. Just add disk, or even new subsystems, and you were all set.
The cloud has brought some very similar discussions. If you get the sizing wrong, just increase the instance capacity – it’s a slider, what could possibly go wrong?
It all makes me sweat a bit, I must admit. We’re talking about moving production systems with particular maintenance window requirements and sketchy options for partial recovery if something goes wrong, which means if something DOES go wrong, it’s a big deal kind of recovery. This isn’t something I expected to go into guessing at *about* what we’d need.
I want facts, man! I want to run a script and have it consider the things going on and say “here’s what you need.”
Alas, we’re having to do our own. Our own tests, all of that – to make absolutely certain. Now the suggestions are coming in to “go high” and back off the power if it’s not needed, but at least you’ll have it to start in case something was missed.
Just makes your heart go pitter-patter.