SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Windows Server 2012 までの Windows Update をスクリプトから実行する場合、Windows Update Agent API を使用したスクリプトを実行する機会が多かったかと思います。
PowerShell ではありませんが、Searching, Downloading, and Installing Updates で公開されているような方法で、Windows Update をスクリプトで制御することが可能でした。
Windows Server 2016 からは、Windows Update Orchestrator によって制御が行われるようになっており、従来の COM の「Microsoft.Update.AutoUpdate」を使用して、Windows Update をスクリプトから実行することも可能でしたが、それ以外の方法も提供が行われています。
SQL Server と Azure SQL Database (Single Database (Elastic Pool) / Managed Instance / Hyperscale) でパフォーマンスチューニングやトラブルシューティングに利用できる情報を、本投稿のタイトルのシリーズでまとめていきたいと思います。
今回は「sys.dm_exec_query_stats」について紹介します。
SQL Server Management Studio (SSMS) を使用するために、実施している設定のカスタマイズについてまとめておきたいと思います。
気づいたときにいろいろと追記していこうかと。
可視化の方法は様々なものが使用できますが、Azure Data Studio (ADS) にはグラフを作成するための機能がありますので、この機能を利用して 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 をジョブ名と関連付けるための方法は覚えておくとよいかと。
The April 2020 release of Azure Data Studio is now available で Azure Data Studio 1.17.0 のリリースがアナウンスされました。
このリリースから Notebook で KQL Magic がサポートされ、KQL の実行が可能になったようです。
Windows 10 ならびに Winodws Server 2016 /2019 の Windows Update のログを確認するときのメモを。
以前 直近の Windows Update の実行状態をスクリプトで取得する というブログを書きましたが、上記の OS では、Update Session Orchestration (USO) のログを見ることで新たな洞察を得られることもありますので、情報を追加しておきたいと思います。
SQL Server 2016 以降では、クエリ情報の取得はクエリストアを使用して取得を行うことができるようになり、SQL Server / Azure SQL Database では、この機能 (または、クエリストアを活用した機能) により、クエリ実行情報を取得することが一般的な方法となってきているのではないでしょうか。
SQL Server 2016 より前のバージョンでは、次のような DMV を使用して情報の取得が行われるケースが多かったかと思います。
SQL Server 2016 以降の環境で、クエリストアが有効になっている環境でも、これらの DMV を活用した方が、クエリの実行状態を細かに分析することができるケースがあります。
本投稿では sys.dm_exec_requests を使用したクエリの実行状況の取得について見ていきたいと思います。
久しぶりに Windows で AlwaysOn 可用性グループを組んでいて WSFC のノードを検疫状態にしてしまったので覚書を。
Windows Server 2016 / 2019 の WSFC の新機能については フェールオーバー クラスタリングの新機能 で解説が行われています。
Windows Server 2016 では 仮想マシンの回復性 として、「異常なノードの検疫」という機能が追加されています。
異常なノードの検疫: 異常なノードは検疫され、クラスターへの参加は許可されなくなりました。 これにより、フラッピングノードが他のノードやクラスター全体に悪影響を及ぼすのを防ぐことができます。
この機能により、異常なノードについてはノードのステータスが「検疫」となり、一定時間、クラスターへの参加が許可されない状態となります。
詳細については Virtual Machine Compute Resiliency in Windows Server 2016 で解説が行われています。
SQL Server の処理の実行状況を取得するためのシステムテーブルとして sys.sysprocesses というシステムビューが存在しています。
このシステムテーブルは下位互換のビューとして含まれているため、このテーブルを利用しているクエリについては、対応した DMV への移行が推奨されています。
sysprocesses については、3 種類の DMV を使用することになるのですが、各 DMV から単純にデータをとるだけでは、sysprocesses で「AWAITING COMMAND」となっているセッションを取得することはできません。