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?
I’ve written few (most of my) posts about running SQL Server, and very often about running it in Azure. While Azure is absolutely the best cloud platform for SQL Server, it is also an excellent platform for plenty of other database workloads. In short: “If it runs on a server or a virtual machine, you can move it to the Azure.” However, I also feel that most blog posts should exceed tweets in length, which is why we’ll go a little deeper into this.
Not so deep, though, that we’d start discussing non-relational databases (those can go to CosmosDB).
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.
It’s always a great time to write about security, so let’s go with this topic today. One of the main reasons I love public cloud is, that beyond nice offering for databases, they also provide great features around security.
One of these features, and the topic of this post, is Azure Defender for SQL. While Azure Defender has been around for a while, it was only very recently it was also made available for SQL Servers running on VMs.
So what is Azure Defender for SQL and why you should be enabling this today, if you already haven’t?
Let’s continue with the storage performance topic a bit further. One thing that sometimes can be confusing is the storage performance with SQL Server Managed Instances. The reason for confusion comes from having two separate performance tiers (General Purpose and Business Critical), with different method of managing the IO performance.
In General Purpose the method to get better performance is to go with bigger files. In Business Critical the better performance comes with cost, by adding more vCores to your Managed Instance. There are also a couple other details to keep in mind, when figuring out what exactly you need for your workloads.
I am a huge fan of managed database services, no matter which cloud platform they’re running on. The simple reason is that I am not a huge fan of managing the automation for the basic things like backups, patching and high availability myself anymore. There is a trade-off though when you’re using someone else’s automation to manage your environments, the price you pay is the limited visibility of what’s happening underneath the covers.
I was reminded about this the other day as I was attempting to restore a database from one Managed Instance to another, a pretty standard thing to do for certain, and was facing an issue with it. In the end the problem itself was easy to fix but difficult to figure out.
Lately I’ve been spending lot of time outside my natural habitat, Azure, and I’ve entered the AWS frontier. Because of this I decided to write down some of my experiences about how the SQL Server deployments between these two cloud platforms compare to each other. AWS has been around longer than Azure by few years and is the largest of all the public cloud platforms, and I believe, that even today it’s hosting greater number of Windows based VMs than Azure.
With Azure Microsoft had the opposite approach to hosting SQL Server databases, and rather than starting with VMs they first released Azure SQL Database and then later on Microsoft added support for SQL Servers in VMs to attract more of the existing workloads into Azure. Noting the different approaches, let’s then take a look at how they compare when it comes to SQL Server deployments.