Oracle AWRレポートの見方と解析ポイントを徹底解説｜パフォーマンス改善・トラブル調査に必須

1. はじめに
AWRとは？
AWRレポート取得方法
AWRレポートの解析観点
1. 基本情報
2. Report Summary
まとめ
参考文献

1. はじめに

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分
保管期間：8日間

これらの設定は要件に応じて変更可能です。

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レポートの冒頭には、データベースおよび環境に関する基本情報が記載されています。ここでは、データベースサーバの CPU数、メモリ容量、インスタンス数などを確認できます。

引用：https://community.sap.com/t5/technology-blogs-by-sap/awr-reports-part-i-10-most-important-bits/ba-p/13125127

主な項目	説明	備考
RAC	Oracle RACの適用有無
CPUs	CPU数
Cores	コア数
Memory (GB)	メモリ搭載容量
Begin Snap	AWRスナップショット取得開始時間。Sessionsに開始時のセッション数が記録されます。
End Snap	AWRスナップショット取得終了時間。Sessionsに終了時のセッション数が記録されます。	開始時と終了時でSession数が大きく変わっていない、つまり負荷が一定であったかどうかを確認しましょう。
Elasped	AWRレポート取得期間。	デフォルトでは60分。
DB Time	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の傾向が通常時と大きく変わっていないことを確認します。

引用：https://jazz.net/wiki/bin/view/Deployment/RequirementsManagement70Performance

主な項目	説明	備考
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でまず見るべき主要項目」を具体的に解説します。

引用：https://www.dbanet.co.za/Summary/awr_load_profile.html

主な項目	説明	備考
DB Time	AWRレポート取得期間中にOracleサーバプロセスのCPU時間と待機イベント時間の合計。
DB CPU	AWRレポート取得期間中にOracleサーバプロセスのCPU時間。つまりDB Timeから待機イベント時間を差し引いた値となります。
Redo size	DML（INSERT, UPDATE, DELETE）実行によって生成されたREDOログのサイズを示しています。	正常時より値が大きくなっていた場合、不要なDMLが発行されていないか確認しましょう。
Logical read	論理書き込みに成功したブロック数	SGAのバッファキャッシュにデータが残っている場合はそのデータを読み込むことで物理ディスクからの読み込みを低減させます。
Physical read	物理ディスクから直接読み込みしたブロック数	物理ディスクからの読み込みが多くなると性能劣化する可能性がありますので確認してみて下さい。
Physical writes	物理ディスクから直接書き出したブロック数	物理ディスクからの書き込みが多くなると性能劣化する可能性がありますので確認してみて下さい。
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パッチの適用など、システムに変更を加えた際には特に注意して確認することを推奨します。

引用：h ttps://www.dbanet.co.za/Summary/awr_load_profile.html

主な項目	説明	備考
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がTopに来ている場合は問題なく動作していることが多いですが、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ログの記録処理が遅延したことが挙げられます。

引用：https://www.dbanet.co.za/Summary/awr_top10_foreground_events.html

まとめ

本記事では、Oracleデータベース運用で重要な AWRレポート の基本と解析ポイントを解説しました。

AWRとは
CPU使用率、メモリ使用率、I/O待ちなどの性能情報を自動収集する仕組みで、性能劣化の兆候把握や障害原因の特定に有効です。
主な解析ポイント
- 基本情報：CPU数、メモリ、インスタンス数、スナップショット期間
- Load Profile：DB Time、DB CPU、Logical/Physical Reads、Redoサイズ
- Instance Efficiency Percentages：キャッシュ効率やパース割合
- Top 10 Foreground Events：ボトルネックとなる待機イベントの確認
実務での活用
正常時レポートとの比較や、アプリ・パッチ適用後の確認を習慣化することで、トラブルの早期検知と迅速な原因分析が可能です。