はじめに
Oracleデータベースの運用において、AWR（Automatic Workload Repository）レポートやStatspackから取得したパフォーマンス情報を定期的に分析することは、トラブル予兆の早期検知や安定稼働の実現に欠かせません。さらに、障害発生時の原因究明においても、これらのレポートは極めて有効です。
本記事では、Oracle初心者でも理解しやすいAWRレポートの基本的な見方や解析のポイントを解説します。これからOracle性能診断に取り組む方はぜひ参考にしてください。
AWRとは？
AWR（Automatic Workload Repository、自動ワークロードリポジトリ） とは、Oracle Databaseの性能情報を自動的に収集・保存する仕組みです。CPU使用率、メモリ使用率、I/O待ち時間など、Oracleインスタンス全体のワークロード統計をレポートとして出力します。
AWRレポートを活用することで、
- データベースが正常に稼働しているかの確認
- 性能劣化の兆候把握
- 障害発生時の原因解析
といった用途に役立ちます。ただし、AWRを利用するには Oracle Enterprise EditionのDiagnostics Packライセンス が必要な点に注意しましょう。
AWRによる情報取得は、MMON（Manageability Monitor）プロセス が SGA（System Global Area） から統計情報を収集・フィルタリングし、SYSAUX表領域 に スナップショット として保存することで行われます。
デフォルト設定：
- スナップショット間隔：60分 ※最小間隔は10分
- 保管期間：8日間 ※上限値はないが、SYSAUX表領域に格納されるため容量に注意
AWRレポート取得方法
AWRレポートの取得方法についてはここでは詳細を割愛しますが、AWRはスナップショット取得間隔（デフォルト60分）で収集した統計情報を、レポートとして出力できます。出力形式には HTMLやテキストがあり、用途に応じて使い分け可能です。
また、Oracleではレポート生成用のスクリプトが複数提供されており、SQL*Plusから簡単に実行できます。私は複数のAWRレポートをまとめて確認することが多いため、get_awr_base.sqlを利用しています。
AWRレポート取得に関する具体的な手順やスクリプト例は、以下の参考サイトが分かりやすいので、必要に応じて確認してみてください。
https://blogs.oracle.com/otnjp/post/kusakabe-014-awr-report-pdb
https://bismarc256.hateblo.jp/entry/2019/11/13/200000
AWRレポートの解析観点
AWRレポートには多くの性能情報が記載されていますが、すべてを詳細に理解する必要はありません。まずは「どのような情報が含まれているか」を把握しておくことが重要です。AWRレポートは大きく以下の3つのセクションに分かれています。
- 基本情報：データベース名、インスタンス名、稼働時間などの環境情報
- レポートサマリ：主要な統計情報の概要
- メインレポート：CPU、メモリ、I/O、SQLごとの詳細な性能統計
これらのセクションを押さえておくことで、AWRレポート全体の構造を理解しやすくなります。
少し補足すると、性能問題が発生したときにAWRレポートを取得しても、それ単体では「どの値が異常なのか」を判断するのは難しい場合があります。
そのため、正常時のAWRレポートを事前に取得し、比較できる環境を整えておくことが重要です。定期的にAWRレポートを保存しておくことで、問題発生時の原因分析を迅速に進められます。
AWRレポートの解析フロー
AWRレポートには多数の統計情報が含まれていますが、最初からすべてを確認する必要はありません。効率よく性能問題を特定するためには、全体像を把握してから原因を掘り下げていくことが重要です。
私が障害調査でAWRレポートを確認する際は、概ね以下の流れで解析を進めています。
① DB Time・Load Profileでデータベース全体の負荷を確認
② Top 10 Foreground Eventsでボトルネックを特定
③ 負荷の原因となっているSQLを確認
④ OSメトリクス（CPU・メモリ・I/O）と照らし合わせて総合的に判断
① DB Time・Load Profileで全体の負荷を確認
まずはデータベース全体の負荷状況を確認します。
特に DB Time は性能分析で最も重要な指標の一つです。通常時と比較してDB Timeが大きく増加している場合は、データベース内部で何らかの処理が滞留している可能性があります。
また、Load Profileでは以下のような項目を確認します。
- DB CPU
- Logical Reads
- Physical Reads
- Redo Size
- Hard Parses
- Transactions
これらの値が通常時と比較して大きく変化していないかを確認します。
② Top 10 Foreground Eventsでボトルネックを特定
次に、どの待機イベントに時間を費やしているかを確認します。
例えば、
- db file sequential read が増加している場合はストレージI/OやSQL実行計画
- log file sync が多い場合はREDO書き込み
- gc current block busy が多い場合はOracle RACのブロック競合
など、待機イベントからボトルネックの方向性を把握できます。
③ 負荷の原因となっているSQLを確認
ボトルネックが見えてきたら、その原因となっているSQLを確認します。
AWRレポートには、
- Elapsed Time
- CPU Time
- Buffer Gets
- Disk Reads
- Executions
などのSQL統計が掲載されています。
特定のSQLがCPUやI/Oを大量に消費していないかを確認し、必要に応じて実行計画や索引設計を見直します。
④ OSの性能情報とあわせて総合的に判断
最後に、OSレベルの性能情報と照らし合わせます。
例えば、
- CPU使用率（sar、vmstat）
- メモリ使用率
- ディスクI/O（iostat）
- ネットワーク帯域
などを確認することで、Oracle内部だけでは判断できない要因を特定できる場合があります。
Oracleの待機イベントとOSメトリクスを組み合わせて分析することで、より正確にボトルネックを特定できます。
AWRレポートの詳細説明
それでは、AWRレポートに記載されている主要な項目を説明していきます。
基本情報
AWRレポートの冒頭には、データベースおよび環境に関する基本情報が記載されています。ここでは、データベースサーバの CPU数、メモリ容量、インスタンス数 などを確認できます。
| 主な項目 | 説明 | 備考 |
|---|---|---|
| RAC | Oracle RACの適用有無 | |
| CPUs | CPU数 | |
| Cores | コア数 | |
| Memory (GB) | メモリ搭載容量 | |
| Begin Snap | AWRスナップショット取得開始時間。Sessionsに開始時のセッション数が記録されます。 | |
| End Snap | AWRスナップショット取得終了時間。Sessionsに終了時のセッション数が記録されます。 | 開始時と終了時でSession数が大きく変わっていない、つまり負荷が一定であったかどうかを確認しましょう。 |
| Elapsed | AWRレポート取得期間。 | デフォルトでは60分。 |
| DB Time | ざっくりいうと、Oracleが実際に処理していた時間です。正確には、AWRレポート取得期間中のOracleサーバプロセスのCPU時間と待機イベント時間の合計となります。CPUコア数が2以上の場合はDB TimeはそれぞれのCPUに対して加算されていくので、Elapsed×CPUsが最大の負荷可能時間となります。ただしバックグラウンドプロセスの情報は含まれません。 計算式：DB Time = DB CPU + non idle wait time | 通常時と比較して、極端にDB Timeが大きくなっていないことを確認しましょう。 |
Report Summary
Top ADDM Findings by average Active Sessions
ADDM（Automatic Database Diagnostic Monitor）の上位診断結果となります。Topに来ているTaskの傾向が通常時と大きく変わっていないことを確認します。
| 主な項目 | 説明 | 備考 |
|---|---|---|
| Avg active sessions of the task | タスクのセッションに要した時間 | セッションに要した時間が増えていないかどうかを確認しましょう。 |
| Percent active sessions of findings | DB timeを占める割合が多い処理ごとの割合 | DBタイムを占めているタスクが正常時と異なっていないことを確認しましょう。 |
Load Profile
Load ProfileはAWRレポート内でもデータベース負荷の傾向を把握するための重要セクションです。ここには DB Time、DB CPU、Logical/Physical Reads、Redoサイズ、トランザクション数、パース数 といった負荷指標がまとまって掲載されます。これらの数値を注意深く確認することで、性能劣化やI/Oボトルネック、CPU飽和などの兆候を早期に検出できます。次節では「Load Profileでまず見るべき主要項目」を具体的に解説します。
| 主な項目 | 説明 | 備考 |
|---|---|---|
| DB Time | AWRレポート取得期間中にOracleサーバプロセスのCPU時間と待機イベント時間の合計。 | |
| DB CPU | AWRレポート取得期間中にOracleサーバプロセスのCPU時間。つまりDB Timeから待機イベント時間を差し引いた値となります。 | |
| Redo size | DML（INSERT, UPDATE, DELETE）実行によって生成されたREDOログのサイズを示しています。 | 正常時より値が大きくなっていた場合、不要なDMLが発行されていないか確認しましょう。 |
| Logical read | 論理読み込みに成功したブロック数 | SGAのバッファキャッシュにデータが残っている場合はそのデータを読み込むことで物理ディスクからの読み込みを低減させます。 |
| Physical reads | 物理ディスクから直接読み込みしたブロック数 | 物理ディスクからの読み込みが多くなると性能劣化する可能性がありますので確認してみて下さい。 |
| Physical writes | データファイルへ書き込まれたブロック数（DBWRなどによる書き込みを含む） | 物理ディスクからの書き込みが多くなると性能劣化する可能性がありますので確認してみて下さい。 |
| User calls | ユーザからのコール数 | 急激に値が上がっていた場合は、ユーザ操作で何が起こっているかを確認しましょう。 |
| Parses（SQL） | ハードパースとソフトパースの回数 | パースとは解析を意味しており、SQL文の構文チェックが実施されます。 |
| Hard Parses | ハードパースの回数 | ハードパースでは、SQL文の構文チェック、テーブルや列の定義および権限チェック、そして実行計画の作成が行われます。ハードパースの割合が増えると、性能に影響を及ぼす可能性があります。CPUの種類やコア数によって異なるため一概には言えませんが、1秒間に100回以上のハードパースが発生している場合は、実行しているSQL文を確認することを推奨します。 なお、ソフトパースの回数は直接表示されませんが、「Parses – Hard Parses」の差分で算出することが可能です。 |
| Executes | SQL実行数 | ユーザが発行したSQLだけではなく、Oracle内部処理のSQL実行数も含まれます。 |
| Transactions | トランザクション数 |
Instance Efficiency Percentages (Target 100%)
このセクションでは、バッファキャッシュやライブラリキャッシュがどの程度効率的に利用されているかが示されます。キャッシュヒット率が低下したり、ソフトパースの割合が減少すると、性能劣化の要因となる可能性があります。そのため、アプリケーションのリリースやOracleパッチの適用など、システムに変更を加えた際には特に注意して確認することを推奨します。
このセクションの各種Hit Ratioは、キャッシュ利用効率を把握するための参考指標です。ただし、Hit Ratioが高いからといって性能に問題がないとは限りません。たとえば、Buffer Hit %が100%近くでデータの読み込み効率が高くても、SQLの実行計画が再利用されずにハードパースが頻発している場合は、CPU負荷の増加によって性能問題が発生することがあります。性能分析では、まずDB TimeやTop Foreground Eventsなどでボトルネックを特定し、そのうえでHit Ratioを補助的な情報として確認することが重要です。
| 主な項目 | 説明 | 備考 |
|---|---|---|
| Buffer Nowait % | 待ち時間なくバッファキャッシュにアクセスできた処理の割合 | 一般的に95%以上が正常値。 |
| Buffer Hit % | バッファキャッシュにヒットした処理の割合 | 一般的に90%以上が正常値。 |
| Library Hit% | 実行可能なSQLが共有プールに存在していた割合 | 一般的に95%以上が正常値。95%を切っている場合は共有プールの拡張を検討してみて下さい。 |
| Execute to Parse % | パースを再実行せずに再利用できた割合 | |
| Parse CPU to Parse Elapsed % | CPU TimeのうちSQLのパースに消費した割合 | |
| Redo NoWait % | REDOログをすぐに使用するための十分なバッファがあった処理の割合 | 一般的に90%以上が正常値。 |
| In-memory Sort % | ソート処理がメモリ上で実施された割合 | 一般的に90%以上が正常値。 |
| Soft Parse % | ソフトパースの割合 | 一般的に90%以上が正常値 |
参考までにSQLのパース処理（ハードパース、ソフトパース）のフローを図示します。
Top 10 Foreground Events
データベースで発生したイベントのうち、Total Wait Time が大きい順に並べた情報です。性能問題が発生した際には、ボトルネックとなっているイベントを特定できる可能性があるため、注意して確認することをおすすめします。
ここでは、よく見かける Top 10 イベントを記載しますので、参考にしてください。
| 主な項目 | 説明 | 備考 |
|---|---|---|
| DB CPU | CPUが動作しているイベント。 Total Wait Time(sec) = 各CPUコアのCPU動作の時間の総和 | DB CPUが上位で、待機イベントが極端に増えていない場合はCPUが主体となって正常に処理できている状態と考えられます。DB CPU以外のイベントがTopに来ている場合にはボトルネックとなっている可能性がありますので確認してみて下さい。 |
| db file sequential read | シングルブロック読み取りが発生した際に発生する待機イベント | 非効率なインデックススキャン、行連鎖、行移行によって無駄なI/Oが発生する場合に待機が発生します。 |
| db file scattered read | マルチブロック読み取りが発生した際に発生する待機イベント | 本待機イベントが発生する要因はdb file sequential readと同様です。 |
| log file sync | Commitを要求してからLGWRプロセスによるREDOのストレージへの書き込みが発生する際の待機イベント | 主に過度なコミット発行、あるいはLGWRのI/O処理によって待機が発生します。頻繁なREDOログファイルスイッチにより待機が発生することもあります。 |
| enq: SV – contention | 要求されたシーケンス番号を取得する待機イベント | |
| gc current/cr block busy | RAC構成において、currentブロックまたはcrブロックが転送される過程で競合が発生したことによる待機イベント | 競合が発生する要因としては、要求されたブロックがローカルプロセスによって使用されていることや、REDOログの記録処理が遅延したことが挙げられます。 |
まとめ
本記事では、Oracleデータベース運用で重要な AWRレポート の基本と解析ポイントを解説しました。
- AWRとは
CPU使用率、メモリ使用率、I/O待ちなどの性能情報を自動収集する仕組みで、性能劣化の兆候把握や障害原因の特定に有効です。 - 主な解析ポイント
- 基本情報：CPU数、メモリ、インスタンス数、スナップショット期間
- Load Profile：DB Time、DB CPU、Logical/Physical Reads、Redoサイズ
- Instance Efficiency Percentages：キャッシュ効率やパース割合
- Top 10 Foreground Events：ボトルネックとなる待機イベントの確認
- 実務での活用
正常時レポートとの比較や、アプリ・パッチ適用後の確認を習慣化することで、トラブルの早期検知と迅速な原因分析が可能です。
AWRレポートは膨大な情報を含んでいますが、すべてを一度に理解する必要はありません。まずはDB Time、Load Profile、待機イベントという主要なポイントを押さえ、正常時との比較を習慣化することが性能問題の早期発見につながります。
参考文献
AWRを基本からおさらいしよう
https://speakerdeck.com/oracle4engineer/awrwoji-ben-karaosaraisiyou
基本からわかる！高性能×高可用性データベースシステムの作り方 第13回 AWRレポート作成とAWRスナップショット取得（CDB全体）
Performance Tuning Basics 15 : AWR Report Analysis
DBA NET
Oracle待機イベント情報
引用：https://community.sap.com/t5/technology-blogs-by-sap/awr-reports-part-i-10-most-important-bits/ba-p/13125127
引用：https://jazz.net/wiki/bin/view/Deployment/RequirementsManagement70Performance
引用：https://www.dbanet.co.za/Summary/awr_load_profile.html
引用：https://www.dbanet.co.za/Summary/awr_top10_foreground_events.html
Japanese 
English
コメント