SQL Server と Azure SQL Database (Single Database (Elastic Pool) / Managed Instance / Hyperscale) でパフォーマンスチューニングやトラブルシューティングに利用できる情報を、本投稿のタイトルのシリーズでまとめていきたいと思います。
今回は「sys.dm_exec_query_stats」について紹介します。
Archive for the ‘SQL Server’ Category
SQL Server Management Studio を使いやすくするためのカスタマイズ
SQL Server Management Studio (SSMS) を使用するために、実施している設定のカスタマイズについてまとめておきたいと思います。
気づいたときにいろいろと追記していこうかと。
Azure Data Studio を使用した統計情報のヒストグラムの可視化
可視化の方法は様々なものが使用できますが、Azure Data Studio (ADS) にはグラフを作成するための機能がありますので、この機能を利用して SQL Server の統計情報のヒストグラムを可視化する方法を紹介したいと思います。
SQL Server エージェント ジョブのプログラム名をジョブ名に変換する
SQL Server で SQL Server エージェントでジョブを実行している場合、sys.dm_exec_sessions の「program_name」に 「SQLAgent – TSQL JobStep (Job 0x66479B4A282C8545BED20F14B618478A : Step 2)」というような形式で表示が行われています。
この際、表示されている program_name ですが、GUID を Binary 表示したものとなっています。
これをジョブ ID と関連付けるためには、次のようなクエリを実行します。
SELECT
T.*,
j.name,
j.description
FROM
(
SELECT
program_name,
CAST(
CONVERT(varbinary,
SUBSTRING(
program_name,
CHARINDEX('0x', program_name),
34
),1) AS uniqueidentifier) AS job_id
FROM
sys.dm_exec_sessions AS es
WHERE
program_name Like '%JobStep%0x%'
) AS T
LEFT JOIN msdb.dbo.sysjobs AS j
ON j.job_id = T.job_id
これにより、SQL Server エージェント ジョブの program_name を実際のジョブ名と関連付けることができます。
sys.dm_exec_requests と sys.dm_exec_sessions を組み合わせて、実行中のクエリ情報を取得する際にはプログラム名も取得するのが定石となります。
SQL Server エージェント ジョブについても「実際にはどのジョブなのか？」が確認できた方が分析の効率が良いですので、このような方法で program_name をジョブ名と関連付けるための方法は覚えておくとよいかと。
Azure Data Studio で KQL の実行が可能になりました
The April 2020 release of Azure Data Studio is now available で Azure Data Studio 1.17.0 のリリースがアナウンスされました。
このリリースから Notebook で KQL Magic がサポートされ、KQL の実行が可能になったようです。
sys.dm_exec_requests を活用したクエリの実行状況の取得
SQL Server 2016 以降では、クエリ情報の取得はクエリストアを使用して取得を行うことができるようになり、SQL Server / Azure SQL Database では、この機能 (または、クエリストアを活用した機能) により、クエリ実行情報を取得することが一般的な方法となってきているのではないでしょうか。
SQL Server 2016 より前のバージョンでは、次のような DMV を使用して情報の取得が行われるケースが多かったかと思います。
SQL Server 2016 以降の環境で、クエリストアが有効になっている環境でも、これらの DMV を活用した方が、クエリの実行状態を細かに分析することができるケースがあります。
本投稿では sys.dm_exec_requests を使用したクエリの実行状況の取得について見ていきたいと思います。
sys.sysprocesses を使用しないで「AWAITING COMMAND」となっている接続の情報を取得する
SQL Server の処理の実行状況を取得するためのシステムテーブルとして sys.sysprocesses というシステムビューが存在しています。
このシステムテーブルは下位互換のビューとして含まれているため、このテーブルを利用しているクエリについては、対応した DMV への移行が推奨されています。
sysprocesses については、3 種類の DMV を使用することになるのですが、各 DMV から単純にデータをとるだけでは、sysprocesses で「AWAITING COMMAND」となっているセッションを取得することはできません。
拡張イベントでコマンドタイムアウトが発生したクエリを取得する
クエリストアによる、クエリタイムアウトしたクエリの取得 では、クエリストアの機能を使用して、コマンドタイムアウト (クエリタイムアウト) が発生したクエリの浄法を取得しました。
クエリストアが使用できない環境では拡張イベントを使用しても取得することができますので、書いておこうかと。
SQL Server の Batch / Statement / RPC はどのような情報なのか？
SQL Serve のクエリ情報を取得する際には、次のイベントカテゴリの情報を使用することがあるのではないでしょうか?
これらのイベントカテゴリの情報には、Batch / Statement / RPC / SP というようなイベントがあり、クエリの情報を取得する場合には、これらの情報を拡張イベントや SQL トレース (SQL Server Profiler / サーバーサイドトレース を使用して取得を行いますが、これらのイベントカテゴリは、どのようなクエリを実行した際に、どの部分の情報を取得することができる野でしょうか？
本投稿では、これらのイベントカテゴリで取得されている情報の基本的な考え方をまとめてみたいと思います。
イベントの考え方に関しては、拡張イベントと SQL Server Profiler で同様の考え方となりますが、蘇rぞれの機能によってイベントの名称が異なっています。
使用する機能に応じたイベントの対応については SQL トレースのイベント クラスと等価な拡張イベントを確認する のドキュメントで確認できますので、こちらを参照してください。
Data Migration Assistant (DMA) で拡張イベントをインプット情報として活用する
SQL Server のバージョンアップや、クラウド移行 (SQL Database / Managed Instance への移行) を実施する際のアセスメントと移行を行うためのツールとして Data Migration Assistant (DMA) というツールが公開されています。
このツールでは、Data Migration Assistant を使用した SQL Server 移行評価の実行 の 評価するデータベースと拡張イベントトレースの追加 に記載されているように、拡張イベント (xEvent) をインプットとして、アドホッククエリのシンタックスエラーのチェックを行うことができるようになります。
この、拡張イベントを入力としたアドホッククエリのチェックですが、4/7 時点のドキュメントに書いている内容を実施しても拡張イベントを使用した処理が行われていないように見えました。
先週 MicrosoftR Data Migration Assistant v5.1 の公開が行われたようで、本日この内容を確認していたところ、次の記載がありました。
(最新バージョンを使用すると SQL Server 2019 を移行元として使用することもできるようになっています)
sql_batch_completed event for application / xevent trace assessments
拡張イベントを入力として使用する場合、「sql_batch_completed」をイベントとして取得しないといけないようです。