4 Improvements to Azure SQL Database

If I was a wizard I would make these 4 improvements to Azure SQL Database. They are in no particular order, in fact I could come up with about 10 features / improvements that I would like to see  but I think 4 will be suffice. Some are more realistic than others, I am sure for some of them I am more likely to get a tiger as a pet.

Azure SQL Analytics

This would be great if it was integrated more into the server blade within the portal. This one is probably quite easy to do and it would enhance the user experience. Right now it can be a little confusing. You need to enable diagnostic settings on the database / elastic pool and then go and create a log analytics work-space. How easy would it be if we could do all this via a button on the main database server blade? Something like the below.

ImproveAzure

Natively restore .BAK file

I would love this ability and it would get me away from using BACPACs. Imagine having the ability to take a copy only full backup straight to Azure storage then logging on via SSMS and writing some TSQL for a restore? The thing with BACPACs is that they can be a pain to execute on busy systems and they are not really true backups.

In built automated scale up and scale down

Again this is something you can do via PowerShell and run it via a runbook, the code isn’t too complex but this feature should be exposed via the portal. Something like what Microsoft already do for the VMs. For example autoscale based on a performance metric. i.e. if my CPU for my SQL Database (already captured by Azure anyways) > 90% usage lets scale up to a higher service tier. Or perhaps time based? I know at 2am we have low number of users so let’s scale down. Obviously we will need to make application changes to handle this sort of change because it may mean connections getting dropped, perhaps a retry policy might work here. A step further here? Maybe something like Amazon’s DynamoDB auto scaling service where it can dynamically adjust provisioned throughput capacity on our behalf, in response to actual traffic patterns… this might be a long shot though!

Execute USE command

To have the ability to execute something like:

USE [AWSDB]
GO
SELECT [SalesOrderID]
      ,[RevisionNumber]
      ,[OrderDate]
      ,[DueDate]
      ,[ShipDate]
FROM [SalesLT].[SalesOrderHeader]
GO
USE [FastDB]
GO
SELECT * FROM [dbo].[BuildVersion]

Which always returns –

Msg 40508, Level 16, State 1, Line 11 USE statement is not supported to switch between databases. Use a new connection to connect to a different database. Msg 208, Level 16, State 1, Line 13.

Now it is your turn, what would you guys change or add?

 

2 thoughts on “4 Improvements to Azure SQL Database

  1. Pingback: Dew Drop - April 9, 2018 (#2700) - Morning Dew

  2. I would have built alerts/notifications for extended SQL Database Resource Health Events, with “extended” starting at a 15 minutes threshold where the database is not available. I have to support 300+ customer databases and within the last six weeks have experienced two such events (separate databases on separate elastic pools). Knowing such a situation quickly versus finding it within a couple of hours would allow me to drop the SECONDARY relationship and point our app to what is now the PRIMARY while I open a case with MS. Right now MS tells me I can use the REST API and write a polling app so perhaps I am the only one who has had pain with this situation.

    Liked by 1 person

Leave a Reply