ご存知のように、データベース管理者の主な責任は、SQL Serverのパフォーマンスを監視し、決められた時間に介入することにあります。市場にはいくつかのSQLServerパフォーマンス監視ツールがありますが、パフォーマンスの問題を診断およびトラブルシューティングするために、SQLServerのパフォーマンスに関する追加情報が必要になる場合があります。したがって、SQL Serverに関する問題を処理するには、SQLServer動的管理ビューに関する十分な情報が必要です。
動的管理ビュー（DMV）は、SQLServerEngineのパフォーマンスメトリックを検出するのに役立つ概念です。 DMVはSQLServer2005バージョンで最初に発表され、その後はすべてのバージョンのSQLServerで継続されました。この投稿では、データベース管理者が十分な情報を持っている必要がある特定のDMVについて説明します。これはsys.dm_os_wait_statsです 。
sys.dm_os_wait_stats
sys.dm_os_wait_stats SQLServerのパフォーマンスの問題を診断するための重要なメトリックをサポートします。 SQL Serverエンジンに問題（CPU、メモリ、I / O、ロック、ラッチなど）がある場合は、sys.dm_os_wait_statsデータが問題の定義をガイドします。 SQL Server Management Studioのアクティビティモニターには、「リソース待機」という名前のパネルが含まれています 」。 「ResourceWaits」は、特別なストアドプロシージャからこれらのメトリックを取得します。この一時的なストアドプロシージャの名前は「#am_generate_waitstats」です。 」であり、sys.dm_os_wait_statsを使用します。この一時ストアドプロシージャは「tempdb」にあります。ここで、一時ストアドプロシージャに関するメモを追加します。このタイプのストアドプロシージャには一般的な使用法がないためです。
一時的なストアドプロシージャ 永続的なストアドプロシージャと違いはありません。一時テーブルのようにローカルとグローバルの2つのタイプがあります。ローカルストアドプロシージャは現在のセッションでアクティブなままであり、セッションが閉じた後に削除されます。次のように作成できます：
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
グローバルストアドプロシージャもすべてのセッションでアクティブなままであり、作成されたセッションが閉じた後に削除されます。グローバルストアドプロシージャは、次のように作成できます。
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
ヒント： Activity Monitorを開くと、 #am_generate_waitstatsが作成されます 一時的なストアドプロシージャであり、終了後に削除されます。
次に、 sys.dm_os_wait_statsの主なアイデアと詳細を調べます。 。次のクエリは、SQLServerの「待機統計」に関するすべてのデータを返します。このクエリは最も純粋な形式です。このようなフォームの問題を検出するのは不便です。次のセクションでは、sys.dm_os_wait_statsよりも便利なクエリを見つけることができます。次に、SQLServerの「待機統計」列の説明を説明します。
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
wait_type列 待機統計の定義または名前が含まれています。問題の主な理由を示す待機統計の定義があるため、wait_type列データは私たちにとって重要です。 waiting_tasks_countは、SQLServerで発生した待機タイプの頻度を示します。
wait_time_ms 合計待機時間を示します。測定単位はミリ秒です。
max_wait_time_ms 最大待機時間を示します。
signal_wait_time_ms MSDNでは、「待機中のスレッドが通知された時間と実行を開始した時間の違い」と説明されています。この列の値が特に高い場合は、CPUの圧力を示しています。したがって、クエリは実行可能なキューで待機しており、実行の準備ができていますが、CPUは他のクエリでビジーです。このため、クエリはキューで待機しています。 CPUリソースが使用可能になると、CPUは実行可能キューから新しいクエリを取得し、処理を開始します。つまり、 signal_wait_time_msを説明できます。 実行可能キューの待機時間として、実行可能から実行可能になります。
ヒント： ベストプラクティスでは、いくつかの待機統計が他の統計よりも重要です。これらは次のようにリストできます：
•PAGEIOLATCH_*
•WRITELOG
•ASYNC_NETWORK_IO
•CXPACKET
•CPU
•LCK_M_*
•PREEMPTIVE_*
•PAGELATCH_*
PinalDaveまたはPaulS.Randalを見てください。統計クエリを待ちます。彼らは、クエリでいくつかの待機統計タイプを排除しました。以下のリソース待機タイプは、 sys.dm_os_wait_statsで削除できます。 クエリ：
•BROKER_EVENTHANDLER
•BROKER_RECEIVE_WAITFOR
•BROKER_TASK_STOP
•BROKER_TO_FLUSH
•BROKER_TRANSMITTER
•CHECKPOINT_QUEUE
•CHKPT
•CLR_AUTO_EVENT
•CLR_SEMAPHORE
•DBMIRROR_DBM_EVENT
•DBMIRROR_DBM_MUTEX
•DBMIRROR_EVENTS_QUEUE
•DBMIRROR_WORKER_QUEUE
•DBMIRRORING_CMD
•DIRTY_PAGE_POL />•EXECSYNC
•FSAGENT
•FT_IFTS_SCHEDULER_IDLE_WAIT
•FT_IFTSHC_MUTEX
•HADR_CLUSAPI_CALL
•HADR_FILESTREAM_IOMGR_IOCOMPLETION
•HADR_LOGCAPTURE •HADR_TIMER_TASK
•HADR_WORK_QUEUE
•LAZYWRITER_SLEEP
•LOGMGR_QUEUE
•MEMORY_ALLOCATION_EXT
•ONDEMAND_TASK_QUEUE
•PREEMPTIVE_HADR_LEASE_MECHANISM
•PREEMPTIVE_HADR_LEASE_MECHANISM
•PREEMPTIVE_OS_COMOPS
•PREEMPTIVE_OS_CREATEFILE
•PREEMPTIVE_OS_CRYPTOPS
•PREEM PTIVE_OS_DEVICEOPS
•PREEMPTIVE_OS_FILEOPS
•PREEMPTIVE_OS_GENERICOPS
•PREEMPTIVE_OS_LIBRARYOPS
•PREEMPTIVE_OS_PIPEOPS
PREEMPTIVE_OS_PIPEOPS
•PREEMPTIVE_OS_PIPEOPS
•PREEMPTIVE_OS_QUERYREGISTRY
•PREEMPTIVE_OS_QUERYREGISTRY
• br />• PREEMPTIVE_SP_SERVER_DIAGNOSTICS
• PREEMPTIVE_XE_GETTARGETSTATE
• PWAIT_ALL_COMPONENTS_INITIALIZED
• PWAIT_DIRECTLOGCONSUMER_GETNEXT
• QDS_ASYNC_QUEUE
• QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP
• QDS_PERSIST_TASK_MAIN_LOOP_SLEEP
• QDS_SHUTDOWN_QUEUE
•REDO_THREAD_PENDING_WORK
•REQUEST_FOR_DEADLOCK_SEARCH
•RESOURCE_QUEUE
•SERVER_IDLE_CHECK
•SLEEP_BPOOL_FLUSH
•SLEEP_DBSTARTUP
•SLEEP_DCOMSTARTUP
•SLEEP_MASTER SLEEP_MASTERMDREADY
•SLEEP_MASTERUPGRADED
•SLEEP_MSDBSTARTUP
•SLEEP_SYSTEMTASK
•SLEEP_TASK
•SP_SERVER_DIAGNOSTICS_SLEEP
•SQLTRACE_BUFFER_FLUSH
•SQLTRACE _INCREMENTAL_FLUSH_SLEEP
•SQLTRACE_WAIT_ENTRIES
•UCS_SESSION_REGISTRATIO
•WAIT_FOR_RESULTS
•WAIT_XTP_CKPT_CLOSE
•WAIT_XTP_CKPT_CLOSE
•WAIT_XTP_HOST_WAIT
•WAIT_XTP_HOST_WAIT
•WAIT_XTP_HOST_WAIT
•WAIT_XTP_HOST_WAIT
•WAIT_X br/>•WAITFOR_TASKSHUTDOW
•XE_TIMER_EVENT
•XE_DISPATCHER_WAIT
•XE_LIVE_TARGET_TVF
ヒント： SQL Serverは、起動時または再起動時にDMVデータの収集を開始します。 SQL Serverは再起動時に待機統計を自動的にリセットし、以下のクエリはSQLServerが最後に再起動されてからの待機統計を強制的にリセットします。
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) さらに、待機統計の測定精度が重要なポイントです。この時点で、2つのアプローチを検討できます。
•待機統計をリセットし、待機統計を再収集します。
•2つの異なる「時間待機統計」を取得し、値の違いを測定します。
私の意見では、履歴テーブルのアプローチの待機統計をキャプチャして保存することは、他のアプローチよりも優れています。この方法では、特に時間間隔を測定でき、履歴データの待機統計を失うことはありません。
次に、待機統計のキャプチャのサンプルを作成し、キャプチャされたデータをPowerBIでグラフィックスとともに表示します。
待機統計を保存する履歴テーブルを作成します：
CREATE TABLE [dbo].[HistoryOfWaitStatistics]( [SQLStartTime] [datetime] NULL, [Dt] [datetime] NOT NULL, [WaitType] [nvarchar](60) NOT NULL, [WaitTimeSecond] [numeric](25, 6) NULL, [ResourcesWaitSecond] [numeric](25, 6) NULL, [SignalWaitSecond] [numeric](25, 6) NULL ) ON [PRIMARY]
次のスクリプトは、履歴テーブルに「待機統計」を挿入します。ただし、このクエリはSQLServerエージェントでスケジュールする必要があります 履歴テーブルを保存するには：
DROP TABLE IF exists #eliminate_WS
CREATE TABLE #eliminate_WS (wait_type NVARCHAR(100));
INSERT INTO #eliminate_WS VALUES ('ASYNC_IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('CHECKPOINT_QUEUE');
INSERT INTO #eliminate_WS VALUES ('CHKPT');
INSERT INTO #eliminate_WS VALUES ('CXPACKET');
INSERT INTO #eliminate_WS VALUES ('DISKIO_SUSPEND');
INSERT INTO #eliminate_WS VALUES ('FT_IFTS_SCHEDULER_IDLE_WAIT');
INSERT INTO #eliminate_WS VALUES ('IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('KSOURCE_WAKEUP');
INSERT INTO #eliminate_WS VALUES ('LAZYWRITER_SLEEP');
INSERT INTO #eliminate_WS VALUES ('LOGBUFFER');
INSERT INTO #eliminate_WS VALUES ('LOGMGR_QUEUE');
INSERT INTO #eliminate_WS VALUES ('MISCELLANEOUS');
INSERT INTO #eliminate_WS VALUES ('PREEMPTIVE_XXX');
INSERT INTO #eliminate_WS VALUES ('REQUEST_FOR_DEADLOCK_SEARCH');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_QUERY_SEMAPHORE_COMPILE');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_SEMAPHORE');
INSERT INTO #eliminate_WS VALUES ('SOS_SCHEDULER_YIELD');
INSERT INTO #eliminate_WS VALUES ('SQLTRACE_BUFFER_FLUSH ');
INSERT INTO #eliminate_WS VALUES ('THREADPOOL');
INSERT INTO #eliminate_WS VALUES ('WRITELOG');
INSERT INTO #eliminate_WS VALUES ('XE_DISPATCHER_WAIT');
INSERT INTO #eliminate_WS VALUES ('XE_TIMER_EVENT');
INSERT INTO HistoryOfWaitStatistics
SELECT
(SELECT sqlserver_start_time FROM sys.dm_os_sys_info ) as SQLStartTime,GETDATE() AS Dt,Wait_type as WaitType,
wait_time_ms / 1000. AS WaitTimeSecond,
(wait_time_ms - signal_wait_time_ms)/1000. AS ResourcesWaitSecond,
signal_wait_time_ms/1000. AS SignalWaitSecond
FROM sys.dm_os_wait_stats
WHERE wait_type IN(SELECT wait_type FROM #eliminate_WS) 履歴データが保存されたら、Power BIを開き、待機統計ダッシュボードを作成します。
データを取得をクリックします SQL Serverを選択します ：
接続設定を設定してから、クエリを SQLステートメント（オプション、データベースが必要）に記述します。 。 OKをクリックします 。
マーケットプレイスからインポートをクリックします
OKVizによるスパークラインを探す ビジュアルコンポーネントと追加 Power BI
以下の画像のように、Power BIデザインパネルにSparklineを追加し、データセット列をドラッグアンドドロップします。
フィルタする2つのテーブルコンポーネントを追加します： SQLStartTime およびWaitType 。最後に、ダッシュボードは次のようになります。
リソース待機の問題を診断する方法：
このセクションでは、待機統計の問題を診断する方法と規律について説明します。特に、待機統計について1つのポイントを理解する必要があります。それは、問題の主要な構造を定義するだけで、詳細を提供することはありません。このため、待機の詳細と理由を調査する必要があります。したがって、「統計を待つ」ことで、私たちの研究をこの方向に向けることができます。その後、他のツール（PerfMon、拡張イベント、サードパーティの監視ツールなど）および他のDMVを使用して、正確な問題を定義する必要があります。
SQL ServerでASYNC_NETWORK_IOを観察すると仮定すると、このリソース待機は、クライアントからサーバー側への低速ネットワーク接続に関連しています。ただし、サーバー側とクライアント側の間にいくつかのネットワーク構成がある可能性があるため、この情報は問題の主な理由のトラブルシューティングには役立ちません。この例では、次のことを確認する必要があります。
•大規模な結果セットクエリ
•ネットワークインターフェイスカードの構成
•サーバー側からクライアント側へのネットワーク環境の設定。
•ネットワークアダプタの帯域幅を確認します。
例でわかるように、正確な問題を定義するためにいくつかのタスクを完了する必要があります。待機統計は、問題のターゲットを示していません。
結論
この投稿では、sys.dm_os_wait_stats動的管理ビューの主な概念について説明しました。同時に、使い方のシンプルさと注意が必要なポイントについても話し合いました。
便利なツール：
dbForge Monitor –SQLServerのパフォーマンスを追跡および分析できるMicrosoftSQLServerManagementStudioのアドイン。