この記事の要点

Oracle のパフォーマンスチューニングは「計測 → 原因特定 → 改善 → 再計測」のサイクルで進める 基本道具: 実行計画 (EXPLAIN PLAN / DBMS_XPLAN)、SQL トレース (10046)、AWR / Statspack、ASH 統計情報の鮮度が最重要: DBMS_STATS.GATHER_TABLE_STATS で定期収集。古い統計はオプティマイザの誤判断を招く インデックス設計: 選択性の高い列に B-tree、低カーディナリティで AND/OR 多用ならビットマップ 待機イベントから根本原因を絞る: db file sequential read (索引アクセス) / db file scattered read (フルスキャン) / log file sync (COMMIT) など

Oracle パフォーマンスチューニングの全体像

Oracle のパフォーマンスチューニングは、闇雲に「インデックスを足す」「メモリを増やす」では失敗します。計測してボトルネックを特定 → 改善 → 効果を再計測するサイクルで進めるのが原則です。

パフォーマンス関連トピック一覧

カテゴリ	具体的なトピック
SQL 単位の分析	実行計画、SQL トレース、SQL Tuning Advisor、ヒント
インスタンス単位の分析	AWR / ADDM / Statspack、待機イベント、V$ ビュー
セッション単位の分析	ASH (Active Session History)、V$SESSION、V$SESSION_WAIT
統計情報	DBMS_STATS、ヒストグラム、自動統計収集ジョブ
インデックス設計	B-tree、ビットマップ、関数索引、複合インデックス、IOT
表領域 / I/O	表領域配置、ASM、データファイル I/O 分散
メモリ	SGA (バッファキャッシュ / 共有プール) / PGA、AMM / ASMM
並列処理	パラレルクエリ、パラレル DML、パラレルパーティション
パーティショニング	レンジ / リスト / ハッシュ、Partition pruning
その他	マテリアライズドビュー、Result Cache、In-Memory オプション

1. SQL の実行計画を見る

-- SQL の実行計画を取得
EXPLAIN PLAN FOR
  SELECT * FROM emp WHERE deptno = 10;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

-- 実際に実行された計画 (より正確)
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ALLSTATS LAST'));

注目する項目: Cost、Rows (見積もり vs 実数)、Access Predicate、Filter Predicate、テーブルアクセス方法 (TABLE ACCESS FULL / INDEX RANGE SCAN など)。

2. 統計情報の鮮度確認と更新

-- 統計情報の最終収集日
SELECT table_name, num_rows, last_analyzed
  FROM dba_tables
 WHERE owner = 'SCOTT';

-- 単一表の統計収集
EXEC DBMS_STATS.GATHER_TABLE_STATS(
       ownname => 'SCOTT', tabname => 'EMP',
       estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
       method_opt => 'FOR ALL COLUMNS SIZE AUTO',
       cascade => TRUE);

3. 待機イベントから原因を絞る

-- インスタンス全体の待機イベント Top10
SELECT event, total_waits, time_waited / 100 AS sec_waited
  FROM v$system_event
 ORDER BY time_waited DESC FETCH FIRST 10 ROWS ONLY;

-- 現在のセッションの待機状態
SELECT sid, event, state, wait_time, seconds_in_wait
  FROM v$session_wait
 WHERE wait_class <> 'Idle';

待機イベント	典型的な原因
db file sequential read	索引経由の単一ブロックI/O。索引アクセスが遅い、または偏っている
db file scattered read	フルテーブルスキャンによる連続I/O
log file sync	COMMIT 待ち。コミット頻度が高い、REDO ログ書き込みが遅い
enq: TX - row lock contention	行ロック競合
library cache: mutex X	共有プール競合、ハードパース過多
buffer busy waits	同一ブロックへの集中アクセス

4. AWR / ADDM レポート

-- AWR スナップショットの取得 (通常は自動)
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

-- レポート生成 (SQL*Plus から)
@?/rdbms/admin/awrrpt.sql

-- ADDM (自動診断) レポート
@?/rdbms/admin/addmrpt.sql

AWR レポートで特に見るべきセクション: Top 5 Timed Events / SQL ordered by Elapsed Time / Instance Efficiency Percentages / Buffer Cache / Library Cache Hit Ratio。

5. インデックス戦略

種類	用途	注意点
B-tree インデックス (標準)	選択性が高い列の検索	更新コスト増、肥大化
ビットマップ	低カーディナリティ、DWH	OLTP の更新で激しいロック競合
複合インデックス	WHERE 句の複数列	列順序が重要 (左から使える)
関数索引	WHERE UPPER(name)=... 等	同じ関数式での検索で有効
IOT (索引構成表)	主キーアクセスが大半	追加索引はロウID参照になる

6. メモリ関連

領域	役割	主要パラメータ
Buffer Cache	データブロックのキャッシュ	DB_CACHE_SIZE
Shared Pool	SQL / PL/SQL のキャッシュ、データ辞書	SHARED_POOL_SIZE
Large Pool	RMAN、共有サーバ用	LARGE_POOL_SIZE
Java Pool	Java VM 用	JAVA_POOL_SIZE
PGA	各サーバプロセスの作業領域、ソート	PGA_AGGREGATE_TARGET

チューニングの王道手順

1. 遅い処理を特定: AWR / V$SQLAREA で時間を食っている SQL を探す
2. 実行計画を取得: DBMS_XPLAN で FULL SCAN や CARTESIAN を確認
3. 統計情報を確認: 推定行数と実際の行数が大きく乖離していないか
4. インデックス / SQL を修正: 適切な索引追加 or SQL 書き換え
5. 待機イベントを再確認: I/O 待ちなら表領域配置・キャッシュ、ロック待ちなら設計見直し
6. 結果を計測: 改善前後の実行時間 / バッファゲット数を比較

関連トピック

• 実行計画の読み方
• 統計情報の収集
• AWR / Statspack レポート
• 待機イベントの種類と意味
• インデックス種類と選定
• パーティショニング戦略
• パラレルクエリ