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 に対してのデバッグ実行ができますが、デバッグ実行を想定した動作で使用するためには Visual Studio 2019 を使用したほうが良いかと思います。
Visual Studio 2019 を使用したほうが良い理由は次の内容で記載されているものと同様の事象が発生したためです。
Visual Studio 2019 / 2022 の両環境で SQL Server のデバッグ実行を行うことができます。
しかし、Visual Studio 2022 のデバッグ実行ではステップイン実行時にトリガーやストアドプロシージャ内のステーメントをステップ実行することができず、これらのオブジェクトの実行に切り替わった際にはステップオーバーにより実行されてしまい、メインとなるスクリプト以外のステップ実行を行うことができませんでした。
Visual Studio 2019 でデバッグ実行した場合はステップイン実行により、トリガー / ストアドプロシージャが呼び出された場合はそれぞれのオブジェクトに遷移しステップ実行することができるようになります。(この動作がデバッグ実行時に期待したい動作となります)
Visual Studio を使用した T-SQL のデバッグ実行については様々な情報が公開されており、それらの情報の中ではストアドプロシージャ内のステートメントをステップイン実行して実行されています。
しかし、使用している Visual Studio については、2019 以前を使用しているようで Visual Studio 2022 を使用したストアドプロシージャ内のステートメントのステップイン実行については情報は無いような気がしています。