When I was presenting my Azure SQL Database session at DataRelay (used to be SQLRelay) I was asked (over coffee) about auto scaling capabilities. Quite simply there is nothing out of the box to achieve this. The idea of auto scaling would be good where you would need a burst to fulfill higher demand in terms of workload for a time duration, you know, something like “end of the day, Friday night sale” for your database.
Okay it is not really called Giant Azure SQL Database but its close. There is a new public preview vCore service tier called Hyperscale. The architecture behind this is very different to that of a Standard tier SQL database (as an example). What drives this concept? Flexible storage architecture where you can scale out the storage as your database grows (up to the 100TB mark).
It is always a good idea to test your failover processes when you have setup failover groups in Azure. I have the following setup:
Time for a fun post, I have been working on a mini-project using technology from Microsoft Azure to hook into Arsenal FC public twitter feed to analyse what was being said about this great football club. (Yes I support Arsenal)
Okay honestly I have done this once. I have deleted Azure SQL Databases and then try and find the quickest way to recover. The Azure portal is actually pretty good when it comes to deleting resources, for example it will usually ask you to re-type the name of the resource to confirm deletion, so you can tell what a bad mistake I made.
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.
No, not quite. I have had many interesting conversations around this topic and I don’t think (personal opinion) that DBAs will disappear from the world of IT. It will definitely change, the so-called “production DBAs” affected the most. With Azure SQL Database (and other company offerings – think Oracle Autonomous DB) you will need to adapt (both short term and long term) some argue with me that the long-term looks harder to predict for DBAs which is true so I can’t talk about that. I mean for example how good will automatic tuning get? Better than the average DBA? I am looking at things from a short-term perspective. What tasks are expected of you to carry out in this new world? Well, this is from experience.
In my mind there are a couple of ways to move a database across resource groups. They vary from scripting to just using the Azure portal. I am going to use the Azure portal and do the following.
It’s just like a “backup and restore” strategy, all with the assumption that you are working within the same subscription ID.
I use elastic pools. They are a fabulous way of saving money when running many Azure SQL Databases, that is assuming you understand the resource utilization patterns of the databases involved.
Lets just get straight to the point, Azure SQL Database across all service tiers gives you the customer a SLA of 99.99% up-time. This means potential unavailability periods shown below.
