For the past 10 years or so, I’ve seen it occasionally come up in the discussions that DBA won’t be needed in the future. Originally, it started with the vendors claiming that their database systems are becoming self-tuning. Then the final nail in the coffin was to be the public cloud, which was also to be self-tuning. And it wouldn’t be just self-tuning, it would be infused with AI and tears of the DBAs to produce absolute magic.
While technology has definitely gone forward, nothing’s yet fully self-tuning, but cloud (especially the cloud bills) have certainly brought tears to the eyes of many DBAs, and occasional CFO. There are also signs, that rather clearly, point to the fact that the DBA role, and other IT specialist roles, aren’t dying away anytime soon either.
Public cloud is a really great place to put your application and database workloads. However, it’s not always clear how, exactly, that should happen. Some people talk about migrating, others about modernizing, a few mix everything together, and then there is a bunch of words that all start with the letter R.
In this post, based on my own experience, I’ll attempt to provide a clear differentiation between migration and modernization approaches, and how they map to a mysterious thing called the R-strategies. I will also introduce you to the third option called Midernization, or Moigration. Yeah, I know. The naming is a work-in-progress. Anyway, this is the option that no one recognizes, but almost everyone ends up doing it.
I spend a lot of my working time and effort to move on-premises databases to the cloud. When I am not doing that, I am most often spending it planning on how to do it more efficiently. While I think today almost everyone agrees with the benefits of going to the cloud, there are a couple of sentences I keep hearing over and over, when we’re planning to move databases to the cloud.
“We haven’t tested it with version X, and can’t guarantee that it works!”
“We only support SQL Server databases running in Virtual Machines”
That, good reader, is the typical sound of a commercial-off-the-shelf (COTS) application making it’s way, kicking and screaming, towards the public cloud. Considering how often I hear these two things been said, it’s easy to end up thinking that public clouds are full of burning wrecks of old applications. However, my own experience from having migrated plenty of SQL Server workloads is, that, about 100% of the time, I don’t have problems with versions or PaaS services (well, except that one time).
In this post, I’ll write about a single feature that can be used as to ensure that your database will be just fine, or even better, and then something about Managed Instances.
I previously wrote about Azure Defender for SQL that brings some remarkable security capabilities to your cloud-based SQL Server estates. And while you can also get some of that goodness to your on-premises servers, sometimes you just don’t need all that comprehensive solution. Well, I have good news for you. There’s also a quick and easy solution to do one off security checks against databases. And it only requires you to have Management Studio installed.
The feature is called “Vulnerability assessment for SQL Server”, and it’s available from version 2012 and onwards. Let’s take a look at how to use this great, and sometimes overlooked feature.
Every so often, Microsoft puts some extra into their SQL Server product, which doesn’t get as much time in the spotlight as it should. Nope, not talking about any of the great, new things that we got coming in with SQL Server 2022. Today’s post will be used to look at something called. SQL Assessment API. It’s not a very exciting name for a feature, but it definitely provides a new, exciting capability!
So, what exactly is the SQL Assessment API, and where, and how would you use it?
Not too long ago, Microsoft released The Final Service Pack for any version of SQL Server, as a part of their move to a Modern Servicing Model. This (and the fall time here in Finland) got me again thinking about the benefits of running your database workloads on PaaS over self-managed VMs. And one of the very real benefits is, that PaaS databases tend to be running with up-to-date versions. This is what you might have seen called as “evergreen” by Microsoft. When it comes to SQL Server running on VMs, well, these tend to be more of a “nevergreen” type of deployments. At best, they are somewhat yellow, but almost always never green.
And this isn’t an on-premises problem only, patching self-managed database services in the cloud is just as unpleasant as it is on-premises. But unlike death and taxes, continuously patching your operating system and the database software is something that you can avoid, without having to fear cosmic powers or a prison. It does require us to adjust our thinking on how we’re managing these systems, though: The databases aren’t the same as the virtual machines, and your virtual machines should be treated like they are disposable, not like pets.
I was just recently going through my backlog of podcasts and came across Data Exposed episode with Microsoft’s Pam Lahoud (@SQLGoddess on Twitter) about SQL Server VMs in Azure. Now, we have it from the official sources that one of the best VM sizes for SQL Server workloads is the Edsv4-series.
Incidentally, this is also one of my favorites for running SQL Server, and one that I often end up recommending due to missing monitoring data. Read further to find what exactly makes this VM series so good for many of the SQL Server workloads.