My name is Mika Sutinen and I'm a Cloud DBA Practice Lead at the company called Nordcloud. I've been working in IT-industry for more than two decades, and I've spend most of my career working with SQL Server and other Microsoft technologies. In the past couple years I've been working on cloud only, on various types of projects and cloud platforms.
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.
In a past couple months I’ve seen this happen in a couple of different customers, so I thought I’d write a short post about the topic. While it’s easy to think that running SQL Server workloads on cloud VM’s is the same as running them on VM’s in an on-premises environment, this is typically not the case. There is one huge difference to cloud based VMs.
And as you are well aware, what databases commonly are used for, it’s storing data. But that data doesn’t exist in a limbo (though sometimes the cloud makes me wonder…) but in an actual storage device somewhere. In the on-premises world, if you’re running any type of serious workloads, that storage is going to be an expensive SAN device. In the cloud your storage is also very like coming from a super-expensive, state-of-the-art storage device, but that’s not the experience you’re going to get. Instead of having bandwidth measured in GB’s, you’re getting something that is measured in MB’s.
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.
One of the things I’ve learned over the years is, that sometimes the performance in cloud platforms can be unpredictable and you always need to expect the unexpected. Most of the times these issues are just minor annoyances, but they can certainly be confusing the first time you run into any of them.
A while back I had one of these experiences as I was working with moving databases from on premises datacenter to AWS using the native restore and backup capability in RDS. It’s a really nice feature giving you ability to easily move data in and out from the RDS, using familiar tools for DBAs. However this time I ran into a weirdest issue with the initial restore performance.