One of the features Microsoft wants us to use for Azure SQL Database is Automatic Tuning. Automatic Tuning is a feature where you can think of it as entering the world of self-running and self-tuning databases.
It is said to be safe, reliable and proven using complex algorithms and built-in intelligence where it can do the following (see this link for more details: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-automatic-tuning)
- CREATE INDEX – identifies indexes that may improve performance of your workload, creates indexes, and automatically verifies that performance of queries has improved.
- DROP INDEX – identifies redundant and duplicate indexes daily, except for unique indexes, and indexes that were not used for a long time (>90 days). Please note that at this time the option is not compatible with applications using partition switching and index hints.
- FORCE LAST GOOD PLAN – identifies SQL queries using execution plan that is slower than the previous good plan, and queries using the last known good plan instead of the regressed plan.
It is always a good idea to test your failover processes when you have setup failover groups in Azure. I have the following setup:
Forget about Adaptive Query Processing for a minute, what other feature have I been waiting for? SELECT INTO a specific filegroup, not the default filegroup! I have needed this feature many times in the past. Let’s take a look at it using the WideWorldImportersDW database.
You may (or may not) have a requirement to setup a linked server to Azure SQL Database from a locally installed SQL Server. One reason could be to pull down some reports from an Azure SQL Database to a local file share. Whatever your reason is hopefully you will find this blog post useful because I ran into some complications on the way.
I was creating some demo non-clustered indexes in one of my Azure SQL Databases and received the following warning when I executed this code:
I do not always use the Azure portal to make database changes or to check for certain information. I use it a lot of for blogging purposes but for some tasks I rather just run code via SSMS – SQL Server Management Studio.
Creating copies of your Azure SQL Database is a common and relatively simple process. You can issue a TSQL statement on the master database such as:
CREATE DATABASE CodeDBcopy
AS COPY OF CodeDB
After demo building and testing features out within Azure SQL Database I like to delete the databases to save costs. Very rarely the following happens when trying to delete a database within Azure.
I could not read my error log on one of my local SQL Servers, when I executed the following code:
I received the below:
Msg 22004, Level 16, State 1, Line 2 Failed to open loopback connection. Please see event log for more information. Msg 22004, Level 16, State 1, Line 2 Error log location not found.
It’s good to be proactive and one way is to setup alerts and it is no different when using Azure SQL Database. I like creating alerts for my Azure SQL Databases and I encourage you to do the same.