This is just a quick blog post to notify you about me speaking at Azure Bootcamp Bulgaria 2021. If you are interested in Azure deployments or some of the other sessions you can check out the schedule and register.
Azure SQL Databases is quite a big service and it is also one of the oldest. Because of these two there are a few architectural designs that you should be aware. Some of these are:
- with every SQL logical server there is a master database resource that is created. This resource is not directly managed but for example when you configure diagnostic settings on server level you need to configure those against the master database resource rather the SQL logical server
- The SKUs of Azure SQL Databases are mostly divided into DTU and vCore based. Among the vCore based we also have Hyperscale and Serverless variants. You can also have elastic pools for some SKUs and than the databases under those elastic pools inherit their SKUs. Not all Azure SQL SKUs support all of the features of the service. Some of the features that may not be available or have some limitations across different SKUs are:
- Zone redundancy
- Hybrid benefit
- Read replicas
- Failover Group support – for example not supported on Hyperscale SKUs and supported on Serverless SKUs only auto pause delay is disabled
- Geo replication
- Short term backup
- Long term backup
Among these we also have Datawarehouses (now known as Azure Synapse Analytics) which underneath are the same resource as Azure SQL databases but have completely different options.
Recently on Microsoft Q&A there was question on how you can control Azure SQL Firewall rule in a way that only certain IP addresses are allowed to be configured. Naturally I gave general answer that you can do that via Azure Policy. Initially I didn’t give the person an actual policy as I haven’t done such before. Of course creating Azure Policy definition can be challenging so the person asked him if I can provide him with example.
AzureDiagnstics table is used by many Azure Services when you send diagnostic logs thus the 500 column limit that Microsoft is trying to fix for that table. When you hit that limit there is currently the described workaround but let’s say you have used one service that was sending logs and you no longer use that service. The logs associated with that service are yet to purged but you also want to clean up any custom columns that the service was using. That way you can free some slots for new custom columns for new services that will send logs to AzureDiagnostics table. Of course you can delete the custom column from Log Analytics blade but you do not want to delete a custom column that is also used by another service. This will be a short blog post that I will show you how to find if custom column is used by more than one service by using Kusto query language.
Azure Policy has a unique feature compared to other competitors when it comes to evaluating Azure Resources. As Azure Policy is built along Azure Resource Manager (ARM) policies are in effect right away. This means if you have policy that blocks location and you try to deploy to that location a resource you will not be able to. The effect is enforced no matter if you use ARM Template Deployments, Portal, PowerShell, CLI, SDK or just plain old REST API. Of course on existing resources the policies are evaluated once 24 hours but you can of course trigger on-demand evaluation scan. The time that the scan will run depends on how many resources the policy will need to evaluate. Obviously policies that evaluate many resources (such as policies for tags or locations) will take longer (also dependable on the number of resources for the applied scope).