Recently I got to a stage where I leveraged Databricks to the best of my ability to join couple of CSV files together, play around some aggregations and then output it back to a different mount point ( based on Azure Storage) as a parquet file, I decided that I actually wanted to move this data into Azure SQL DB, which you may want to do one day.
Wouldn’t it be nice if we could access one main dashboard / report that pulls in information from many tools such as security centre, SQL advisor and cost management tools? Well you can, thus giving you a focal point to implement best practices, called Azure Advisor. This is not specifically for Azure SQL Database, you can leverage this for most resources within Azure. Later in this blog post you see that I will use it as a focal point for my database infrastructure in Azure.
In the Azure portal under services look for “advisor”
Do you enable this setting to allow automatic tuning to care of all your performance needs? Well not ALL your needs, more so:
- CREATE INDEX
- DROP INDEX
- FORCE LAST GOOD PLAN
Would you like to troubleshoot a deadlock in Azure SQL Database? To do this you probably will be after the deadlock graph. So does this mean that you need to setup your own extended event session? No, it doesn’t.
The Azure SQL Database service triggers an automatic failover after a failure is detected and the grace period has expired. What is the grace period? You can find this setting when building a failover group.
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).