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.
While I work 100% with cloud based SQL Server deployments these days, my life is not all unicorns and PaaS services. Surprisingly (or not) enough, many of the environments in the cloud are still build on top of good, trusty virtual machines. Except that sometimes they’re not good or trusty. There are definitely some good reasons for deploying VM’s in the cloud, however some decisions on the architecture can prove to be a challenge in a long run.
In this post, I’ll share my experience from struggling with some of these decisions, and hopefully help some of you make better decisions out there. Let me share a woeful story about Storage Spaces Direct and Cluster Shared Volumes.
Sometimes I run into things in cloud that really just blow my mind away. Not that long ago I learned how you can give everyone in Azure, no matter what subscription or region they are in, an access to your database. And it was super easy too. It’s just one click to allow whole (Azure) world to start accessing your data.
Is this something I wanted to do, or would I recommend anyone to do it? No, not really. Also the documentation around this particular setting was less than great, so I decided to share what I learned.
Core responsibility of a DBA is to make sure that the databases they are responsible for are maintained properly. In a nutshell this usually means that you are taking backups of the data, checking the consistency of the databases and maintaining statistics and indexes. Performing these tasks gives the DBA the ability to provide the agreed SLAs for the system.
However the trade-off for doing all these tasks is that it requires some computing resources and it can sometimes impact the performance of the connecting applications, and through that the SLAs in a negative way.
In this post we’ll look at how to implement low impact database maintenance routines for environments that have large databases and are accessed 24/7 by the users.
Very recently I was working on a customer databases, when I more or less stumbled on a something I had not noticed before. Apparently at some point the latest version of SQL Server (I was working with Azure SQL DB) had a new security enhancement added into it called Feature Restrictions. As this was something I had not heard about before, I figured this would be a good opportunity to dig in and learn more about it.
Note: As I was finishing up this post to add links and such, I noticed that the official documentation from Microsoft regarding Feature Restrictions has completely vanished.
I just realized that it has been awhile since my last post, so I figured it’s time to do one before the end of the year. Last few months have been rather hectic with me migrating new workloads to Cloud as well as taking the time to visit PASS Summit 2019 to learn more about Microsoft Data Platform.
I also wanted to finish up my year of blogging by writing about a topic close to my heart, the evolution of the DBA role in the Cloud era. I did have a session about this topic in SQLSaturday Finland earlier this year and I will be doing a PASS Cloud Virtual Group presentation about it on January 16th.
In this post we’ll be looking at one of the Cloud technologies that have significant impact on the DBA role in the future, Platform-as-a-Service databases.