Database watcherの変更制限は11月9日：Azure SQL監視をDatabase Hubへ移す前の検証

結論：変更制限前に構成を固定し、監視機能を一項目ずつ検収する

編集上の判断：watcher、SQLターゲット、データストア、ネットワーク接続、認証、ダッシュボード、アラートを一つの台帳にまとめます。とくに、再構築やDR時にwatcherを新規作成するIaCが残っていないかを確認してください。既存リソースが動き続けることだけでは、同じ構成を再作成できるとは判断できません。

編集上の提案：Database Hubを並行評価し、必要な対象・指標・期間・通知先が揃うまで旧監視の停止を承認しない運用を提案します。本記事は個別環境の設計保証や法的助言を行いません。実装適用には検証環境での事前テスト、および委託・支援を含む業務範囲の確認が必要です。

背景と技術的要因：監視インフラの管理方式が変わる

確認済み事実：Microsoftの廃止発表はDatabase watcherをGAに移行せず、Database Hubを移行先として案内しています。新方式の性能監視はMicrosoft管理の基盤を使用します。編集上の技術評価：利用者が管理してきたデータストアやクエリの前提をそのまま引き継げるとは限らず、保存と通知の設計を再確認する必要があります。

確認済み事実：Database Hubのテレメトリ資料は、プレビュー中にエンドポイント、スキーマ、テーブル名・列名が変わり得ると注意しています。また、クエリ本文・プラン・クエリ単位の統計はテレメトリに含まれず、Query Storeの利用を案内しています。編集上の提案：旧KQLの構文が通るかだけでなく、同じ運用判断ができるデータかを比較します。

具体的な日付・対象：11月の編集制限と翌年の収集停止を分ける

確認済み事実：公式発表日は2026-10-27です。2026-11-09から新しいwatcherの作成と既存リソースの編集がブロックされ、既存の収集は移行期間中継続します。2027-04-30に既存watcherは停止状態となり、性能監視データの収集を終了し、以後は起動できません。対象はAzure SQL Database、Elastic Pool内のデータベース、Azure SQL Managed Instance向けのDatabase watcherです。

確認済み事実：日本語のDatabase Hub有効化資料は、資産として表示できても、Managed Instance、Elastic Poolやそのデータベース、セカンダリレプリカ等では性能監視の制約があると記載しています。廃止発表の機能追加予定を、提供完了の証明として扱いません。必要な対象が実際に対応したことを確認して移行判断を行います。

確認済み事実：本記事で参照する日本語の有効化・監視・テレメトリ資料はいずれも表示更新日2026-10-05です。記事公開日・確認日は2026-11-03です。廃止発表の最終更新日、制限開始の時刻・段階展開、API版ごとの例外は確認できずnullです。資料更新日を変更の適用日や機能のGA日と同一視しません。

設計・実装：IaC、SQL設定、RBACとクエリを別々に移行する

編集上のIaC確認事項：Microsoft.DatabaseWatcher/watchersを作成・更新するBicep、Terraform、復旧スクリプトを検索し、11月9日以後の再適用・再作成に依存する工程を見直します。APIバージョンを変更すれば制限を回避できるとは本記事では確認していません。既存構成を保存し、移行先の対応API・プロバイダーを検証してから変更してください。

確認済み事実：Azure SQL Databaseでは、各対象ユーザーデータベースにMS_EnablePerformanceMonitoringPreview拡張プロパティを設定するか、Database Hubで性能監視を有効にする手順が案内されています。Microsoft.Sqlの登録も必要です。masterに同じスクリプトを実行しないよう公式資料が注意しています。

確認済み事実：閲覧には既存のMicrosoft Entra IDとAzure RBACが使われ、各対象サブスクリプションのReaderまたは上位権限等が前提です。編集上の提案：管理者だけで確認せず、当番担当者と委託先の実際のIDで必要範囲が見えるかを試験します。アクセス権拡大を収集不備の一般的な解決策にせず、登録・有効化・対象制約と切り分けます。

編集上のクエリ移行案：リソース識別子、時刻、集計間隔、単位、欠損値、プライマリ・セカンダリの扱いを対応表にします。CPUや接続等の代表指標で旧監視と比較し、Query Storeなど別経路が必要な調査項目も明記してください。新しいスキーマへ列名だけを置換して、同じしきい値を無検証で流用しないことを提案します。

運用・アラート・DR・責任分界：表示、通知、履歴保全を別の完了条件にする

確認済み事実：公式発表は、カスタムダッシュボードに基づくアラートをSQL monitorとFabric Activatorで再構成する経路を案内し、この経路にはFabric容量が有効なワークスペースを要求しています。編集上の提案：性能監視を有効にする費用の説明だけで移行全体を無料と判断せず、通知経路と容量を個別に見積もります。

編集上の受入試験：検証環境で承認した負荷・接続異常等を再現し、テレメトリ到着、しきい値評価、通知、当番への到達、復旧後の解除を一連で確認します。過去のデータが表示されることだけを現在の監視成功とせず、最終サンプル時刻と収集対象数を確認してください。通知が来ない場合は、データ未収集と評価・通知の失敗を分けて調べます。

確認済み事実：廃止で既存のADXやFabric Eventhouseが自動停止・削除されるわけではなく、保持設定と費用は継続し得ます。編集上の提案：他用途との共有を調べ、履歴の保存・検索試験が済んでから廃止対象を決めます。Database Hub側のテレメトリは読み取り専用で保持を変更できないと資料が説明しているため、必要な長期保存は自社ストアへの出力等を検討します。

編集上のDR・責任分界整理：DBのフェイルオーバーや復旧後、対象ID・リージョン・閲覧権限・性能データ・通知が継続するかを試験します。監視復旧時間はDBのRTOと分けて計測してください。DB担当、IaC担当、Fabric管理者、監視担当、委託先の間で、設定変更、機能待ち期間の補完監視、履歴保存、費用停止の担当を確定します。