I thought being an Azure Data/Database blogger I would share some amazing content from Microsoft, an Azure SQL Fundamentals learning path.
Can you improve on the baseline (service level agreement) SLA of 99.99 % for Azure SQL Database? How can you get 99.995% as shown below, from official Microsoft documentation?
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.
You should always seriously consider enabling this feature. This is part of the ADS suite – Advanced Data Security and I will show you how good this pro-active service is.
Question, can you take a built-in backup ( a backup that Microsoft takes as part of the service) and create a new database from it on a NEW server in a different region?
Let’s find out.
Have you realised the changes Microsoft have made to the firewall and networking section of Azure SQL Database? I found this quite stealthy and took me by surprise. I did encounter an edge case scenario where it lead to issues once I made some tweaks but that was a rare thing.
A quick post today about moving across database tiers. As you can see below I have a General Purpose Serverless Gen 5 1 vCore database (currently paused). Can I move this back to a DTU based model?
So you have many databases in Azure, you accidentally deleted one which can happen and has happened to me because in my situation they had very similar naming conventions with a number different at the end of the database name.
Question is, how can you protect yourself from this? Answer. Locks.
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
For some reason I have friends / colleagues telling me that when scaling (up and down for this example) that no downtime occurs. Well, not only does Microsoft documentation say differently, I will show it. So let’s test it out. Before the practical test, this is the official stance. “There is a switch over period where connectivity is lost to the database for a short amount of time, which can be mitigated using retry logic”.