Using a Shared Access Signature (SAS) is usually the best way to control access rights to Azure storage resources (like a container for backups) without exposing the primary / secondary storage keys. It is based on a URI and this is what I want to look at today.
I always use the Azure Storage Explorer to build a SAS token. Let’s dig into what the different parts mean.
The below image is a beautiful picture, now it could be worse. The red line and the green line could peak at the same time and for a very long time or the blue line could behave the same as the red line and peak at the same time as the green line. Regardless of the situation the point of this blog post is when you are hitting your eDTU (elastic database transaction unit) limits within your elastic pools, tune your queries and do not knee jerk and just scale up (straightaway that is).
Do you want to identify the correct Service Tier and Compute Size ( was once known as performance level) for your Azure SQL Database? How would you go about it? Would you use the DTU (Database Transaction Unit) calculator? What about the new pricing model vCore? How would you translate you current on-premises workload to the cloud?
As Microsoft states “online clustered columnstore index build enables you to optimize and compress your data with minimal downtime without major blocking operations on the queries that are executing while you are transforming the data.”
Based on one of my favourite blog posts ever about unicorns, rainbows and online index operations (https://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-830-unicorns-rainbows-and-online-index-operations/) I wanted to show that using a command such as
Checking out the transaction log in Azure SQL Database. If you are curious like me, you will want to know about what your transaction log is doing in the cloud. The following queries have been tested and run okay within Azure SQL Database it gives you some great insight. First up, the classic log_reuse_wait_desc. You can’t exactly do much with this output, more so, just to fulfill curiosity.
I would like to share a link to my Azure SQL Database Stairway series hosted over at SQLServerCentral.
As stated on the website a stairway guide is a series focused on a single topic and is arranged into no more than a dozen easily-navigable tutorials that we call ‘steps’. Each step is the length of a typical magazine tutorial, and emphasizes practical, hands-on learning, with just enough background theory to help you understand the topic.
If you decide to use IP addresses to control what services have access to your Azure SQL Database, then understanding firewall rules are important. Within this important area you have the ability to create firewall rules that are scoped to the database or server level as shown below.
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).
Now that I have your attention with a powerful title how about some context? It is quite common to get this error message when trying to connect to your Azure SQL Database which obviously resides on a “logical” SQL Server.
