12.1 性能問題へのアプローチ

再現条件と基準値を確保してからボトルネックを絞り込みます。根拠なく複数の設定やインデックスを 同時に変更すると、原因と効果を区別できません。

1. 再現条件の記録

• 遅くなった SQL または入力経路
• 開始・終了時刻とデータベース・ユーザー
• 対象テーブル、時間範囲、行数、結果件数
• 同時セッション・クエリ・Appender 数
• 正常時と問題時の遅延・スループット
• 直前のデプロイ、スキーマ、設定、データ分布の変更

2. リソースのボトルネック確認

iostat -x 1 5
top -b -n 1
free -h

CPU・I/O・メモリは固定しきい値ではなく正常時の基準値と比較します。短時間の急増と継続的な飽和を 区別し、OS 指標の時刻をサーバートレースやクエリの時刻と合わせます。

3. 実行中の処理確認

SELECT sess_id, id AS stmt_id, state, record_size, query
FROM V$STMT
ORDER BY sess_id, id;

SELECT id, user_name, user_ip, login_time, client_type
FROM V$SESSION
ORDER BY login_time DESC;

長時間実行の文、異常に増えたセッション、同じクエリの同時実行を探します。システムビューの列は 使用中のバージョンで DESC により確認します。

4. 実行計画と範囲の確認

遅い SELECT は EXPLAIN でテーブル、スキャン方式、キー範囲、フィルター、結合を確認します。 TAG・LOG に時間条件があるか、関数や型変換がインデックス範囲の利用を妨げていないかを調べます。

詳細はクエリと分析の性能調整を参照してください。

5. 1項目変更して再測定

クエリ、インデックス、バッチ、同時実行、キャッシュ・設定の順に候補を絞ります。 1項目ずつ変更し、同じ再現条件で次を比較します。

効果がない、または副作用が大きい場合は、記録した以前の値に戻します。スキーマやストレージ構造の 変更は最後の手段として検討し、先に検証環境と復旧手順を準備します。

最終診断チェックリスト

• 現在の処理とセッションを正常時の基準値と比較したか。
• 実際の SQL と時間範囲で実行計画を確認したか。
• インデックス・ROLLUP 変更による入力コストを確認したか。
• OS とサーバー指標の時刻を対象処理に合わせたか。
• 設定・スキーマを1項目ずつ変更したか。
• 復元用の値と再測定結果を記録したか。