SQL Server ではクエリのデバッグ実行をするための T-SQL デバッガーの機能が含まれており、サポートするツールからのクエリ実行について、ステップ実行しながらデバッグをすることができます。
普段は管理用のクエリを書くことが多く、ユーザーから実行されるクエリを書くことに直接携わることは少ないのですが、ユーザーワークロードのクエリ実行で確認したいことがあり、デバッグ実行したほうが早いかなと思い、投稿時点の T-SQL デバッグの情報についてまとめてみました。
Contents
サポートされる SQL Server ベースの環境
ネットワーク要件と PaaS のサポートについて
デバッグ実行にはサーバー側 / クライアント側で次の情報に記載されているネットワーク要件を満たす必要があります。
この要件を満たすためには、SQL Server を実行している OS に直接ログイン (またはネットワーク経由で OS に対してコマンド実行) する必要がありまｓ。
PaaS として提供されている SQL Server ベースの環境 (Azure SQL / RDS for SQL Server / Cloud SQL for SQL Server 等) では、必要となる設定を OS に追加することができない / TDS 以外のポートをアクセス許可することができない / sysadmin の権限を使用することができないため、デバッグ実行を使用することができません。
PaaS で実行したいクエリをデバッグ実行したい場合は、PaaS から Dacpac / Bacpac のようなデータ層アプリケーション (DAC) の機能で DB をエクスポートして SQL Server にインポートすることで、SQL Server 上に環境を作る必要があるかと思います。
(PaaS によっては SQL Server の Native Backup をユーザーが取得できるケースもありますので、データ層アプリケーション以外の方法でも可)
Windows 版以外の SQL Server に対してのデバッグ実行について
Windows 版の SQL Server でないとオープンされていないポート / 機能を使用する必要があるため、Linux / Container 版の SQL Server では使用することができないという認識です。(TCP 135 であれば、DTC 関連の機能を有効にすることで対応できそうですが、その他のポートをデバッグ用にオープンすることができないかと)
Windows 版以外の SQL Server でのデバッグのサポートについては、投稿時点では実現されていませんが、以下で議論が行われていますので、こちらの情報も参考になると思います。
SQL Server はクエリのデバッグ実行をする環境にインストールしておく必要があるか
SQL Server の実行環境についてはリモート / ローカルのどちらでも対応しており、サーバー / クライアントで Windows Firewall で適切なポート / プログラムに対して設定が行われていれば、デバッグ用のクエリを実行した環境上に SQL Server がインストールされていなくてもデバッグ実行が可能です。
デバッグ実行に関しては、接続先の SQL Server に対して sysadmin の権限が必要となり、インスタンス管理者の権限を付与する必要があります。
デバッグ実行のためにリモートインスタンスに強力な権限を付与することも難しいかと思いますのでローカルの SQL Server でデバッグ実行ができるような環境にしたほうが良いかと思います。(ローカルの SQL Server であれば、ファイアウォールの設定が不要でデバッグ実行ができますので)
ローカルの環境については SQL Server Developer Edition / Express Edition だけでなく、LocalDB を使用することができますので、ローカルに構築するデバッグ用の SQL Server のインスタンスについては、無償提供されているものを使用してもいくつかのエディションから選択することはできます。
デバッグ実行がサポートされるツール
サポートされるツール
T-SQL のデバッグ実行がサポートされるツールに関しては、次のツールとなります。
- SQL Server Management Studio 17.9.1 以前 (SSMS)
- SQL Server Data Tools
- Visual Studio に SQL Server Data Tools のコンポーネントを追加するのではなく、SSDT のスタンドアロンインストーラー
- Visual Studio 2017 ベースの環境となり、SQL Server 2022 には接続することができなかった
- Visual Studio 2019
- Visual Studio 2022
SSMS については 18.x がリリースされた際にデバッグ機能が削除されたことで物議がありましたが、投稿時点では、最新の SSMS ではデバッグ機能は復活していません。
SSMS のデバッグ機能については SQL Server User Voice の次のトピックから確認することができます。(スパムコメントがかなりあるので、コメント内のリンクはクリックしないことをお勧めします)
SSMS を使用した T－SQL デバッグ
SSMS は複数のバージョンをサイドバイサイド実行することができるので最新の SSMS とデバッグ実行がサポートされる最新の SSMS 17.9.1 の両方をインストールしておき、デバッグする場合には、17.9.1 を使用するという使い分けができます。
SSMS 17.8.1 は 2018 年にリリースされたバージョンとなるため、SQL Server 2019 以降の全機能がサポートされていないため、サポートされていないバージョンの SQL Server の管理には制限が出ます。
古いバージョンの SSMS では、T-SQL を実行する程度であれば、接続さえできれば古い SSMS でも対応できますが、一部のオブジェクトの操作ができない等の機能制限が出る可能性が高くなります。
私が検証した範囲では SSMS 17.9.1 を使用して SQL Server 2022 に接続をしてデバッグ実行をするということはできました。
Visual Studio を使用した T-SQL デバッグ
Visual Studio 2017 ベースの SSDT を使用したデバッグですが SQL Server 2022 に接続ができなかったため、スタンドアロンインストーラーの SSDT についてはデバッグで使用できる SQL Server のバージョンに制限があります。
Visual Studio 2019 / Visual Studio 2022 については SQL Server 2022 に対してのデバッグ実行ができます。
以前は、Fail to debug a SQL procedure in Visual Studio 2022 の問題が発生していまいｓた。
本投稿の初稿のタイミングでも同様の事象が発生しており、ストアドプロシージャをデバッグする際に、Visual Studio 2022 では、ストアドプロシージャ内をステップイン実行するということができず、ステップイン実行をするためには、Visual Studio 2019 を使用する必要がありました。(拡張機能として、SQL Server Data Tools – Sql Editor はインストールされていてもステップイン実行が実行できませんでした)
この問題は英語版以外の Visutal Studio を使用している場合に発生していたようで、SQL debugger can’t step-into (VS2022 17.4.3 German on German Windows 10 Pro) / SQL debugger can’t step-into (VS2022 non-english versions) / Debug SQL Stored Procedure not working in VS2022 17.6.4 で問題が報告されていました。
2024-08-30 に、Debugging T-SQL using Visual Studio という記事が公開されたため、改めて検証をしてみたところ、Debug SQL Stored Procedure not working in VS2022 17.6.4 が更新されており、2023-11-15 で修正が行われ、日本語環境の Visual Studio 2022 でもストアドプロシージャのステップイン実行ができるようになっています。