《Windows Azure Platform 系列文章目錄》

　　我們在使用Azure SQL Database的時候，需要對數據庫的性能進行監控，這時候就可以有兩種方法：

　　1.第一種方法，是通過Azure SQL Database的監控界面，來查看數據庫的性能，在本章會簡單的介紹一下

　　2.第二種方法，是通過Query Store來進行監控，在本章會詳細介紹

　　首先，我們介紹一下使用Azure SQL Database的監控界面。

　　1.我們登錄Azure Portal: https://portal.azure.cn/

　　2.查看到我們使用的Azure SQL Database，選擇概述，然後點擊下圖紅色部分

　　3.頁面跳轉後，我們可以在下圖的Last Hour，設置監控的時間段

　　在Add Metric裏面，增加新的監控指標，比如CPU Percentage, Data IO Percentage等

　　4.我們還可以在性能概述裏面，查看到微軟雲Azure對我們當前數據的優化建議

　　接下來，我們詳細介紹一下使用Query Store來進行監控，實際上我們在上面看到的通過Azure Portal的可視化監控，其實也是通過Query Store來進行監控的。

　　Query Store是SQL Server 2016裏面新的功能，同時在微軟雲Azure平臺上，也提供了該功能

　　Query Store是從內存中讀取數據，並異步寫入到Azure SQL Database的磁盤上的

　　這裏我們假設一個場景，如果Azure SQL Databse的DTU利用率很高，我們如何查詢出具體是哪些語句，占用了過多的資源呢？

　　1.首先，我們通過Azure Portal，查看到問題發生的時間，如下圖在9月2日的淩晨開始，發生了該問題

　　我們點擊下圖的紅色部分

　　2.DTU和CPU Time，DataIO都有關。我們點擊下圖的Add Metric

　　3.DTU是和CPU Time，Data IO疊加的因素，我們可以看到下面的CPU Time和DataIO都很高，

　　8點以後都是DATA IO

　　4.我們在本地PC上安裝SQL Server Management Studio，訪問上面的數據庫，並且找到Query Store

　　我們點擊下圖的Top Resource Consuming Queries

　　5.點擊上圖右上角的Config，設置查詢時間

　　6.在彈出的窗口中，選擇查詢時間，我們也可以使用默認的

　　7.我們查詢CPU Time，Static 選擇Avg。可以查看到缺少索引

　　8.在下圖，我們右鍵Miss Index，設置索引

　　9.如果我們需要查詢所有缺少索引的表結構，可以在SSMS執行下面的語句

--Search Missing Index Directly
SELECT
    SUM(qrs.count_executions) * AVG(qrs.avg_logical_io_reads) as est_logical_reads,
    SUM(qrs.count_executions) AS sum_executions,
    AVG(qrs.avg_logical_io_reads) AS avg_avg_logical_io_reads,
    SUM(qsq.count_compiles) AS sum_compiles,
    (SELECT TOP 1 qsqt.query_sql_text FROM sys.query_store_query_text qsqt
        WHERE qsqt.query_text_id = MAX(qsq.query_text_id)) AS query_text,    
    TRY_CONVERT(XML, (SELECT TOP 1 qsp2.query_plan from sys.query_store_plan qsp2
        WHERE qsp2.query_id=qsq.query_id
        ORDER BY qsp2.plan_id DESC)) AS query_plan,
    qsq.query_id,
    qsq.query_hash
FROM sys.query_store_query qsq
JOIN sys.query_store_plan qsp on qsq.query_id=qsp.query_id
CROSS APPLY (SELECT TRY_CONVERT(XML, qsp.query_plan) AS query_plan_xml) AS qpx
JOIN sys.query_store_runtime_stats qrs on qsp.plan_id = qrs.plan_id
JOIN sys.query_store_runtime_stats_interval qsrsi on qrs.runtime_stats_interval_id=qsrsi.runtime_stats_interval_id
WHERE    
    qsp.query_plan like N‘%<MissingIndexes>%‘
    and qsrsi.start_time >= DATEADD(HH, -24, SYSDATETIME())
GROUP BY qsq.query_id, qsq.query_hash
ORDER BY est_logical_reads DESC
GO

　　10.如果我們發現數據庫發生死鎖，可以嘗試以下語句（master庫）執行查看死鎖，更多信息可參考：https://blogs.msdn.microsoft.com/azuresqldbsupport/2017/04/19/deadlock-analysis-for-sql-azure-database/

WITH CTE AS (
       SELECT CAST(event_data AS XML)  AS [target_data_XML] 
   FROM sys.fn_xe_telemetry_blob_target_read_file(‘dl‘, null, null, null)
)
SELECT target_data_XML.value(‘(/event/@timestamp)[1]‘, ‘DateTime2‘) AS Timestamp,
target_data_XML.query(‘/event/data[@name=‘‘xml_report‘‘]/value/deadlock‘) AS deadlock_xml,
target_data_XML.query(‘/event/data[@name=‘‘database_name‘‘]/value‘).value(‘(/value)[1]‘, ‘nvarchar(100)‘) AS db_name
FROM CTE 

　　11.當我們需要手動Kill死鎖的Session時候，需要註意：當前執行完kill 會話後，為什麽執行kill語句完成，但查看會話進程還在？

　　在執行kill殺會話時候，命令執行完成並不代表會話即時被kill掉，會話中有大事務操作的話，為保證數據的一致性，未提交的事務首先要做回滾，執行回滾時間的依據事務操作的大小。
　　建議：一般在Kill會話，建議采用KILL session ID WITH STATUSONLY 方式，這樣我們在kill動作操作結束，可以實時看到當前處理的進度百分比。
　　詳細介紹可參考：https://docs.microsoft.com/zh-cn/sql/t-sql/language-elements/kill-transact-sql?view=sql-server-2017

Azure SQL Database (26) 使用Query Store對Azure SQL Database監控