Report Summary はAWRレポートの最初に表示される総覧セクションです。ここで全体像をつかみ、次にどのセクションを見るかを決めます。14項目すべての見方を順に解説します。
1. Database Instance Information— DBインスタンス情報
何を表すか: DB Name / Instance / Release / RAC / 起動時刻 / DB ID 等。レポートが「どのDBで取得されたか」を特定するメタ情報。
- 読み方: DBバージョン（Release）とRAC構成を確認。Startup Time が AWR 期間の途中だと再起動が挟まっているサイン。
- 閾値・注意点: Release 12c と 19c で項目構成が一部異なる。RAC=YES の場合は他インスタンスの AWR も併読すべき。
- 関連セクション: Host Information / Snap Information
- 使うシーン: レポート読み始め最初に確認
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| DB Name | データベースの論理名（DB_NAME 初期化パラメータ） | 複数DB環境で取り違え防止。バックアップ/リカバリ単位 |
| DB Id | DBを一意に識別する32bit数値 | バックアップセット紐付け・複製DB識別 |
| Instance | インスタンス名（ORACLE_SID） | RAC環境でのノード識別 |
| Inst num | インスタンス番号（RAC時1〜N） | RAC構成の判別。1ならシングルか1号機 |
| Startup Time | インスタンス起動時刻 | AWR期間内に再起動があったかを判定 |
| Release | Oracle Database のバージョン | 機能差/バグ可能性の判断。サポート判断 |
| RAC | RAC構成有無（YES/NO） | YESなら他ノードのAWRも併読が必要 |
2. Host Information— ホスト情報
何を表すか: OS名 / プラットフォーム / CPUs / Cores / Sockets / Memory(GB)。AAS/Cores 計算や CPU ボトルネック判定の前提値。
- 読み方: Cores 値が AAS や CPU 使用率の評価基準。Memory(GB) と Cache Sizes を見比べてSGA/PGAの占有率を推測。
- 閾値・注意点: Cores より CPUs（論理コア）が多い場合はハイパースレッディング有効。メモリは物理メモリ、SGA はその一部。
- 関連セクション: Database Instance Information / OS Statistics
- 使うシーン: CPU/メモリ系の評価前に必ず確認
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Host Name | サーバホスト名 | 複数サーバ環境でのレポート取り違え防止 |
| Platform | OS種別（Linux x86 64-bit 等） | OSごとのチューニング指針の前提 |
| CPUs | 論理CPU数（HT含む） | OSスケジューラから見える並列度 |
| Cores | 物理コア数 | AAS閾値の基準。Cores≧AASなら余裕あり |
| Sockets | 物理ソケット数 | NUMA構成の有無。メモリレイアウトに影響 |
| Memory (GB) | サーバの物理メモリ容量 | SGA+PGA総量の上限。50〜70%が目安 |
3. Snap Information— スナップショット情報
何を表すか: Begin Snap / End Snap の番号と時刻、Elapsed (分)、DB Time (分)。AWR の集計区間を特定する。
- 読み方: Elapsed が想定通りか（24時間=1440分）まず確認。
DB Time / Elapsed = AAS（平均アクティブセッション）。 - 閾値・注意点: 夏時間切替やDBMS_AUTO_TASKの自動停止/再起動でスナップが欠落することあり。Begin Snap 時刻=前日 23:00 のような取り違えに注意。
- 関連セクション: AAS / DB CPU(s/s)
- 使うシーン: AAS 計算・期間特定
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Snap Id | スナップショットID（連番） | 差分レポート生成時のキー。欠落の検知 |
| Snap Time | スナップ取得時刻 | 業務ピーク時刻と一致しているか確認 |
| Sessions | スナップ取得時のセッション数 | 接続プール枯渇の兆候検出 |
| Cursors/Session | セッションあたり平均オープンカーソル数 | open_cursors 設定枯渇の予兆 |
| Elapsed (mins) | レポート対象の経過時間（分） | AAS計算の分母。極端に短いと統計の信頼性低下 |
| DB Time (mins) | 全セッションがDBに費やした累積時間 | AASを算出。Cores数を超えると要警戒 |
4. Top ADDM Findings by Average Active Sessions— Top ADDM 検出事項
何を表すか: ADDM（Automatic Database Diagnostic Monitor）が自動診断した上位の問題候補。AAS 影響度順。
- 読み方: DBが自動的に「ここが怪しい」と挙げた候補。検出名に対応する詳細はレポート末尾の ADDM Task セクションへ。
- 閾値・注意点: ADDM の推奨は機械判断なので必ず正しいわけではない。鵜呑みにせず、Foreground Wait Events 等と突き合わせて検証する。
- 関連セクション: Foreground Wait Events / Top SQL / ADDM Task
- 使うシーン: 原因の当たりを早くつけたい時
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Finding Name | ADDMが検出した問題名（例: SQL Statements、CPU Usage） | 調査の優先度判断。検出名でADDM Taskを掘る |
| Avg active sessions of the task | その問題が関係したAAS | 影響度。Cores比で判断 |
| Percent active sessions of finding | 該当タスク内でその問題が占めた割合 | 「真の主因か副次か」を判定 |
| Task Name | ADDMタスクの内部名 | 詳細セクションのリンク先キー |
| Begin/End Snap Time | そのタスクが分析対象とした期間 | 業務イベント時刻との照合 |
5. Load Profile— ロードプロファイル
何を表すか: 1秒あたり / 1トランザクションあたり / 1Execあたり / 1Callあたりの主要負荷指標。DB全体の処理量を一目で把握する最重要表。
- 読み方: Per Second 列が日常感覚で読みやすい。Logical/Physical の比、Parses と Hard Parses の比をまず見る。Exec/sec が異常に高ければ短時間SQL大量実行型ワークロード。
- 閾値・注意点: Per Transaction は短時間サンプルでは不安定。Per Exec/Per Call は Listener 経由ベースなので注意。Redo size が桁違いに大きい場合は大量更新中。
- 関連セクション: Instance Efficiency / Time Model / Top SQL
- 使うシーン: ワークロード性質の把握。比較分析時の基準値
列方向は Per Second / Per Transaction / Per Exec / Per Call の4軸、行方向は以下の指標で構成されます。
主要な行指標と意味・影響
| 指標 | 意味 | 影響箇所・着目点 |
|---|---|---|
| DB Time(s) | DB処理時間（CPU+待機） | 負荷総量の代表値。AASの分子 |
| DB CPU(s) | 純粋なCPU処理時間 | DB Time に対する比率が低いと待機支配型 |
| Logical read (blocks) | 論理ブロック読込（バッファ参照） | Buffer Hit分母。Gets per Exec の傾向把握 |
| Physical read (blocks) | 物理ブロック読込 | I/O量。Logicalとの比でキャッシュ効率を判定 |
| Redo size (bytes) | 生成されたREDO量 | DML負荷の指標。LGWR/REDOディスク性能を要確認 |
| Block changes | 更新されたブロック数 | 更新ワークロードの規模感 |
| User calls | クライアントから来たコール数 | アプリ⇔DB の往復頻度 |
| Parses (SQL) | パース呼び出し回数 | Hard Parseとの比でカーソル再利用を判定 |
| Hard parses (SQL) | 計画作成までやり直したパース | 多いとShared Pool競合、バインド変数未使用の兆候 |
| Logons | 新規ログオン回数 | コネクションプール未使用の兆候 |
| Executes (SQL) | SQL実行回数 | OLTP性。Parses比率で再利用効率を判定 |
| Rollbacks | ロールバック発生数 | 多いとアプリエラー or デッドロック多発 |
| Transactions | コミット+ロールバック総数 | 業務トランザクション量の代表値 |
6. Instance Efficiency Percentages (Target 100%)— インスタンス効率指標
何を表すか: Buffer Hit / Library Hit / Soft Parse / Latch Hit / Redo NoWait など、SGA・ライブラリキャッシュの効率を一覧化。
- 読み方: Buffer ≥90%、Library ≥95%、Soft Parse ≥95% が一般的な目安。Latch Hit は通常99%以上、それ未満は内部競合のサイン。
- 閾値・注意点: 「100%が理想」という名称だが、Hit%だけで判断するのは危険。物理I/O量が少なければ Buffer Hit が低くても問題ない場合あり。指標は他と合わせて読む。
- 関連セクション: Buffer Pool Statistics / Library Cache Activity / Latch Statistics
- 使うシーン: 効率劣化のスクリーニング
代表指標の意味・閾値
| 指標名 | 意味 | 影響箇所・閾値目安 |
|---|---|---|
| Buffer Nowait % | バッファ取得時に待機なしで取れた割合 | 低いとBuffer Busy。99%以上が目安 |
| Redo NoWait % | REDOバッファ書込が待機なしで成功した割合 | 低いとREDOバッファ不足 |
| Buffer Hit % | 論理読込のうちキャッシュ命中の割合 | キャッシュ効率。90%以上が目安 |
| In-memory Sort % | メモリ内でソート完結した割合 | 低いとPGA不足。Tempスパイル発生 |
| Library Hit % | SQL/Plan のライブラリキャッシュヒット率 | 低いとハードパース多発 |
| Soft Parse % | 全パースのうちソフトパースの割合 | 95%以上が目安。低いとShared Pool競合 |
| Execute to Parse % | 実行回数とパース回数の比 | 高いほどカーソル再利用が効いている |
| Latch Hit % | ラッチ取得成功率 | 99%以上が目安。内部競合の指標 |
| Parse CPU to Parse Elapsd % | パース時間のCPU比率 | 低いとパース中の待機（Mutex等）あり |
| % Non-Parse CPU | パース以外でのCPU使用比率 | 高いほど健全（業務処理に時間が使われている） |
7. Top 10 Foreground Events by Total Wait Time— Top 10 待機イベント
何を表すか: ユーザ（Foreground）セッションが待たされた上位10イベントを Total Wait Time 降順で表示。「何で待っているか」が一目で分かる。
- 読み方: DB CPU を除いた1位が支配的待機。% DB time ≥30% で「中」、≥50% で「高」レベル。Avg Wait の桁（ms単位）も同時確認。
- 閾値・注意点: DB CPU は厳密には待機ではないがここに混在する。「DB CPU だけが上位」の場合は CPU 飽和型ワークロード。
- 関連セクション: Foreground Wait Events（詳細）/ Wait Event Histogram / Top SQL by Elapsed Time
- 使うシーン: ボトルネック調査の最初の入口
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Event | 待機イベント名（db file sequential read など） | ボトルネックの性質を即座に判別 |
| Waits | 待機発生回数 | 頻度。回数×Avg Wait=Total Wait Time |
| Total Wait Time (sec) | 累積待機時間（秒） | ランキングの基準。最も影響大の指標 |
| Wait Avg(ms) | 1回あたり平均待機時間 | 個別待機の重さ。10ms超のI/Oは要注意 |
| % DB time | DB Timeに占めるその待機の割合 | 30%以上で要注目、50%以上で高負荷 |
| Wait Class | 待機クラス分類（User I/O、Concurrency等） | 大分類でのボトルネック傾向把握 |
8. Wait Classes by Total Wait Time— 待機クラス別集計
何を表すか: 待機イベントを Wait Class（User I/O / Concurrency / Application 等）でグループ化した集計。クラス単位での偏在を見る。
- 読み方: User I/O が支配的なら物理I/O系、Concurrency が大きければ内部競合、Application は明示的なロック競合（FOR UPDATE 等）。
- 閾値・注意点: クラス分類は Oracle が自動で振っており、特殊イベントは「Other」に紛れる。「Other」が大きい場合は Foreground Wait Events を直接確認。
- 関連セクション: Foreground Wait Class（詳細）/ Top 10 Foreground Events
- 使うシーン: ワークロード性質の大まかな分類
実カラムと代表的なWait Class
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Wait Class | 待機クラス名 | 下表参照 |
| Waits | そのクラスの待機回数合計 | 頻度規模 |
| Total Wait Time (sec) | クラスごとの累積待機時間 | ランキング基準 |
| Avg Wait (ms) | 1回あたり平均待機時間 | クラス内の平均的な「重さ」 |
| % DB time | DB Timeに占める割合 | 支配的クラスの判定 |
| Avg Active Sessions | そのクラスでの平均アクティブセッション数 | 並列度。Cores比で判定 |
代表的なWait Classの意味
| Wait Class | 意味 | 典型的な原因 |
|---|---|---|
| User I/O | ユーザSQLによる物理I/O待ち | ストレージ性能・Buffer Cache不足・SQL非効率 |
| System I/O | バックグラウンドプロセスのI/O待ち | DBWR/LGWR/ARCH 等の書込み |
| Concurrency | 内部競合（ラッチ・Mutex等） | Shared Pool競合・ハードパース多発 |
| Application | アプリ起因のロック競合 | FOR UPDATE・行ロック保持時間長 |
| Commit | コミット同期待ち（log file sync） | コミット頻度・REDO ディスク性能 |
| Configuration | 設定起因（ログサイズ不足等） | 初期化パラメータ・REDOサイズ |
| Network | ネットワーク待ち（SQL*Net等） | NW帯域・往復頻度 |
| Cluster | RACのGlobal Cache待ち | RAC構成での通信ボトルネック |
| Other | 分類されない待機 | 特殊イベント。詳細はForeground Wait Eventsを参照 |
9. Host CPU— ホストCPU使用率
何を表すか: OS全体の CPU 使用率（User/System/Idle/WaitIO 等）、Load Average。Begin/End スナップ時点の瞬間値が表示される。
- 読み方: WIO%（Wait I/O）が高いとI/Oボトルネック。System% が User% を超えるならカーネル処理過多（頻繁な fork/syscall 等）。
- 閾値・注意点: Begin/End の2点しか出ない。期間中の平均は OS Statistics - Detail で確認。
- 関連セクション: OS Statistics / OS Statistics - Detail
- 使うシーン: OSレベルでのCPU状況確認
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| CPUs / Cores / Sockets | 論理/物理CPU構成 | AAS判定の前提値 |
| Load Average Begin/End | OS Load Average の2点測定値 | Cores超えなら過負荷 |
| %User | ユーザモードCPU使用率 | 業務処理が占める部分 |
| %System | カーネルモードCPU使用率 | システムコール/IO多発の指標 |
| %WIO | I/O待機中のCPU割合 | 高いとストレージボトルネック |
| %Idle | アイドル率 | 余力。低いと余裕なし |
10. Instance CPU— DBインスタンスCPU使用率
何を表すか: そのDBインスタンスが消費した CPU 時間と、ホスト全体に占める割合。RACでないシングル環境では実質ホスト = インスタンス。
- 読み方: Host利用率 > インスタンス利用率 なら、他プロセスや OS も CPU を使っている。差が大きい場合は同居プロセス調査。
- 閾値・注意点: DB Time に含まれない非CPU待機（I/O waits等）はここに反映されない。
- 関連セクション: Host CPU / OS Statistics
- 使うシーン: DBがホストCPUをどれだけ使っているか確認
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| %Total CPU | このインスタンスが消費したホストCPU比率 | 同居プロセスとの差分を判定 |
| %Busy CPU | Busy時間のうちこのインスタンス分 | 稼働時間ベースでの占有率 |
| %DB time waiting for CPU (Resource Manager) | リソースマネージャによる待機割合 | RM設定が想定通りかの確認 |
11. IO Profile— I/Oプロファイル
何を表すか: Read/Write の総量（秒あたり）。Total / Read / Write の3行で、Requests と MB を表示。
- 読み方: Read Requests が支配的なら検索系、Write が大きければ更新系。MB/s が大きく Request 数が小さければ大ブロック転送（Full Scan等）。
- 閾値・注意点: ストレージのキャッシュは見えない（DB側からの発行ベース）。
- 関連セクション: Tablespace IO Stats / File IO Stats / IOStat by Function
- 使うシーン: I/O 規模の把握
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Read+Write Per Second | 合計I/Oスループット | ストレージ全体の負荷 |
| Read per Second | 読込スループット | 多いと検索ワークロード型 |
| Write Per Second | 書込スループット | 多いと更新ワークロード型 |
12. Memory Statistics— メモリ統計
何を表すか: ホストメモリと SGA/PGA の割当・使用状況を Begin/End スナップで比較。
- 読み方: Begin と End の差が大きければメモリ動的調整が発生。SGA+PGA がホストメモリの大半を占めるなら他プロセスが圧迫を受ける可能性。
- 閾値・注意点: AMM（Automatic Memory Management）環境では SGA/PGA の比が動的変化する。Resize 履歴は Memory Statistics の Resize Ops で確認。
- 関連セクション: Memory Dynamic Components / SGA Memory Summary / PGA Aggr Summary
- 使うシーン: メモリ割当の確認
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Host Mem (MB) | サーバの物理メモリ容量 | SGA+PGA総量の上限 |
| SGA use (MB) | System Global Area の使用量 | 共有メモリ（Buffer Cache等） |
| PGA use (MB) | Program Global Area の使用量 | セッション専用領域の総和 |
| % Host Mem used for SGA+PGA | ホストメモリに占めるDB割合 | 50〜70%が目安。超えるとOS圧迫 |
13. Cache Sizes— キャッシュサイズ
何を表すか: Buffer Cache / Shared Pool / Std Block Size / Log Buffer の Begin/End 値。
- 読み方: Begin と End の差で動的Resize の発生を検知。Standard Block Size は通常 8KB（8192）。
- 閾値・注意点: Buffer Cache が極端に小さい（数百MB）と Buffer Hit % が下がりやすい。
- 関連セクション: Memory Dynamic Components / Buffer Pool Advisory / Shared Pool Advisory
- 使うシーン: サイジング確認・調整履歴
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Buffer Cache (M) Begin/End | データブロックキャッシュサイズ | Buffer Hit % に直結 |
| Shared Pool (M) Begin/End | Library Cache等の共有メモリ領域 | SQL実行計画キャッシュサイズ |
| Std Block Size | 標準ブロックサイズ（通常8192バイト） | I/O単位。変更にはDB再作成が必要 |
| Log Buffer | REDOログバッファサイズ | 大きすぎても効果薄。デフォルト推奨 |
14. Shared Pool Statistics— Shared Pool 統計
何を表すか: Shared Pool の Memory Usage / % SQL with executions>1 / % Memory for SQL w/exec>1 を Begin/End で表示。
- 読み方: Memory Usage が常時 90% 超なら Shared Pool 不足傾向。% SQL w/exec>1 が低い（50%未満）と「使い捨てSQL」が多く、リテラルSQL/ハードパース過多のサイン。
- 閾値・注意点: Memory Usage 100% は必ずしも悪くない（Oracleは積極的にキャッシュする）。継続的な高位 + ORA-04031 発生で初めて問題。
- 関連セクション: Soft Parse % / Library Hit % / Shared Pool Advisory
- 使うシーン: ハードパース過多の傍証
実カラムと意味・影響
| 項目名 | 意味 | 影響箇所・着目点 |
|---|---|---|
| Memory Usage % | Shared Pool の使用率 | 90%超持続でShared Pool枯渇の予兆 |
| % SQL w/exec>1 | 2回以上実行されたSQLの割合 | 低いと使い捨てSQL多発（バインド未使用） |
| % Memory for SQL w/exec>1 | 再利用SQLが占めるメモリ比率 | 低いとShared Pool効率低下 |