1. はじめに
Oracleデータベースを運用しているエンジニアとして、AWRやStatspackから取得したパフォーマンス関連の情報を定期的に分析して、トラブルの予兆がないか確認する取り組みは非常に大切です。また、トラブル発生時の原因究明の際にもAWRやStatspackの情報は重宝します。今回は入門者向けにAWRレポートに関する情報を取りまとめておりますので、ぜひご参照ください。
2. AWRレポートとは
AWRとはAutomatic Workload Repositoryの略で日本語だと自動ワークロードリポジトリと略されます。CPU使用率、メモリ使用率、I/OwaitなどのOracleインスタンス全体のワークロードに関する実行統計を出力しているレポートとなります。DBヘルスチェックやトラブル解析の際に用いる非常に有益なレポートとなりますが、AWRの機能を使うためにはEnterprise EditionのDiagnostics Packのライセンス契約が必要となりますので注意して下さい。
AWRによる情報取得の仕組みを紹介します。MMON（Manageability Monitor）プロセスがSGAから各種統計情報を収集してフィルタリングし、SYSAUX領域にAWRのスナップショットを作成しています。デフォルトではスナップショット作成間隔は60分、スナップショット保管期間は8日間となっておりますので、要件によって変更するようにして下さい。また、AWRスナップショットの作成、削除を繰り返すとメモリの断片化が進んで再利用できなくなることがあるので、適切なSYSAUX表領域のサイズを見積もるようにして下さい。
3. AWRレポート取得方法
AWRレポートの取得方法については詳細割愛しますが、スナップショット取得間隔（デフォルトだと60分）の間における統計情報をレポートとして出力させることができます。HTML形式のレポートを作成するツールがいくつか提供されていますので、用途に合わせて使ってみて下さい。私は複数のAWRレポートを出力させることが多いのでget_awr_base.sqlを良く使っています。参考サイトを記載しておきます。
https://blogs.oracle.com/otnjp/post/kusakabe-014-awr-report-pdb
https://bismarc256.hateblo.jp/entry/2019/11/13/200000
4. AWRレポートの解析観点
AWRレポートの主要な項目について説明していきます。全部覚える必要はないですが、どんな性能情報が記載されているか概要を頭に入れておくと良いかと思います。AWRレポートは、基本情報、レポートサマリ、メインレポートのセクションに分かれて記載されておりますので、それぞれ説明していきます。
少し話それますが、性能問題発生時のAWRレポートだけあったとしても、どこの値が異常なのか判別することは難しいので、正常時のAWRレポートを事前に取得しておき、それと比較できるような状況にしておくことが迅速な原因究明につながります。問題がなかったとしても定期的にAWRレポートを取得することを推奨いたします。
4.1 基本情報
データベースおよび環境に関する基本情報が記載されています。データベースサーバのCPU、メモリ、インスタンス数などの情報を確認することができます。
| 主な項目 | 説明 | 備考 |
| 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が大きくなっていないことを確認しましょう。 |
4.2 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
データベース負荷に関する情報がまとまっている重要な情報となります。性能劣化の特定につながる情報が記載されている可能性がありますので注意深く確認してみて下さい。
引用：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パッチ適用などの変更があった際には注意してみるようにして下さい。
引用：https://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が大きい順に並べた情報となります。性能問題発生時にボトルネックとなっているイベントを特定できる可能性がありますので良く見ていただければと思います。
良く見かけるTop10イベントを記載しますので、参考にしてみて下さい。
| 主な項目 | 説明 | 備考 |
| 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
5. まとめ
Oracle AWRレポートに関する記載は以上となります。一般的な記載をしたつもりではありますが、各システムの特性によってリソース使用状況やTop10イベントの内容が変わってくるので、注視すべきポイントも異なってきます。定期的に情報を取得して安定運行しているかどうかを確認する運用を実施していただければと思います。
6. 参考文献
AWRを基本からおさらいしよう
https://speakerdeck.com/oracle4engineer/awrwoji-ben-karaosaraisiyou
基本からわかる！高性能×高可用性データベースシステムの作り方 第13回 AWRレポート作成とAWRスナップショット取得（CDB全体）
Performance Tuning Basics 15 : AWR Report Analysis
DBA NET
Oracle待機イベント情報
コメント