GitHub上のMicrosoftDocs/sql-docsリポジトリで行われた「Update resolution for system_health on SQL MI」は、Azure SQL Managed Instanceを運用している開発者・クラウド管理者・アーキテクトが確認すべきドキュメント更新です。結論から言うと、system_health拡張イベントセッションのevent_fileターゲットに関する既知問題が「部分的に解決」から「解決済み」に更新され、sys.fn_xe_file_target_read_fileでsystem_healthを読む場合の扱いが明確化されました。監視、障害調査、移行設計で独自の回避策を入れている環境では、今すぐ「回避策を継続すべきか」「標準機能に戻せるか」を検証する価値があります。(GitHub)
GitHubの公式ドキュメント更新「Update resolution for system_health on SQL MI」で何が変わったか
今回の更新は、GitHub上のMicrosoftDocs/sql-docsリポジトリに対するコミットです。対象は主に次の2つのMicrosoft Learnドキュメントです。
| 変更対象 | 確認すべきポイント |
|---|---|
| Azure SQL Managed Instanceの既知問題ページ | system_healthのevent_fileターゲットに関する問題のステータスが「Resolved」に更新 |
sys.fn_xe_file_target_read_fileのリファレンス | Azure SQL Managed Instanceでsystem_healthを読む場合、ローカルファイル名を指定できる旨が追記 |
重要なのは、これは単なる文言修正ではなく、運用判断に影響する更新だという点です。従来は、Azure SQL Managed Instanceでsystem_healthのevent_fileターゲットを読もうとすると、https://で始まるURLが必要だというエラー40538が発生するケースがありました。公式ドキュメントでは、この問題が2026年3月に解決済みと整理されています。 (Microsoft Learn)
一方で、GitHubの更新日だけを見て「2026年4月29日に新機能がリリースされた」と判断するのは早計です。コミット上の変更はドキュメント反映であり、既知問題ページでは解決時期が「March 2026」とされています。運用チームは、ドキュメント更新日と実際のサービス挙動の反映時期を分けて確認する必要があります。(GitHub)
変更前後の違いを整理
今回のGitHub更新で特に注目すべき差分は、system_healthの読み取りに関する扱いです。
| 項目 | 更新前の理解 | 更新後に確認すべき理解 |
|---|---|---|
| 既知問題のステータス | 一部解決、または回避策が必要な問題として扱われていた | SQL Managed Instanceでは解決済みとして整理 |
| SSMSでの確認 | SSMSでは解決済み、関数利用では未解決という読み方が残っていた | SSMSとsys.fn_xe_file_target_read_fileの両方で解決済みと記載 |
sys.fn_xe_file_target_read_file | Azure SQLではローカルパス指定時にエラー40538が発生する前提で設計しがち | SQL Managed Instanceのsystem_healthに限り、ローカルファイル名を指定できる例外が明記 |
| 回避策 | Azure Blob Storage上に独自のsystem_health相当セッションを作る運用が選択肢 | 回避策を継続するか、標準のsystem_health参照へ戻すかを再評価 |
sys.fn_xe_file_target_read_fileのドキュメントでは、Azure SQL Managed InstanceまたはAzure SQL Databaseのevent_fileターゲットで作成されたファイルは基本的にAzure StorageのBlobに保存されると説明されています。そのうえで、Azure SQL Managed Instanceのsystem_healthセッションについては、資格情報を作成しなくてもローカルファイル名を指定して読めることが追記されています。(Microsoft Learn)
そもそもsystem_healthとは何か
system_healthは、SQL ServerおよびAzure SQL Managed Instanceに既定で含まれるExtended Eventsセッションです。Database Engineの起動時に自動で開始され、パフォーマンス問題や重大エラーの調査に役立つ情報を収集します。公式ドキュメントでは、デッドロック、重大エラー、メモリ関連エラー、長時間のラッチ待機・ロック待機、接続エラーなどが収集対象として挙げられています。(Microsoft Learn)
実務では、次のような場面でsystem_healthがよく使われます。
| 活用シーン | 確認したいこと |
|---|---|
| 突発的な性能劣化 | 長時間待機、非yielding scheduler、重大エラーの有無 |
| デッドロック調査 | deadlock graphの取得、発生時刻、関係するセッション |
| 障害一次切り分け | エラーの発生タイミング、SQLテキスト、セッション情報 |
| 移行後の安定性確認 | SQL Managed Instance移行後に予期しないエラーが出ていないか |
| 監視基盤の補完 | アプリケーションログやAzure Monitorだけでは見えないDB内部イベントの確認 |
ただし、system_healthは「何でも記録する万能ログ」ではありません。収集対象は限定され、保存サイズや保持数にも制限があります。公式ドキュメントでも、system_healthセッションを停止・変更・削除しないことが推奨されています。将来の製品更新で設定が上書きされる可能性があるため、標準セッションを直接カスタマイズするより、必要に応じて別のExtended Eventsセッションを作る方が安全です。(Microsoft Learn)
開発者・クラウド管理者がまず確認すべきこと
今回の更新を受けて、Azure SQL Managed Instanceを利用している環境では、次の順序で確認すると無駄がありません。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | SQL Managed Instanceでsystem_healthを参照しているか | 障害調査手順書、監視ジョブ、運用Runbookを確認 |
| 2 | エラー40538への回避策を入れているか | 独自Extended Events、Azure Blob Storage出力、手動収集手順の有無 |
| 3 | sys.fn_xe_file_target_read_fileを使ったクエリがあるか | SQL Agent、監視ツール、運用SQL、障害調査テンプレートを確認 |
| 4 | SSMSでsystem_healthを見る運用があるか | DBAやSREの手順にSSMS確認が含まれるか |
| 5 | 本番環境で標準機能に戻せるか | 検証環境で同じクエリを実行し、結果と権限を確認 |
特に見落としやすいのは、障害時だけ使う「手順書内のSQL」です。定期ジョブに入っていなくても、インシデント対応用のRunbookに古い回避策が残っていると、復旧時に余計な作業が発生します。
sys.fn_xe_file_target_read_fileで確認する基本クエリ
Azure SQL Managed Instanceでsystem_healthの直近イベントを確認する場合、まずは次のようなクエリで読み取り可否を確認します。
SELECT TOP (100)
object_name,
timestamp_utc,
CAST(event_data AS xml) AS event_xml,
file_name,
file_offset
FROM sys.fn_xe_file_target_read_file('system_health*.xel', NULL, NULL, NULL)
WHERE timestamp_utc >= DATEADD(DAY, -1, SYSUTCDATETIME())
ORDER BY timestamp_utc DESC;公式ドキュメントでも、SQL Server 2017以降の例として、system_health*.xelを指定して直近1日分のデータを取得するクエリが示されています。今回のポイントは、この考え方がAzure SQL Managed Instanceのsystem_health読み取りにも関係することです。(Microsoft Learn)
ただし、次の点には注意してください。
| 注意点 | 理由 |
|---|---|
system_health以外のローカルファイルまで読めると解釈しない | ドキュメント上の例外はSQL Managed Instanceのsystem_healthに関するもの |
| Azure SQL Databaseにも同じ挙動があると決めつけない | 対象サービスやサポート範囲が異なる |
| 権限不足と既知問題を混同しない | 関数実行にはサーバー状態・パフォーマンス状態の参照権限が必要な場合がある |
| 大量結果をSSMSに直接返さない | 大きな結果セットではSSMS側でエラーになる可能性がある |
sys.fn_xe_file_target_read_fileの権限について、公式リファレンスではSQL Server 2019以前ではVIEW SERVER STATE、SQL Server 2022以降ではVIEW SERVER PERFORMANCE STATEが必要とされています。Azure SQL Managed Instanceで実際に必要な権限は環境や実行主体によって確認が必要ですが、読み取り失敗時は「既知問題が再発した」と判断する前に、権限と実行コンテキストを確認すべきです。(Microsoft Learn)
既存の回避策を見直す判断基準
過去にエラー40538への対策として、Azure Blob Storageに独自のExtended Eventsセッションを出力していた環境では、回避策をすぐ削除するのではなく、目的別に整理して判断します。
| 現在の運用 | 推奨される判断 |
|---|---|
| エラー40538を避けるためだけに独自セッションを作った | 検証後、標準のsystem_health参照へ戻す候補 |
system_healthより長く履歴を保持したい | 独自セッションを継続する価値がある |
| 監査・証跡用途でBlobに保存している | 標準機能に戻すのではなく、保存要件を優先 |
| 障害時にDBAがSSMSで見るだけ | 手順を簡素化できる可能性が高い |
| 監視ツールが独自XEventを前提にしている | ツール連携を確認してから段階的に見直す |
実務上は、「問題が解決したから回避策を削除する」ではなく、「回避策が今も必要な理由があるか」を確認することが重要です。たとえば、保存期間を長くしたい、特定イベントだけを軽量に収集したい、アプリケーション別に監視を分けたいといった理由があるなら、独自セッションの継続は合理的です。
移行準備で確認すべき影響
SQL ServerからAzure SQL Managed Instanceへ移行する計画がある場合、今回の更新は障害調査設計に関係します。
移行プロジェクトでは、接続、バックアップ、互換性、性能検証に注目が集まりがちです。しかし、移行後に問題が起きたときに「どのログを見ればよいか」が決まっていないと、初動が遅れます。system_healthを標準の調査導線に組み込めるかどうかは、移行後運用の品質に直結します。
移行前に確認したい項目は次の通りです。
| 確認項目 | 具体的な作業 |
|---|---|
| 障害調査手順 | SQL Server側で使っていたsystem_health確認手順をSQL Managed Instance向けに書き換える |
| 権限設計 | 運用担当者や監視用IDが必要な情報を読めるか検証する |
| 監視連携 | Azure Monitor、Log Analytics、独自監視とsystem_healthの役割分担を決める |
| 保持期間 | 標準のsystem_healthで足りるか、別途Blob保存が必要か判断する |
| インシデント訓練 | デッドロックや重大エラー発生時に、誰がどのSQLで確認するかを決める |
この更新は、移行可否を左右する大きな仕様変更というより、移行後の運用設計を現実的に見直す材料です。とくにグローバル環境でSQL Managed Instanceを複数リージョンに展開している場合、各リージョン・各サブスクリプションで同じ手順が使えるかを確認しておくと、障害対応のばらつきを減らせます。
失敗しやすいポイント
今回の更新で起こりやすい誤解は、次の3つです。
「GitHubの更新＝GitHubサービスの機能変更」と誤解する
今回の対象はGitHubそのものの機能ではなく、GitHub上で管理されているMicrosoftDocs/sql-docsリポジトリのドキュメント更新です。内容の中心はAzure SQL Managed InstanceとSQL Server関連ドキュメントです。GitHub Actions、GitHub Enterprise、GitHub Copilotなどの仕様変更ではありません。
「Azure SQLのevent_fileはすべてローカル名で読める」と広げて解釈する
sys.fn_xe_file_target_read_fileのドキュメントでは、Azure SQL Managed InstanceまたはAzure SQL Databaseのevent_fileターゲットで作成されたファイルは基本的にAzure Storage Blobに保存されると説明されています。そのうえで、SQL Managed Instanceのsystem_healthについてローカルファイル名指定の例外が示されています。対象を広げすぎると、別のXEventセッションでエラー40538に遭遇する可能性があります。(Microsoft Learn)
「回避策は不要」と即断する
過去の回避策が、単なる障害回避ではなく、監査・長期保存・独自分析のために使われている場合があります。削除前に、なぜその回避策が導入されたのかを確認してください。特に、Blob Storage出力をセキュリティ監査やSIEM連携に使っている場合、標準のsystem_health参照へ戻すだけでは要件を満たせないことがあります。
技術意思決定者が見るべきポイント
技術責任者やソリューションアーキテクトは、今回の更新を「SQL MIの細かいドキュメント修正」として流すのではなく、運用標準化の機会として見るべきです。
| 立場 | 確認すべき観点 |
|---|---|
| 開発者 | 障害時にDB内部イベントを確認する手順が最新か |
| DBA | system_health読み取り手順と権限設計が正しいか |
| クラウド管理者 | Azure SQL Managed Instanceごとの監視・ログ取得方針に差がないか |
| SRE | インシデント対応Runbookから古い回避策を削除できるか |
| アーキテクト | 移行後の監視設計に標準セッションをどう組み込むか |
| 技術意思決定者 | 独自運用の維持コストと標準機能への回帰メリットを比較する |
判断の軸は、「標準機能で十分な調査ができるか」「独自セッションを残す明確な理由があるか」です。標準機能で足りるなら手順を簡素化し、独自要件があるなら目的を明文化して継続するのが現実的です。
今すぐ行うべきアクション
まず、Azure SQL Managed Instanceを使っている環境で、system_healthの読み取りが現在どのように運用されているかを棚卸ししてください。次に、検証環境でsys.fn_xe_file_target_read_file('system_health*.xel', NULL, NULL, NULL)を使った確認クエリを実行し、権限・結果・SSMSでの表示を確認します。
そのうえで、次の3つを更新すると効果が大きいです。
| 更新対象 | 更新内容 |
|---|---|
| 障害対応Runbook | エラー40538前提の古い手順を見直す |
| 監視設計書 | system_health、Azure Monitor、独自XEventの役割を整理する |
| 移行チェックリスト | SQL Managed Instance移行後のsystem_health確認手順を追加する |
今回のGitHub公式ドキュメント更新は、派手な新機能ではありません。しかし、障害調査や移行後運用では、こうした既知問題のステータス変更が手順の正確性を左右します。Azure SQL Managed Instanceを運用しているなら、標準のsystem_healthを読める前提で手順を再確認し、不要になった回避策と残すべき独自運用を切り分けることが次の一手です。
コメント