DP300-CS04#2
【Case Study】Northwind 社 DR + パフォーマンス監視統合
【背景】
Northwind 社は グローバル EC プラットフォーム で Azure SQL Database を運用しており Primary (East US) + DR (West US 2) 構成 で運用中です。最近 ピーク 時間帯 に レスポンス 遅延 + DTU 95% 到達 が発生し パフォーマンス監視 + 自動最適化 強化 を計画 します。
【既存環境】
Azure SQL Database Business Critical 8 vCore (Primary), 同等 (DR), Microsoft Entra ID テナント, Defender for SQL 有効化済み, TDE CMK 運用, Auditing を Central Log Analytics に転送 設定済み。
【要件】
- Query Store + Automatic Tuning で Plan Regression / Missing Index を 自動 対処
- Wait Statistics + Top CPU クエリ を Log Analytics で 統合 分析
- OLTP ピーク 時 の Read Workload を Read-only Replica に分散
- CPU 80% + DTU 80% でアラート + Action Group で 自動 通知
- 夜間バッチ (大規模 集計) は別 Workload Group で リソース 分離
【質問 2/3】
本シナリオで DTU 95% + PAGEIOLATCH_SH 多発 を検出 した場合の根本 対処 として 最も効果的な手段はどれですか?
解説
【正解: B】の理由
PAGEIOLATCH_SH (I/O 遅延) + 高 CPU の同時発生 は Index 不足 で Scan 多発 + Buffer Pool 過剰 Read が主因 の場合が 多 いです。Query Store + sys.dm_exec_query_stats で Top CPU / Top IO クエリを特定 し Performance Recommendations の Missing Index 推奨 を 適用 することで 根本 対処 + 持続的 改善 が実現 できます。
【他選択肢が違う理由】
- A: Tier アップは 一時 対処 で 根本 原因 (Index 不足) 解決 なしでは 再 発します。
- C: ネットワーク制御 で 性能とは別 です。
- D: TLS は通信暗号化 で性能とは無関係 です。

コメント