Microsoft Most Valuable Professionals (Microsoft MVP) を再受賞させていただくことができました。
カテゴリは「SQL Server (on Windows, Linux, Containers)」となり、去年と同様 SQL Server での受賞となりました。
直近はブログの更新頻度も少なくなってきてしまっていますが、引き続き当ブログで情報発信を継続していければと思います。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Microsoft Most Valuable Professionals (Microsoft MVP) を再受賞させていただくことができました。
カテゴリは「SQL Server (on Windows, Linux, Containers)」となり、去年と同様 SQL Server での受賞となりました。
直近はブログの更新頻度も少なくなってきてしまっていますが、引き続き当ブログで情報発信を継続していければと思います。
Windows Server のパフォーマンス状態を確認する際には、パフォーマンス モニターを使用した問題のトラブルシューティング に記載されているような、パフォーマンスモニターのログファイル (blg) を使用して、各種メトリックの解析を行うことがあります。
一般的には、パフォーマンス カウンター ツール に記載されている「perfmon.exe」を使用して解析を行っていきます。
このツールでも十分に解析を行うことは可能ですが、
というようなケースでの利用を想定した場合、perfmon.exe でも実現することはできるのですが、少し手間がかかることがあります。
そこで、自分が使用しやすいようにするための操作が実装された Performance Monitor Analyzer というツールを Vibe Coding で作成し、公開をしました。
perfmon.exe で使用できる次の機能は含まれていないため、複数の blg ファイルの解析の効率は低いのですが、単一ファイルの解析については、普段使いできる機能が含まれているかと思います。
Copilot ライセンスに関する情報 に記載されていますが、Microsoft 365 Copilot アドオンライセンスを保有していない場合、Copilot を使用する際には「Copilot Chat (Basic)」「M365 Copilot (Basic)」のいずれかが使用されます。
どちらも「Microsoft 365 Copilot アドオンライセンスを保有していない」場合に使用されるということですが、保有していないという条件以外に、Copilot Chat (Basic) / M365 Copilot (Basic) が変わる要因があるのかを確認した結果を残しておこうと思います。
ユニファイドサポートのような最上位サポートではなく、通常のサービスリクエストで確認をした内容のため、公開情報ベースとなりますが、確認できた範囲では、明確な基準 / 特定の設定で切り替えをできるということは無いようでした。
SQL Server でロックエスカレーションが発生する要因としては次の 2 種類があります。
閾値については、ロックのエスカレーションのしきい値 に記載されています。
それぞれの閾値に達した場合に、ロックエスカレーションが発生し、ロックの粒度がテーブルにエスカレーションされ確保されます。
この動作により、取得されているロックの数を最小限にすることで、ロックで過剰なメモリが使用されないようにします。
TF1211 を有効にすることで、「1.」「2.」の両方のロックエスカレーションを無効にし、TF1224 を有効にすることで「2.」についてのロックエスカレーションを無効にします。
これが、ロックエスカレーションの基本的な考え方となりますが、「1.」のケースについて、きちんと理解できていなかったことが分かったので、情報をまとめておきたいと思います。
SQL Server の場合、同時接続数の上限は、user connections の設定で指定を行うことができます。
SQL Server では、最大 32,767 の接続をサポートしており、デフォルトが最大数となっています。
SQL Database の場合は、SKU に応じて同時接続数の上限が異なります。
本投稿では、SQL Database の同時接続数の上限についてまとめておきたいと思います。
SQL Server で取得されているロック数を把握する際には、sys.dm_tran_locks を参照することが多いかと思います。
ロック数が数 10 万 / 数 100 万となっている環境では、この DMV を参照して COUNT(*) をするだけでも数分かかってしまい、定期的にロック数を取得して推移を把握するということが難しいケースがあります。
この DMV を使用せず、類似のロック数を把握することができるかを検証してみました。
先日、SQL Database のセカンダリ レプリカのクエリストアについて という投稿をしました。
セカンダリ レプリカのクエリストアヒントについては、SQL Server 2025 でもサポートされているため、分散型可用性グループを構築して、SQL Server でも挙動をを確認してみました。
Vibe Coding (Codex) で作成したツールとなりますが、SQL Server の実行プランを解析するツールとして MSSQLPlanViewer を公開しました。
.NET で作成されている Web アプリケーションとなります。

SQL Server 2022 以降では、セカンダリ レプリカに対してのクエリストアがサポートされています。
SQL Server 2022 では、制限付きプレビュー (TF の有効化が必要)、SQL Server 2025 では一般提供開始されている機能となります。
この機能が SQL Database でも使用することができるようになっています。(本書作成時点では、プレビューでの提供)
SQL Database でこの機能を使用する場合のポイントをまとめておきたいと思います
Build 2026 のタイミングでアナウンスのあった SQL Server 関連のアップデートについてまとめておきたいと思います。