Quick video showing you how to failover your Azure SQL Database between your primary and secondary location.
Ok, so Azure SQL doesn’t really have its own error log based somewhere on a machine within \\MSSQL\Log directory but the closest thing you will get is a system catalog view called sys.event_log which is very useful. It will get you information about all sort of event types such as:
- Successful connections
- Failed connections
- Throttling issues
- Blocked by firewall attempts
- Connection termination
This is by no means a complete list but more of a personal list of features I have seen not setup or just missed out when looking at Azure SQL DB. After reading, not only will I hope that you agree but it may provoke you to double check your setups.
Sometimes you may not want to flip over to the Azure portal to grab the database size, such as the used space below.
I am sure many missed the updates to Azure SQL Database SLA (Service Level Agreement). It used to be 99.99% across all tiers but split between two different high-availability architectural models. Basic, Standard and General Purpose tiers had its own model and the Premium / Business Critical tiers had a different one.
I had a good question from JP via a comment on my blog about whether you can use the MAXDOP query hint in Azure SQL Database. The answer? Yes.
A quick 2 minute upload (with sound, my voice) showing you how easy it is to create an Azure SQL Database using the Azure portal and then using SSMS (SQL Server Management Studio) to connect to it.
The infamous setting that we all know and love – MAXDOP. Did you know that you can actually control MAXDOP when using Azure SQL Database? You might not be able to tinker with the Cost Threshold for Parallelism setting but you sure can with MAXDOP.
Naturally the cost of Azure SQL Database directly relates to what tier and performance level you are using. Starting from the least expensive basic database to the more premium ones I thought it would be worthwhile capturing the costs (GBP) across all tiers.
Let’s start off with a quick overview of SQL Server versions and compatibility levels.
- 100 = SQL Server 2008 and Azure SQL Database
- 110 = SQL Server 2012 and Azure SQL Database
- 120 = SQL Server 2014 and Azure SQL Database
- 130 = SQL Server 2016 and Azure SQL Database
- 140 = SQL Server 2017 and Azure SQL Database
So with SQL Server 2017 now available to the public what level is a newly created Azure SQL Database set at?