A Fine Slice Of SQL Server
Like all services in Azure, there’s associated costs when using the service, and naturally Microsoft Purview is no different. If interested in reading the standard pricing model for Microsoft Purview it has been outlined here – and follows a similar layout to all Azure price models.
However – as a result of such a broad range of capabilities, its pricing model is one of the more difficult to understand!
Read on for a PDF which hits the various charges you’ll see.
Comments closedReitse Eskens continues a series on performance comparisons for Azure SQL DB:
This tier is more expensive than the basic, but starting at 12 euro’s per month up to 3723 euro’s you have a wider range of spending your money and with that a wider performance range. The standard tier is suited for general purpose workloads and can be compared with the general purpose tier whereas the latter works with cores. Standard tier works with DTU’s. The concept of a DTU is a difficult one as the documentation states it’s a blend of CPU, Memory, reads and writes. If you hit a limitation, you’ll be throttled. You can read more about the DTU model here.
One thing I wish Reitse had done in the images was to show them in log scale—there’s a consistent L curve for each (which is good) but makes it hard to see anything after about Standard S4.
Comments closedI constantly see customers with so many managed disks which are unattached and orphaned. Recommendation here would be to delete these if you know you can. Else (from a VM within Azure in the same region where the disks are (to save on egress costs)) use Azure Storage Explorer, download the managed disks as VHD disks, then copy to an Azure Storage account and mark the storage account as Archive (tape storage backend).
Archive storage is estimated less than 10% the cost of managed disk storage. Note, VHDs can be brought back and imported again as managed disks at any time if they are needed.
Pricing can be confirmed by using the Azure Pricing Calculator
There’s a lot of solid guidance in here.
Comments closedArun Sirpal is looking for a query plan:
Whatever your database background is you will have heard of an execution / explain plan. Snowflake is no different. Coming from a MS SQL background I was used to reading plans from right to left. Now it is bottom to the top!
Read on to see how you can find the query plan for an operation.
Comments closedSarath Sasidharan clones an Azure Synapse Analytics dedicated SQL pool:
There are many scenarios where you want to create a new Synapse dedicated SQL pool environment based on an existing Synapse dedicated SQL pool environment. This may be required when you need to create a development or test environment based on your production environment by copying complete schemas and without copying data.
Note that this process won’t move the data itself—given that you’re starting with terabytes for an effective dedicated SQL pool, trying to create a bacpac would be an exercise in misery.
Comments closedJohn Sterrett does some DNS work:
Azure Managed Instances are provisioned by default with a yourname.uniqueid.databases.windows.net DNS fully qualified domain name (FQDN). Even on your private virtual network you will still have to use this FQDN.
If you want your Azure Managed Instance to connect with your DNS prefix like yourname.domain.com this blog post is for you.
Read on for the process.
Comments closedAmanda Ibrahim answers a customer request:
If the customer needs to configure auto scaling for SQL Managed Instance, where the vCores can be increase and decrease automatically on specific time.
Read on to learn how. This can be useful for dev environments or places where your use case has “office hours”—that is, 90% of your activity takes place during a block of 4-12 hours—and you can afford the time in which the service is unavailable due to scaling.
Comments closedShaf Mahmood has a few updates for us:
The optimized autoscale feature has been in place and using reactive logic. It has been helping ADX users by adjusting the cluster size when there is an increase in resources due to ingestion or query load. The optimized autoscale feature has been further improved with predictive logic. This logic monitors the same metrics as the reactive logic and over time builds up the cluster usage pattern and uses this to forecast and plan the size of the cluster. The reactive logic is still used to ensure any forecast anomalies or usage pattern changes are still autoscaled appropriately.
There are a few cost-related updates but also updates to visuals, data ingestion, and more.
Comments closedReitse Eskens keeps things basic:
When you look at the documentation, the basic tier has low CPU (at max less than one), 1 to 4 IOPS per DTU (translating to 5-20 IOPS in total), a latency of 5ms read and 10 ms write and a maximum of 7 days backup retention. Even though it’s advertised as a production database, I wouldn’t store essential data there. However, I can use it for metadata storage in a Data Factory or Synapse Analytics environment.
About the IOPS, one IOP is a read of a disk cluster, usually 4 Kb. In this case, this means that the database is capable of reading 20 to 80 Kb of data per second.
When they say Basic, they aren’t kidding.
Comments closedGarry Bargsley restores a backup:
My post for T-SQL Tuesday #154 is going to be a demo of the new SQL Server feature that allows you to restore an Azure SQL Managed Instance backup to a SQL Server 2022 instance. Actually, I am not sure if this is a feature or just an enhancement that allows for this behavior to work.
Current versions of SQL Server do not allow the restoration of backups taken on Azure SQL Managed Instance. Managed Instances are considered “vNext” and runs a different version that is beyond anything on-premises could keep up with due to the frequent changes being applied to Managed Instance. There has always been a disconnect with the restorability between the two platforms, so it is good that Microsoft has found a solution to this limitation.
I’d still like to see the ability to fail from SQL MI to on-prem (or VM) SQL Server—you can go from on-prem to Azure SQL MI, though it sounds like right now, failback is a database restore.
Comments closed