An amazing blog post by Microsoft describing the idea of hot patching the database engine in Azure SQL Database to allow for minimal downtime when applying patches to SQL Server. We know that it is one of the benefits of Azure SQL Database but now we get some insight into how it’s done.
I want to do a quick summary post of the many different types of Azure SQL Database available and I am not talking about elastic pools, VMs etc, more so the singleton type.
A small but useful change has been made to the Azure Portal for Data Platform objects.
Using a Shared Access Signature (SAS) is usually the best way to control access rights to Azure storage resources (like a container for backups) without exposing the primary / secondary storage keys. It is based on a URI and this is what I want to look at today.
I always use the Azure Storage Explorer to build a SAS token. Let’s dig into what the different parts mean.
The below image is a beautiful picture, now it could be worse. The red line and the green line could peak at the same time and for a very long time or the blue line could behave the same as the red line and peak at the same time as the green line. Regardless of the situation the point of this blog post is when you are hitting your eDTU (elastic database transaction unit) limits within your elastic pools, tune your queries and do not knee jerk and just scale up (straightaway that is).
Do you want to identify the correct Service Tier and Compute Size ( was once known as performance level) for your Azure SQL Database? How would you go about it? Would you use the DTU (Database Transaction Unit) calculator? What about the new pricing model vCore? How would you translate you current on-premises workload to the cloud?
As Microsoft states “online clustered columnstore index build enables you to optimize and compress your data with minimal downtime without major blocking operations on the queries that are executing while you are transforming the data.”
Based on one of my favourite blog posts ever about unicorns, rainbows and online index operations (https://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-830-unicorns-rainbows-and-online-index-operations/) I wanted to show that using a command such as
Checking out the transaction log in Azure SQL Database. If you are curious like me, you will want to know about what your transaction log is doing in the cloud. The following queries have been tested and run okay within Azure SQL Database it gives you some great insight. First up, the classic log_reuse_wait_desc. You can’t exactly do much with this output, more so, just to fulfill curiosity.
I would like to share a link to my Azure SQL Database Stairway series hosted over at SQLServerCentral.
As stated on the website a stairway guide is a series focused on a single topic and is arranged into no more than a dozen easily-navigable tutorials that we call ‘steps’. Each step is the length of a typical magazine tutorial, and emphasizes practical, hands-on learning, with just enough background theory to help you understand the topic.
If you decide to use IP addresses to control what services have access to your Azure SQL Database, then understanding firewall rules are important. Within this important area you have the ability to create firewall rules that are scoped to the database or server level as shown below.