【Oracle】表や索引の断片化を防ぐ！インデックス再構築と表領域メンテナンスの実践ガイド

Oracleで断片化が起こる理由

Oracleデータベースを長期間運用していると、表や索引（インデックス）の断片化が徐々に進行します。
これは削除・更新を繰り返すことで、**データブロック間に無駄な空き領域（HWM下の未使用領域）**が生まれるためです。

結果として…

• SELECTやJOIN時のI/Oコスト増大
• 表領域の肥大化
• バックアップ時間の増加

など、パフォーマンス低下と管理コストの上昇を招きます。

本記事では、実際の業務現場で行われている
✅ 断片化の確認方法
✅ インデックス再構築の実施方法
✅ 表領域の整理（SHRINK・MOVE）
をわかりやすく解説します。

---

1. 断片化の発生状況を確認する

■ DBA_INDEXES から確認する

SELECT 
    INDEX_NAME,
    TABLE_NAME,
    LEAF_BLOCKS,
    DISTINCT_KEYS,
    BLEVEL
FROM DBA_INDEXES
WHERE OWNER = 'SCOTT';

BLEVEL（ブランチ階層）が高く、LEAF_BLOCKS が極端に多い場合は断片化が進行しているサインです。

---

■ 表断片化の確認（NUM_ROWS と BLOCKS 比較）

SELECT 
    TABLE_NAME,
    NUM_ROWS,
    BLOCKS,
    AVG_ROW_LEN
FROM DBA_TABLES
WHERE OWNER = 'SCOTT';

削除・更新が多い表では BLOCKS が過大になる傾向があります。
ANALYZE TABLE ... COMPUTE STATISTICS で統計情報を更新してから比較すると正確です。

---

2. インデックスの再構築方法

Oracleでは、インデックス再構築を主に2つの方法で行います。

■ ① REBUILD（再構築）

ALTER INDEX idx_customer_name REBUILD ONLINE;

• ONLINE オプションを指定すれば、テーブルへのDML操作をブロックせずに再構築可能。
• 大規模テーブルでは PARALLEL オプションの併用も有効。

ALTER INDEX idx_customer_name REBUILD ONLINE PARALLEL 4;

---

■ ② COALESCE（空き領域の再結合）

ALTER INDEX idx_customer_name COALESCE;

• ロック時間を最小化したい場合に適しています。
• 断片化が軽度な場合に有効。

---

3. 表領域（TABLESPACE）の断片化を整理する

テーブルやLOB列を頻繁に更新するシステムでは、表領域自体が断片化することもあります。

■ ① SHRINK SPACE

ALTER TABLE sales ENABLE ROW MOVEMENT;
ALTER TABLE sales SHRINK SPACE;

• ROW MOVEMENTを有効にすることで、Oracleが行を詰め直して空き領域を開放。
• 注意：一時的にUNUSABLEインデックスが発生する場合あり。

---

■ ② MOVE文で物理再配置

ALTER TABLE sales MOVE TABLESPACE USERS;
ALTER INDEX idx_sales_id REBUILD;

• SHRINKで効果が薄い場合に実施。
• 再構築後はインデックスも必ずREBUILDが必要です。

---

4. メンテナンス運用の自動化例（スケジュール実行）

毎週末にインデックス再構築を自動実行する場合の例です。

BEGIN
  DBMS_SCHEDULER.CREATE_JOB (
    job_name        => 'JOB_IDX_REBUILD',
    job_type        => 'PLSQL_BLOCK',
    job_action      => '
      BEGIN
        FOR r IN (SELECT index_name FROM user_indexes WHERE status = ''VALID'') LOOP
          EXECUTE IMMEDIATE ''ALTER INDEX '' || r.index_name || '' REBUILD ONLINE'';
        END LOOP;
      END;',
    start_date      => SYSTIMESTAMP,
    repeat_interval => 'FREQ=WEEKLY;BYDAY=SUN;BYHOUR=3;BYMINUTE=0;BYSECOND=0',
    enabled         => TRUE
  );
END;
/

これにより、定期的な断片化対策を自動化できます。

---

5. SHRINK実施時の注意点

注意点	内容
LOB列が含まれる場合	SHRINK対象外（別途 ALTER TABLE ... MOVE LOB が必要）
外部キー制約	SHRINK中に一時ロックが発生する可能性あり
アーカイブログモード	SHRINKはREDO生成量が多く、ログ容量に注意

---

6. パフォーマンス改善の効果確認

再構築後は DBMS_STATS.GATHER_TABLE_STATS で統計を更新し、SQLの実行計画を比較してみましょう。

EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'SALES');

再構築により、アクセスパスがINDEX RANGE SCANに戻る／I/Oコストが半減するケースが多く報告されています。

---

まとめ

ポイント	内容
✅ インデックス断片化は放置するとI/Oコスト増大	BLEVELとLEAF_BLOCKSで確認可能
✅ 軽度なら COALESCE、高度なら REBUILD	ONLINEオプションで業務影響を最小化
✅ 表の断片化は SHRINK や MOVEで解消	LOB列・外部キー制約に注意
✅ 定期ジョブ化で自動化	DBMS_SCHEDULERで毎週再構築可

Oracleの断片化メンテナンスは、「どの程度の断片化で行うか」を定期的にモニタリングすることが重要です。
DBの運用年数が長いほど、「再構築する勇気」も性能チューニングの一部と言えます。