With SQL Managed Instance you will need to consider your configuration requirements in terms of core count for the CPU and memory, which we all know that the MIN/MAX settings for SQL is so important.
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.
When moving to a cloud model for your database stack no doubt you will be involved in a costing exercise. The good news is if you have Software Assurance with your existing licenses then expect some cost savings when moving to the cloud. You can save up to 70% cost when compared to a pay as you go model.
I always follow a contained user model when setting up users within my Azure SQL Database. I do this so the user in question has access to only specific database(s) and does not have a login to the server. It becomes even more apparent the importance of this when you design a solution based on failover groups.
When a failover occurs to the secondary, I want a pleasant experience for the user. With the contained user model, the user goes with the database. I don’t want to do admin work on the new primary (post failover). Let’s see.
There is a new (ish) interface to looking and configuring backups for your Azure SQL Database. This can be found within the settings section of the SQL Server.
As you can see, by default we have 7 days retention to allow for PITR – Point In Time Recovery, anything longer you will need to setup long term retention.
If you are building database solutions in Azure , using Azure SQL Database then you will know that you have a purchasing option decision to make. That being should you use a vCore model or DTU approach?
Have you ever wondered how your connection from outside of Azure to your database is handled? It is important to understand that there is a difference between route(s) from when connecting inside to that of outside of Azure.
There are many factors to consider when you are thinking about the move to Azure SQL Database (PaaS) – this could be single databases (provisioned compute or serverless) to elastic pools. Going through your head should be how many vCores do you want? What are the I/O requirements, do we need access to certain features like in-memory OLTP? But what about the memory requirements? This has always been a key requirement for SQL Server – those wonderful words – Min / Max memory settings.
How does this relate to Azure? Well it all depends on your vCore count and the generation of hardware we select during the build process.
There are currently 4 hardware generations ( each has its own purpose) :Gen4, Gen5, Fsv2-series and M-series. Each type has xGB per vCore up to a certain max. So it is important to remember this when sizing your workloads. (screen shot summarising is below) https://docs.microsoft.com/en-us/azure/azure-sql/database/service-tiers-vcore?tabs=azure-portal
So, for example I select a provisioned Azure SQL Database – 12 vCore on Gen 4 means I will have 84GB memory available for my workload.
If you have been following me or generally topics around Azure SQL Database and security you would know that it is important to leverage Advanced Data Security (ADS) for Azure SQL Database, if you remember this meant having tools such as advanced threat protection, vulnerability scans at your finger tips.