Tools and Documents for fault analysis in SQL Server-based environments
Tools and Documents for fault analysis in SQL Server-based environments.
Azure SQL Developer がアナウンスされました
Build locally, ship to Azure: meet Azure SQL Developer で、ローカルで Azure SQL Database の開発を行うためのデータベース環境である Azure SQL Developer の Private Preview のアナウンスが行われました。
Agent Skills を活用した既存の M365 Copilot 向けのカスタム エンジン エージェントへの Microsoft Agent 365 の機能追加
次の記事で公開されていますが、生成 AI の Agent Skills として、Agent 365 Skills を使用することで、生成 AI からのプロンプトの指示により、既存の Microsoft 365 Copilot 向けのカスタム エンジン エージェントに対して、Microsoft Agent 365 の機能を追加することができます。
- Agent 365 Skills: Bring your agents into Microsoft Agent 365 in minutes
- What’s new in Agent 365 ? June 2026
Microsoft 365 Agents Toolkit (ATK) で提供されているサンプルの天気エージェントに対して、Microsoft Agent 365 の機能を追加するというシナリオで、実際に追加を行うことができましたので、その際の作業内容についてメモをしておきたいと思います。
SQLServer 2019 CU19 / 2022 CU1 で追加された変更の追跡のクリーンアップ用トレースフラグによるクエリの変化
SQL Server の 変更の追跡 では、クリーンアップ プロセス で変更の内容を記録するサイドテーブル (syscommittab / change_tracking_<オブジェクト ID>) のクリーンアップが実行されます。
このクリーンアップはバックグラウンド タスクとして実行されるため、ユーザー側では実行されるクエリの制御ができないのですが、トレースフラグ TF8286 / 8287 を有効にすることでヒント句を追加することができます。
このトレースフラグを有効化することで、クリーンアップで実行されるクエリがどのように変化をするのかを確認してみました。
管理者が Microsoft 365 Copilot のカスタム エンジン エージェントの管理性を検証するために、テスト用のエージェントを展開する際に確認しておきたい情報
Microsoft 365 Copilot で使用できるエージェントの管理を管理者が実施する場合、Copilot Studio / Agent Builder で作成したエージェントの管理性を調査することが多いのではないでしょうか。
それ以外のエージェントとしては、カスタム エンジン エージェント も対象になるケースがあります。
この際、Copilot Studio で作成したエージェントではなく、Azure App Service (Microsoft 365 Agent Toolkit) / Microsoft Foundry 上に展開したエージェントを、カスタム エンジン エージェントと呼ぶことが多いのではないでしょうか。
このようなエージェントを作成する場合、管理者はどのような情報を確認しておけば、開発者に依頼することなく評価用のシンプルなエージェントを作成することができるのか？
これについての関連情報をまとめておきたいと思います。
Microsoft MVP を再受賞させていただきました
Microsoft Most Valuable Professionals (Microsoft MVP) を再受賞させていただくことができました。
カテゴリは「SQL Server (on Windows, Linux, Containers)」となり、去年と同様 SQL Server での受賞となりました。
直近はブログの更新頻度も少なくなってきてしまっていますが、引き続き当ブログで情報発信を継続していければと思います。
パフォーマンスモニターのログ解析ツール Performance Monitor Analyzer を公開しました
Windows Server のパフォーマンス状態を確認する際には、パフォーマンス モニターを使用した問題のトラブルシューティング に記載されているような、パフォーマンスモニターのログファイル (blg) を使用して、各種メトリックの解析を行うことがあります。
一般的には、パフォーマンス カウンター ツール に記載されている「perfmon.exe」を使用して解析を行っていきます。
このツールでも十分に解析を行うことは可能ですが、
- ファイルを変更しながら同一のパターンで何度か解析を行う
- 汎用的な解析パターンでメトリックの確認を行う
- データを Excel に貼り付けて加工しながら解析を行う
というようなケースでの利用を想定した場合、perfmon.exe でも実現することはできるのですが、少し手間がかかることがあります。
そこで、自分が使用しやすいようにするための操作が実装された Performance Monitor Analyzer というツールを Vibe Coding で作成し、公開をしました。
perfmon.exe で使用できる次の機能は含まれていないため、複数の blg ファイルの解析の効率は低いのですが、単一ファイルの解析については、普段使いできる機能が含まれているかと思います。
- 「perfmon.exe /sys /comp」相当の機能
- 複数の blg ファイルを横断して解析
Copilot Chat (Basic) と M365 Copilot (Basic) のどちらが使用されるかについて
Copilot ライセンスに関する情報 に記載されていますが、Microsoft 365 Copilot アドオンライセンスを保有していない場合、Copilot を使用する際には「Copilot Chat (Basic)」「M365 Copilot (Basic)」のいずれかが使用されます。
どちらも「Microsoft 365 Copilot アドオンライセンスを保有していない」場合に使用されるということですが、保有していないという条件以外に、Copilot Chat (Basic) / M365 Copilot (Basic) が変わる要因があるのかを確認した結果を残しておこうと思います。
ユニファイドサポートのような最上位サポートではなく、通常のサービスリクエストで確認をした内容のため、公開情報ベースとなりますが、確認できた範囲では、明確な基準 / 特定の設定で切り替えをできるということは無いようでした。
SQL Server のメモリサイズによるロックエスカレーションについて
SQL Server でロックエスカレーションが発生する要因としては次の 2 種類があります。
- ロックのメモリが閾値に達した場合
- ロック数が閾値に達した場合
閾値については、ロックのエスカレーションのしきい値 に記載されています。
それぞれの閾値に達した場合に、ロックエスカレーションが発生し、ロックの粒度がテーブルにエスカレーションされ確保されます。
この動作により、取得されているロックの数を最小限にすることで、ロックで過剰なメモリが使用されないようにします。
TF1211 を有効にすることで、「1.」「2.」の両方のロックエスカレーションを無効にし、TF1224 を有効にすることで「2.」についてのロックエスカレーションを無効にします。
これが、ロックエスカレーションの基本的な考え方となりますが、「1.」のケースについて、きちんと理解できていなかったことが分かったので、情報をまとめておきたいと思います。
Azure SQL Database の同時接続数の上限について
SQL Server の場合、同時接続数の上限は、user connections の設定で指定を行うことができます。
SQL Server では、最大 32,767 の接続をサポートしており、デフォルトが最大数となっています。
SQL Database の場合は、SKU に応じて同時接続数の上限が異なります。
本投稿では、SQL Database の同時接続数の上限についてまとめておきたいと思います。
sys.dm_tran_locks を参照せずに取得されているロック数を把握できるかを検証する
SQL Server で取得されているロック数を把握する際には、sys.dm_tran_locks を参照することが多いかと思います。
ロック数が数 10 万 / 数 100 万となっている環境では、この DMV を参照して COUNT(*) をするだけでも数分かかってしまい、定期的にロック数を取得して推移を把握するということが難しいケースがあります。
この DMV を使用せず、類似のロック数を把握することができるかを検証してみました。