【要約】ADB-S で Exadata IORM が動作したかを追跡してみる。(Oracle Cloud Infrastructure) [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
ADB-S を利用するエンジニアは、プラットフォーム内部の I/O 制御（IORM）がどのように機能しているかを把握しにくいという課題に直面する。ADB-S は Exadata を基盤としており、IORM によって Disk I/O が制御されているが、その詳細な挙動は隠蔽されている。
- ・PaaS 特有のブラックボックス性により、I/O 遅延の原因特定が困難。
- ・AWR レポートや SQL モニターだけでは、IORM の動作を直接的に追跡できないケースがある。
- ・リソース競合が発生した際、それが IORM による意図的な制御なのかを判断する術が乏しい。
// Approach
筆者は、大量のデータ更新処理を実行し、動的ビューの統計値の変化から IORM の介入を特定するアプローチを採用した。標準的な SQL インターフェースを用いて、実行前後のリソース使用状況を比較する手法である。
- ・ATP-S (ECPU=4, Autoscaling 有効) 環境を構築。
- ・1,000万件のテストデータを作成し、大規模な UPDATE 文を実行。
- ・
GV$SYSSTATからPDB IORM disk wait timeなどの特定項目を抽出。 - ・実行前後の統計値の増分を比較し、IORM による待ち時間の発生を検証。
- ・SQL モニターの
Activity Detailと併せて、物理的な Disk I/O 待ちを確認。
// Result
検証の結果、統計値の変化と SQL モニターの解析結果が一致し、IORM の動作を定量的に捉えることに成功した。これにより、ADB-S における I/O 制御の可視化が可能であることを実証した。
- ・
PDB IORM disk wait timeが 240,032 から 266,333 へ増加。 - ・
Session IORM flash wait timeも微増を確認。 - ・SQL モニター上で
cell list of blocks physical readによる Disk I/O 待ちを検出。 - ・
GV$SYSSTATを用いることで、IORM の介入を追跡できることが明確になった。
Senior Engineer Insight
> ADB-S のようなマネージドサービスでは、インフラ層の挙動が隠蔽される。そのため、I/O レイテンシのボトルネックが「アプリケーションのクエリ起因」か「プラットフォームの I/O 制御起因」かを切り分ける能力が求められる。本手法は、追加のツールを必要とせず、標準的な動的ビューのみで実装可能なため、実戦的なデバッグ手法として極めて価値が高い。スケーラビリティの限界を判断する際にも、この視点は不可欠である。