Before writing about pausing (and resuming) Azure SQL Data Warehouse (DW) it makes sense to discuss the architecture of this product. At a high level it involves a control node, a MPP (Massively Parallel Processing) engine compromising of compute nodes and storage. Perfectly summarised by this image.
Once again I would like to share with you an article I wrote about backing up (and restoring) a SQL Server database to Azure Blob Storage. In this article I write about some important concepts and show you the code needed to do this. This includes all the lovely components such as SQL Server credentials, secrets and SAS etc.
In my mind there are a couple of ways to move a database across resource groups. They vary from scripting to just using the Azure portal. I am going to use the Azure portal and do the following.
- Export a database in resource group X to a storage account Z.
- Import the file from the storage account Z into a database that is in resource group Y.
It’s just like a “backup and restore” strategy, all with the assumption that you are working within the same subscription ID.
Last year I wrote about Azure SQL Database extended events (https://blobeater.blog/2017/02/06/using-extended-events-in-azure/) and gave an example where I was capturing deadlocks via the ring buffer. Ever since then I wanted to do a follow-up post but using Azure storage as the target for my XEL files.
This is more complicated than using the ring buffer as the target and requires a couple of things:
- Azure storage account where you create a dedicated container for the files.
- SAS key.
- Database master key.
- Database scoped credential.