SQL Server のトラブルシューティングでは「特定の機能を有効化したことによる性能影響への調査」を実施することもあります。
今回は SQL Server 2016 で搭載された「クエリストア」の機能を例として、機能を有効にした場合の性能影響への調査のアプローチを考えてみましょう。
なお、今回の調査は本番環境ではなく、検証環境での調査を前提としています。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
SQL Server のトラブルシューティングでは「特定の機能を有効化したことによる性能影響への調査」を実施することもあります。
今回は SQL Server 2016 で搭載された「クエリストア」の機能を例として、機能を有効にした場合の性能影響への調査のアプローチを考えてみましょう。
なお、今回の調査は本番環境ではなく、検証環境での調査を前提としています。
Azure Data Factory (ADF) で、コピーアクティビティを使用して、データの投入 (インポート) を行う場合、ポータルからシンプルに設定を行場合は、次のようにマッピングの情報を指定することになります。
(同一の構成 (同一列名) のテーブル to テーブルであれば、明示的なマッピングを設定する必要が不要なケースもあると思いますが)
このようなインポートを実行する場合に、マッピングを設定するのが面倒だったので、コピーアクティビティのマッピング情報を動的に設定してみたいと思います。
Azure SQL Auditing to storage account behind Virtual Network and firewall now generally available でアナウンスがありましたが、Azure SQL Database の監査ログを、仮想ネットワークとファイアウォールのある背後にあるストレージアカウントに対して出力する機能が GA となりました。
これにより、閉じられたネットワークに対してのアクセスのみを許可しているストレージアカウントに監査ログ (サーバーレベル / DB レベルの監査の両方) の出力ができるようになります。
詳細については VNet とファイアウォールの背後にあるストレージ アカウントに対して監査を書き込む に記載されていますのでこちらを確認すれば問題ないと思いますが、関連する内容をいくつか検証してみようかと。
最新のアップデートを終えていなかったので、Build 2020 が開始される前に、SQL Server on Azure VM と SQL Database のアップデートをキャッチアップしておこうかと。
今までブログにかけていなかった内容 (ここ、数ヶ月で気づいた内容) を主に記載しています。
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 の実行が可能になったようです。