I am passionate about using Microsoft Technology to maximise business benefit. Specializing in the Data Platform – SQL server, Azure SQL DB, Azure SQL DW, elastic pools, managed instances etc.
So any questions/ feedback – please Get In Touch
Copyright © in accordance with the Copyright, Designs and Patents Act 1988. All rights reserved. You are free to use any of the content here for personal use but need permission to use it anywhere or by any means (electronic, mechanical, photocopying, recording or otherwise).
SQL Server 2019 is ready available for use, but before you download you should review the webinars, white papers and eBook available on the technology (definitely the eBook 😉 ).
You can find the eBook at the following link –
Yes you can still get execution plans for Azure SQL Database, you cannot get this from the Azure Portal so it is good to know for your tuning days. It is based on the same code you have probably run many times before. Lets get the plan handle and work through an example.
A way to enforce good practice and standards is by Azure Policy. As stated by Microsoft “Azure Policy is a service in Azure that you use to create, assign, and manage policies. These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements”. Pretty important stuff if you ask me.
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.
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.
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.
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.
In the previous blog post I did a quick overview building a SQL VM (imaged) in Azure. It is now time to clarify some backup techniques because it can get confusing.
At a high level there are 3 techniques.
- Automated backup.
- Azure backup for SQL VM (that’s what MS call it).
- Manual backup, for example backup to URL.
I prefer not setting up manual backups to storage accounts, I have done it, I just find it painful to setup/support/fix. So my choice would be automated backup vs “Azure backup” for SQL VM. What’s the difference?
Let’s create a virtual machine in Azure that has an imaged copy of SQL Server on it. I want to do this because down the line I want to show how you can setup automated backups to a storage account based on an IaaS extension, when I do that I will most likely talk about the different backup options because there are many.
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.