For some reason I have friends / colleagues telling me that when scaling (up and down for this example) that no downtime occurs. Well, not only does Microsoft documentation say differently, I will show it. So let’s test it out. Before the practical test, this is the official stance. “There is a switch over period where connectivity is lost to the database for a short amount of time, which can be mitigated using retry logic”.
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:
I think many have covered how you should backup your SQL Server database to Azure storage (also known as backup to URL) but what about restoring? Lets assume you have setup backups and they are working, this is what I usually do.
I get asked quite a bit about my thoughts on the impact Cloud computing has on a DBA role. Still in 2019, I get people say oh it’s the death, will you be made redundant? Are you worried? Simply put… No.
Let’s get straight to the point. From official documentation it states that “To secure your storage account, you should first configure a rule to deny access to traffic from all networks (including internet traffic) by default. Then, you should configure rules that grant access to traffic from specific vnets. This configuration enables you to build a secure network boundary for your applications”.
Navigate to your storage account, what is the default setting? It is shown below.
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 am not sure when this became available but for Azure SQL Database 150 compatibility level is now available. Last time I created a database few weeks ago, only level 140 ( SQL Server 2017) was available so I think it is a recent thing.
Upon some testing, if you create a new Azure SQL Database by default it is 150 as per the screen shot below (from the script action command)
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.
