This is kind of a follow up from my last blog post about a scale down request issue. (https://blobeater.blog/2018/11/07/azure-sql-database-aborting-scale-request/) I was confused, so confused that I ended up logging a support request with Microsoft. The issue was I wanted to scale down a database from S1 to Basic however it would take hours for a 1GB database. Obviously something was up, but what?
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.
Just because the cloud movement is strong doesn’t mean the end of “DBA’s”, it does mean a change in skills and no doubt you will (one day) create Azure SQL Data Warehouse (DW) in Azure. If you are from an operational background like me then backups will be on your mind for this product. The question is how are backups done with Azure SQL DW?
Back in September 2017 Microsoft announced a new security feature for Azure SQL Database called the SQL Vulnerability Assessment (VA). It is currently in preview mode where it has the ability to find, you can guess, security based vulnerabilities for your database such as misconfigurations, excessive permissions, and exposed sensitive data.
Let’s setup a scan. You can find this feature within the settings section of your database.
Nobody wants to waste money and being in the cloud is no exception! Luckily for us Azure is very efficient in tracking usage patterns and its associated costs, in this case, potential cost savings.
You can find this information under Help + Support.
This is quite a new feature (currently in preview) but an important one where we now have the ability to isolate connectivity to a database to only a given subnet or set of subnets within your VNET. This is not a theory based blog post but a practical one, setting them up is easy but deleting them via the portal is a totally different experience.
I had a strange issue recently when trying to login to the Azure Portal. Quite simply I would enter my login details and ended up with this message – Bad Request – Request Too Long, HTTP Error 400. The Size of the request headers is too long.
I used to be on the fence regarding whether or not Automatic Tuning should be on as the default when creating Azure SQL Databases. A part of me never liked the idea of Azure creating/dropping indexes or forcing plans without my prior approval but then again if it happens to do the right thing at the right time then it’s a pleasurable experience.
Six months ago how you would go about setting up Active geo replication for your SQL Databases would be different to today, yes things (naturally) do change but for this specific area it has changed for the better – again something that you would expect right?
Scaling up and down your SQL Database is something that is quite common to do. I want to discuss the impact of moving up and down tiers, in terms of your transactions and connections.