I have a passion for Microsoft Azure and SQL Server technology. I am a frequent writer where my articles have been published on SQL Server Central and Microsoft TechNet. During 2017 I worked with the Microsoft SQL Server product team on testing the vNext adaptive query processing feature and other Azure product groups. I am also a member of Microsoft’s Azure Advisors and SQL Advisors groups, as well as a Microsoft Certified Solutions Expert on the Data Platform.
Copyright © in accordance with the Copyright, Designs and Patents Act 1988. All rights reserved. You are free to use any of the content here for personal use but need permission to use it anywhere or by any means (electronic, mechanical, photocopying, recording or otherwise).
I have decided to do a 4-part series on Cloud “Fear Busting” scenarios. Why? Over the past few years working with the cloud (Azure) I have come across 4 main “fears” or “concerns” that stand out in my mind that people have highlighted when adopting cloud technology for their database tier. Each “fear” with form a blog post where I am hoping that after reading each post you will be “less” fearful. More specifically I will be looking at these topic areas:
- I have security fears for SQL Database.
- Performance Issues that I faced – Learn from my mistakes.
- There is no going back – can I get the data back?
- I’m a DBA – Will I lose control?
Series Link Here.
We all know that the magic figure for cost threshold for parallelism is 5 by default, meaning if the estimated cost of a query is greater than 5 it may very well generate a parallel plan.
Does this apply to Azure SQL Database? Let’s check.
This command only applies to Azure SQL Database, at a high level it empties the database authentication cache for logins and firewall rules for the current USER database.
When you create a “logical” Azure SQL Server (I say logical because we are not really physically creating anything) there is a setting that is ticked ON by default which is called “Allow Azure services to access server”.
The question is, what does it mean? (See the highlighted section below)
I am a big fan of this feature, I have written and spoken about it before ( https://blobeater.blog/2018/01/04/azure-sql-analytics/) but I did not cover HOW to set this up. In the previous post mentioned above all I stated was:
- Setup a Log Analytics workspace.
- Enable diagnostics for your SQL Databases and/or elastic pools.
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.
I was using a query on one of my local SQL Servers where I wanted to know what logins were connected to my databases. I actually ended up running the query against my Azure SQL Database and had some very interesting results.
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.
Times are changing, 10 years ago I would never have thought that self-tuning databases would be available as a packaged product. I was testing out SQL Server 2017 Automatic Tuning recently and I ended up with the following situation. Below shows an image from the query store.
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.
Thank you to everyone that took the time to write and contribute, I enjoyed reading about how you conquered your challenges, here is a round-up in no particular order.