SQLServerでのパフォーマンスの監視とトラブルシューティングは広大なトピックです。 SQL Server 2005では、DMVとも呼ばれる動的管理ビューが導入され、SQLServerのパフォーマンスの問題を診断するための不可欠な支援ツールになりました。同時に、AzureSQLデータベースの動的管理ビューを使用できます。それらの一部はSQLServerのオンプレミスデータベースとは異なる場合がありますが、作業のロジックは同じです。 Microsoftには、動的管理ビューに関する非常に優れたドキュメントがあります。唯一のことは、動的管理ビューのバージョンと製品の検証に注意する必要があります。 sys.dm_exec_requestなどはSQLServer2008以降のバージョンとAzureSQLデータベースで使用できますが、sys.dm_db_wait_statsはAzureSQLデータベースでのみ有効です。
この投稿では、sys.dm_exec_requestの基本について説明します。 sys.dm_exec_requestsは、現在実行中のリクエストのみを返す動的な管理ビューです。これは、sys.dm_exec_requestsクエリを実行すると、その時間に実行されていて履歴データを含まないリクエストのスナップショットを作成することを意味します。したがって、このビューはリアルタイムのリクエストを監視するのに非常に便利です。言い換えれば、「今、私のサーバーで何が起こっているのか」という答えが得られます。このビューには多くの詳細が含まれていますが、最も重要なものについて説明します。
session_id :この値は、セッション識別番号を定義します。 SQL Serverでは、50以下のセッションIDはバックグラウンドプロセス専用です。
start_time :この値は、リクエストの開始日時を定義します。
ステータス :この値は、リクエストのステータスを定義します。利用可能なステータスは次のとおりです。
- 背景
- 実行中
- 実行可能
- 眠っている
- 一時停止
SELECT DISTINCT status FROM sys.dm_exec_requests WHERE session_id <>@@SPID
背景 :このステータスタイプは、バックグラウンドプロセスを定義します。それらのいくつかは、レイジーライター、チェックポイント、およびログライターです。
select session_id, command, os_thread_id from sys.dm_exec_requests as r join sys.dm_os_workers as w on r.task_address = w.task_address join sys.dm_os_threads as t on t.thread_address = w.thread_address where session_id <= 50 order by session_id
実行中 :このステータスタイプは、リクエストがCPUによって処理されていることを定義します。
select * from sys.dm_exec_requests where status='running' and session_id <>@@SPID
実行可能 :このステータスタイプは、CPUキューで実行を待機している要求として簡単に定義できます。 sys.dm_exec_requestsで実行可能なプロセスを多数検出した場合は、CPUの負荷が高いことを示している可能性があります。このメトリックは、このCPUパフォーマンスの問題を診断するのに十分ではありません。このため、より多くの証拠でこの事件を支持する必要があります。これは私たちの理論を証明するために重要です。 sys.dm_os_wait_stats動的管理ビューには、signal_wait_time_msという列が含まれています。この列の値は、CPUの問題を判別するのに役立ちます。次のクエリは、Signalwaitのパーセンテージを示しています。このメトリックの値が高い場合は、CPUパフォーマンスの問題に直面している可能性があります。この方法でレビューを深めることができます。
---https://sqlserverperformance.wordpress.com/page/146/ ---Glenn Berry's SQL Server Performance SELECT signal_wait_time_ms=SUM(signal_wait_time_ms) ,'%signal (cpu) waits' = CAST(100.0 * SUM(signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2)) ,resource_wait_time_ms=SUM(wait_time_ms - signal_wait_time_ms) ,'%resource waits'= CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2)) FROM sys.dm_os_wait_stats;
一時停止 :このステータスタイプは、一部のリソースの待機プロセスを定義します。 I / O、LOCK、LATCHなどがあります。前述のように、 sys.dm_os_wait_statsを使用できます。 wait_time_msを検出するための動的管理ビュー。
眠っている :リクエストはSQL Serverに接続されていますが、現在コマンドを実行していないことを意味します。
コマンド :この列は、実行されているコマンドのタイプを定義します。同時に、完了率である特定のコマンドの追加情報を見つけることができます。オンラインブックによると、これらは;
ALTER INDEX REORGANIZE
ALTERDATABASEを使用したAUTO_SHRINKオプション
バックアップデータベース
DBCC CHECKDB
DBCC CHECKFILEGROUP
DBCCチェックテーブル
DBCC INDEXDEFRAG
DBCC SHRINKDATABASE
DBCC SHRINKFILE
回復
データベースの復元
ロールバック
TDE暗号化
デモ :
- マスターデータベースに接続し、任意のデータベースのバックアップを開始します。
BACKUP DATABASE WideWorldImporters TO DISK ='NUL'
ヒント :データベースを「NUL」デバイスにバックアップする場合、SQL Serverはバックアップファイルをどこにも書き込まず、テストバックアップファイルの削除を回避します。ただし、実稼働環境ではこのコマンドを使用しないでください。 LSNチェーンを壊す可能性があります。
次のクエリを実行します:
SELECT command,percent_complete ,* FROM sys.dm_exec_requests WHERE session_id <>@@SPID and session_id>50 and command='BACKUP DATABASE'
sql_handle :この値は、要求のSQLステートメントを定義します。ただし、この値はビットマップ形式です。このため、sys.dm_exec_sql_textテーブル値関数を使用して、値を意味のあるテキストに変換する必要があります。
select session_id ,command , sqltxt.text ,database_id from sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt where session_id<>@@SPID AND session_id>50
database_id :この値は、どのデータベースが要求を行うかを定義します。このフィールドをsys.databasesと結合して、データベース名を取得できます。
select session_id ,command , sqltxt.text ,db.name from sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt inner join sys.databases db on db.database_id = req.database_id where session_id<>@@SPID AND session_id>50
wait_type :この値は、要求の現在の待機タイプを定義します。クエリの実行に予想よりも時間がかかる場合は、クエリの待機タイプを確認して判断できます。
transaction_isolation_level :この値は、送信されたクエリのトランザクションレベルを定義します:
0=指定なし
1 =ReadUncomitted
2 =ReadCommitted
3=繰り返し可能
4=シリアル化可能
5=スナップショット
select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level, CASE transaction_isolation_level WHEN 0 THEN 'Unspecified' WHEN 1 THEN 'ReadUncomitted' WHEN 2 THEN 'ReadCommitted' WHEN 3 THEN 'Repeatable' WHEN 4 THEN 'Serializable' WHEN 5 THEN 'Snapshot' END AS isolation_level_name from sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt inner join sys.databases db on db.database_id = req.database_id where session_id<>@@SPID AND session_id>50
blocking_session_id :リクエストをブロックしているセッションのIDです。この列がNULLの場合、リクエストはどのセッションもブロックしていません。
デモ :
- SQL Server Management Studioを開き、次のクエリを実行します。
DROP TABLE IF EXISTS TestPerfomon GO CREATE TABLE TestPerfomon (ID INT , Nm VARCHAR(100)) INSERT INTO TestPerfomon VALUES(1,1) GO BEGIN TRAN UPDATE TestPerfomon SET Nm='2' WHERE ID=1 SELECT @@SPID AS blocking_session_id
新しいクエリウィンドウを開き、次のクエリを実行します。
SET TRANSACTION ISOLATION LEVEL Serializable BEGIN TRAN UPDATE TestPerfomon SET Nm='3' WHERE ID=1
別の新しいクエリウィンドウを開き、このDMVクエリを実行します。
select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level, CASE transaction_isolation_level WHEN 0 THEN 'Unspecified' WHEN 1 THEN 'ReadUncomitted' WHEN 2 THEN 'ReadCommitted' WHEN 3 THEN 'Repeatable' WHEN 4 THEN 'Serializable' WHEN 5 THEN 'Snapshot' END AS isolation_level_name , blocking_session_id from sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt inner join sys.databases db on db.database_id = req.database_id where session_id<>@@SPID AND session_id>50
このデモンストレーションでは、2番目のクエリがブロックされる理由と、どのセッションがリクエストをブロックするかを確認しました。 sp_BlitzWho 65を実行すると、ブロックの詳細とブロックされたセッションの詳細を確認できます。
sp_BlitzWho 65
このデモンストレーションでは、ブロックされたセッションとブロックされたセッションの詳細を取得すると同時に、これらのセッションの詳細を取得しました。これは非常に基本的なデモンストレーションですが、問題を解決する方法を示しています。
この投稿では、sys.sys.dm_exec_requestsについて説明しました。この動的な管理ビューにより、リクエストの現在のラング中にスナップショットを取得する柔軟性が得られます。また、これらの詳細データは、問題を発見するプロセスを支援またはガイドすることができます。
参考資料
- sys.dm_exec_requests(Transact-SQL)
- 動的管理ビューを使用したAzureSQLデータベースの監視
- sys.dm_db_wait_stats(Azure SQLデータベース)
便利なツール:
dbForge Monitor –SQLServerのパフォーマンスを追跡および分析できるMicrosoftSQLServerManagementStudioのアドイン。