First step login into the Azure portal and find SQL Managed Instance and click create. Yes you can find these tutorials all online but this is my thinking and opinions on some key areas.
After many years working with different “flavours” of SQL server in Azure from its true PaaS form to SQL server in AKS (Azure Kubernetes Service) it’s time to look at SQL Managed Instances – you will notice that I call it SQL MI.
Last week I created the below with a dummy database and is something that I will do against SQL server but this time that has a persistent volume claim.
So, the point in the previous blog post was to leverage Persistent Volume Claims – PVC for data when using SQL server that it is needed in a stateful manner. But what happens when we don’t create SQL server in AKS without a PVC?
Following on from my last post after creating AKS, I now want to work with SQL server. First step, load up Azure cloud shell.
In the last post we built an image of SQL server 2019 Linux hosted in Azure Container Instance for fast access to SQL server. So, your next question is probably, lets see some database action?
It is quite a common requirement to restore a copy of a database to the same Azure SQL server, you just issue a COPY OF command. What if you need to restore a copy to a different target Azure SQL server? Well its similar, just with a slight difference in that you need to refer back to the source server within your code.
Since SQL Server 2016 we could leverage Microsoft Azure to dynamically move “cold” portions of data away from on-premises storage for longer retention time periods. Whilst in theory being a great idea the cost was a blocker for some and with a cumbersome setup process. SQL Server 2019 addresses this by making the costs of storing the data in the cloud more competitive and making the setup more streamlined with the use of the Data Migration Assistant (DMA) tool and SSMS (SQL Server Management Studio).
Note: DMA tool replaces the older Upgrade Advisor tool. To install DMA please see the following link https://docs.microsoft.com/en-us/sql/dma/dma-overview?view=sql-server-ver15.
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.
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.