本ブログでは、次の投稿で SQL Server へのクエリ実行時の「コマンド タイムアウト」(クエリ タイムアウト) について触れてみました。
そもそも「コマンド タイムアウト」とは何なのでしょうか?
上記の投稿では触れていなかった部分についてもまとめておきたいと思います。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
本ブログでは、次の投稿で SQL Server へのクエリ実行時の「コマンド タイムアウト」(クエリ タイムアウト) について触れてみました。
そもそも「コマンド タイムアウト」とは何なのでしょうか?
上記の投稿では触れていなかった部分についてもまとめておきたいと思います。
Released: General Availability of Microsoft.Data.SqlClient 2.0 でアナウンスされましたが、.NET で SQL Server にアクセスするための最新のデータプロバイダーである Microsoft.Data.SqlClient 2.0 がリリースされました。
アナウンスや、リリースノート でも触れられていますが、いくつかの機能が追加されています。
Some of the highlights of new features over the 1.1 release of Microsoft.Data.SqlClient include:
- Support for Active Directory Integrated and Interactive authentication modes when targeting .NET Cor…
- Support for Active Directory Service Principal authentication
- EventSource tracing support
- SNI dependency changes
- SqlBulkCopy RowsCopied property
- Connection Open Overrides
- Order Hints for SqlBulkCopy
PowerShell から新機能の検証をしようと思ったところ、Microsoft.Data.SqlClient 2.0 を使用するのにちょっとハマったので、メモを残しておこうかと。
動作方法がよくわかっていなかったので、”Microsoft.Data. SqlClient is not supported on this platform.” when trying to use it in PowerShell 7.0.2 で助けていただきました (感謝)
Microsoft.Data.SqlClient with PowerShell も参考にさせていただきました。
(本ドキュメントを書かれていた方に Issue でヘルプいただけて感謝、感謝)
Microsoft.Data.SqlClient については Microsoft.Data.SqlClient 名前空間の概要 でドキュメントが公開されていますので、こちらも確認すると良いかと思います。
以前、次の投稿を書きました。
これらの投稿では、「アプリケーションからのクエリタイムアウト (コマンドタイムアウト)」を SQL Server 側 (DB サーバーサイド) で取得する方法について記載を行いました。
(本ブログでも何回か書いていますが、クエリのタイムアウトは「アプリケーションから発行された Attention のメッセージにより、SQL Server がクエリをキャンセルする処理」ですので、クエリをタイムアウトさせているのは、SQL Server ではなく、クエリを発行したアプリケーション側の処理となります)
SQL Server に対してクエリを実行する際に発生するのは、クエリタイムアウトだけでなく、様々なエラーがあります。
本投稿では、クエリタイムアウト以外のエラーを SQL Server 側で取得する方法の一例について紹介したいと思います。
クエリのタイムアウトや、クエリの実行の失敗については、クエリ実行側 (アプリケーション側) で取得した方が正確かと思いますので、SQL Server で全てをキャッチするのではなくアプリケーション (または、APM のような仕組み) でエラーを把握した方が良いと思います。
(DB に対してのクエリ実行でエラーが発生すると、SQL Server 側の調査のみで原因を特定してくれという依頼が多いのですよね…。)
Build 2020 で発表された SQL Server / SQL Database に関連する情報を。
全体のニュースは MICROSOFT BUILD 2020BOOK OF NEWS から。
SQL Server のトラブルシューティングでは「特定の機能を有効化したことによる性能影響への調査」を実施することもあります。
今回は SQL Server 2016 で搭載された「クエリストア」の機能を例として、機能を有効にした場合の性能影響への調査のアプローチを考えてみましょう。
なお、今回の調査は本番環境ではなく、検証環境での調査を前提としています。
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 の実行が可能になったようです。