~パフォーマンス維持と障害予防のために定期実施したいこと~
はじめに
Oracleデータベースで性能を維持するうえで、索引の定期的なメンテナンスは非常に重要です。
索引は検索性能を高める一方、以下のような課題を持っています。
- ✅ 更新による断片化
- ✅ 統計情報の陳腐化
- ✅ 不要な索引の放置
この記事では、Oracleにおける索引の代表的なメンテナンス項目を、図解を交えながら実務的に解説します。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか?
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか?
✅ 索引メンテナンスの目的とは?
┌──────────────┬────────────────────────────────────┐
│ メンテナンス目的 │ 効果 │
├──────────────┼────────────────────────────────────┤
│ パフォーマンス維持 │ 検索効率を維持し、オプティマイザの精度向上 │
│ ストレージ効率 │ 不要な領域を解放し、断片化を防止 │
│ 無駄な索引の削除 │ DML性能の向上・バックアップ対象削減 │
│ 実行計画の最適化 │ 最新の統計情報で正しいアクセスパス選択が可能になる │
└──────────────┴────────────────────────────────────┘
① 索引の断片化と再構築(REBUILD)
データのINSERT・DELETE・UPDATEにより、索引ブロック内の空き領域や偏りが生じることがあります。
これが索引の断片化です。
▼ 図:索引断片化のビフォー・アフター
[正常な索引構造]
┌────┬────┬────┬────┬────┐
│ 10│ 20│ 30│ 40│ 50│
└────┴────┴────┴────┴────┘
[断片化が進行した状態]
┌────┬────┬────┬────┬────┐
│ 10│ │ 30│ │ 50│ ← 空きブロック・非効率な検索
└────┴────┴────┴────┴────┘
✅ 再構築コマンド
ALTER INDEX idx_product_name REBUILD;
Enterprise Editionを使用している場合は、業務影響を抑えられるONLINEオプションも活用可能です。
ALTER INDEX idx_product_name REBUILD ONLINE;
② 統計情報の更新(DBMS_STATS)
Oracleのオプティマイザは、索引やテーブルの統計情報をもとに最適な実行計画を選択します。
データ量の変化に伴い、古い統計情報では誤った実行計画が選ばれることがあります。
▼ 図:統計情報が古いと起きる問題
┌───────────────┐ 古い情報で判断 ┌──────────────┐
│ 実データ:100万件 │ ─────────────────▶ │ オプティマイザ │
│ 索引未更新 │ │ (誤った計画) │
└───────────────┘ └──────────────┘
✅ 統計情報更新コマンド(推奨)
EXEC DBMS_STATS.GATHER_INDEX_STATS(ownname => 'SCOTT', indname => 'IDX_EMP_ENAME');
テーブルと索引の両方をまとめて更新する場合:
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'EMP', cascade => TRUE);
③ 索引の使用状況を監視(v$object_usage)
Oracleには、索引が実際に使用されたかどうかを記録する仕組みがあります。
これにより、使われていない索引を特定できます。
▼ 図:索引使用監視の流れ
[開始]
ALTER INDEX idx_sales_date MONITORING USAGE;
[業務運用中]
▼
[確認]
SELECT index_name, used FROM v$object_usage;
[終了]
ALTER INDEX idx_sales_date NOMONITORING USAGE;
✅ 使用状況を一覧で確認
+-------------------+-------------+------+
| INDEX_NAME | TABLE_NAME | USED |
+-------------------+-------------+------+
| IDX_SALES_DATE | SALES | YES |
| IDX_FLAG_TEMP | ORDERS | NO | ← 不要な可能性あり
+-------------------+-------------+------+
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか?
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか?
④ 未使用・重複索引の削除
使用されていない索引や、PRIMARY KEYと重複する内容の索引は、性能劣化の原因になります。
▼ 図:不要な索引の例
[EMPテーブルの索引]
┌────────────────────────┐
│ PK_EMP(empno) │ ← PRIMARY KEY索引(自動作成)
│ IDX_EMP_EMPNO(empno) │ ← 重複 → 削除候補
└────────────────────────┘
✅ 削除コマンド
DROP INDEX idx_emp_empno;
⑤ ONLINE索引再構築・圧縮(Enterprise Edition)
Enterprise Editionでは、業務を止めずに索引の再構築・圧縮が可能です。
ALTER INDEX idx_orders_status REBUILD ONLINE COMPRESS;
▼ 図:圧縮による領域効率化
[圧縮前]
PREFIX-A001-TYPE1
PREFIX-A002-TYPE1
PREFIX-A003-TYPE1
[圧縮後]
PREFIX-□□□-TYPE1 ← プレフィックス圧縮により領域節約
⑥ インデックスの状態確認
SELECT index_name, status
FROM dba_indexes
WHERE table_name = 'EMPLOYEES';
| STATUS | 内容 |
|---|---|
| VALID | 正常に使用可能 |
| UNUSABLE | 再構築が必要 |
⑦ メンテナンス対象のインデックス選定基準
┌──────────────┬────────────────────────────────────┐
│ チェック項目 │ 方法または確認手段 │
├──────────────┼────────────────────────────────────┤
│ 使用頻度 │ v$object_usageで使用履歴を確認 │
│ 統計情報の鮮度 │ dba_indexes.last_analyzedを確認 │
│ 断片化の程度 │ ANALYZE INDEX ... VALIDATE STRUCTURE など │
│ 重複インデックス │ PRIMARY KEYやUNIQUE制約と照合 │
└──────────────┴────────────────────────────────────┘
🔁 索引メンテナンスの目安(頻度)
| メンテナンス項目 | 推奨頻度 |
|---|---|
| 統計情報の更新 | 日次〜週次(変更頻度による) |
| 索引の使用状況モニタリング | 半年ごと、またはリリース単位 |
| 断片化・再構築の検討 | 年1〜2回(重たいDMLが多い場合は都度) |
| 不要な索引の削除 | 四半期〜半年ごと |
✅ まとめ:索引メンテナンスのチェックポイント
┌─────────────────────────────────────────────┐
│ メンテナンス項目 │ やるべきこと │
├──────────────────────┼─────────────────────────────┤
│ 再構築(REBUILD) │ 断片化した索引を効率化 │
│ 統計情報の収集 │ GATHER_STATSでオプティマイザ最適化 │
│ 使用状況の監視 │ v$object_usageで利用有無を把握 │
│ 不要な索引の削除 │ USED = 'NO'のものをDROP検討 │
│ 圧縮(COMPRESS) │ プレフィックス圧縮で領域削減 │
└──────────────────────┴─────────────────────────────┘
おわりに
索引のメンテナンスは日々の業務では見落とされがちですが、パフォーマンス維持・障害防止・ストレージ効率向上に直結する重要な作業です。
作るだけでなく、「定期的に見直す」ことが本当の意味での索引管理です。
現場に合ったサイクルで、継続的なメンテナンスを設計・実行していきましょう。
[参考]
Oracle Database データベース開発ガイド 19c




コメント