Hi,
This is my third and last post dedicated to HADR solutions in Azure SQL Database, where I’ll introduce “Auto-failover groups“.
You can find the previous ones here:
So, first of all, what is Auto-failover groups?
Hi,
This is the second of three posts dedicated to HADR solutions in Azure SQL Database. In HADR in Azure SQL Database (Part I) I presented the “Scale out read-only Database” feature. In this one, I’ll talk about Active Geo-Replication and in HADR in Azure SQL Database (Part III), I’ll introduce “Auto-failover groups”.
So, first of all, what is Active Geo-Replication?
Hi,
AlwaysOn Availability Groups (AG) has been around since SQL Server 2012 and today it is widely used in HADR solutions. It also gives us the ability to have readable secondary replicas, allowing read-only access to the respective secondary databases. If you have read-intensive workloads (like reporting, ETL applications, etc.) you can have a significant performance benefit by simply directing those workloads to the secondary replicas.
In this post I’m assuming that you’re already familiar with this “old” feature so I’m not going to elaborate about it.
The thing is that AG is not present in Azure SQL Database (PaaS), so my purpose here is to show how to implement an HADR solution in Azure SQL Database, since we can’t use our well known (and beloved) AG and you’ll see that it’s actually pretty easy 😊
Hi there!
Recently I was involved in a project that aimed for the downsizing of the Pricing tiers in some Azure SQL Databases, in order to get a more cost effective solution. I’m going to tell a (true) story about a situation that happened with one of them, regarding a strange I/O usage up to 100% every now and then, with no apparent reason, after the downsizing took place. I’m also going to explain how I fixed it while keeping the database in the same tier, hence achieving a more cost effective solution with no impact in performance.
Continue reading “The “strange” case of high I/O usage in Azure SQL Database”
SQL Land 