Disclaimer: QPI library is open source library provided as-is and not maintained by Microsoft. There are not guarantees that the results are correct and that there are not bugs in calculations. This is a helper library that can help you to more easily analyze performance of your Managed Instance, but you can do the same job by looking directly at DMVs.

exec qpi.snapshot_wait_stats;

waitfor delay '00:00:03';

select *
from qpi.wait_stats
order by wait_time_s desc;

• qpi.snapshot_file_stats procedure will take a snapshot of io statistics from sys.dm_io_virtual_file_stats DM function. You MUST take the snapshot because sys.dm_io_virtual_file_stats contains cumulative information and you need to calculate sample in the recent time interval.
• qpi.file_stats view will get the file statistics since the last snapshot. This view contains several calculations such as IOPS, throughput based on a data from sys.dm_io_virtual_file_stats.

Cosmos DB setup

Driver setup

Querying CosmosDB

SELECT a.*
FROM OPENROWSET('MSDASQL', 
'DSN=cosmosdb1', 
'select * from Orders where billto_Name = ''John Smith''') as a

Conclusion

• Storage limit of managed instance that you choose on the portal. This limit cannot be bigger than 8TB in General Purpose or 4TB in Business Critical. In this post you can find how to check storage usage and create alerts using SQL Agent.
• (General Purpose only) Allocation limit of underlying remote Azure premium storage which is described here.

• (General Purpose only) the storage limit of local SSD disk storage - in Managed Instance tempdb is placed in local SSD that can have 24GB*<number of vCores> space. If you reach this limit, you would not be able to create temporary objects in tempdb.

SELECT volume_mount_point,
used_gb = CAST(MIN(total_bytes / 1024. / 1024 / 1024) AS NUMERIC(8,1)),
available_gb = CAST(MIN(available_bytes / 1024. / 1024 / 1024) AS NUMERIC(8,1)),
total_gb = CAST(MIN((total_bytes+available_bytes) / 1024. / 1024 / 1024) AS NUMERIC(8,1))
FROM sys.master_files AS f 
CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id)
GROUP BY volume_mount_point;

• Your databases are in "read-only" state because nothing can be written in log/data files.
• Some of the read queries cannot run because they might require tempdb to grow to store some temporary objects.
• CHECKPOINT cannot flush data from memory into mdf files.

select top 1 avg_cpu_percent,
storage_space_used_mb / reserved_storage_mb
from master.sys.server_resource_stats
order by start_time desc

Sending alerts using db_mail

declare @cpu_perc float, @storage_perc float;
declare @instance nvarchar(200) = @@SERVERNAME;

select top 1 @cpu_perc = avg_cpu_percent,
@storage_perc = storage_space_used_mb / reserved_storage_mb
from master.sys.server_resource_stats order by start_time desc

if(@cpu_perc > .95 or @storage_perc > .9)
begin

declare @msg nvarchar(max) = CONCAT('You are reaching the compute/storage limits of your instance ', @@SERVERNAME, ':
Storage ', @storage_perc, '%
CPU usage:', @cpu_perc, '%
Consider upgrading the instance.');
exec msdb.dbo.sp_notify_operator 
@profile_name = N'AzureManagedInstance_dbmail_profile', 
@name = N'DevOps team', 
@subject = N'Azure SQL Instance - Storage limit alert', 
@body = @msg;
end

• sys.dm_os_wait_stats that returns instance level wait statistics
• sys.query_store_wait_stats that returns query-plan wait statistics per database.

Analyze wait statistics

exec qpi.snapshot_wait_stats

There is a mapping logic between wait types and wait categories that is documented on SQL Server documentation and these rules are added in this library. This is important because this is the only link between global wait statistics and query store wait statistics.

1. Create a temporary table
2. Call a stored procedure

3. Insert a row into the temporary table.
4. Return the row from the temporary table.

• We will check if the outer-scope module used for creating the temporary table at compile time is the same one used for consecutive executions.
• We will keep track of any data definition language (DDL) changes made at initial compilation and compare them with DDL operations for consecutive executions.

• Improved throughput, as represented by Batch Requests/sec (blue line, second hump).
• Shorter overall workload duration.
• Reduced recompilations, as represented by SQL Re-Compilations/sec (green line) showing only a small increase at the beginning of the second test.

• Paul Randal How to examine IO subsystem latencies
• Erin Stellato What Virtual Filestats Do, and Do Not, Tell You About I/O Latency.

1. Take the snapshots of your sys.dm_io_virtual_file_stats
2. Calculates the values such as IO throughput, latency, etc. Calculations are same/similar as in Paul & Erin scripts.
3. Enables you to go back in past and examine the latency of the previous snapshot - this is a small additional functionality compared to Paul & Erin scripts.

Prerequisite - install QPI

This is plain T-SQL script that you can review to make sure that there is nothing dangerous inside.

Analyzing io statistics

EXEC qpi.snapshot_file_stats;

SELECT * FROM qpi.file_stats;

SELECT * FROM qpi.db_file_stats;

• read_latency_ms/write_latency_ms represent average latency to complete request end-to-end.
• read_io_latency_ms/write_io_latency_ms represent average latency to complete request in IO subsystem. Ideally it should be same as read_latency_ms/write_latency_ms. If there is a difference, then SQL Server Database Engine cannot catch-up procession IO requests or introduces some IO throttling.

SELECT * FROM qpi.file_stats_as_of( <some date> );

Conclusion

We are excited to announce that this capability is now available in public preview.

For more information and to get started with using Azure SQL Database as your reference data set for Azure Stream Analytics, see this announcement.