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

Oracleで断片化が起こる理由
1. 断片化の発生状況を確認する
1. ■ DBA_INDEXES から確認する
2. ■ 表断片化の確認（NUM_ROWS と BLOCKS 比較）
2. インデックスの再構築方法
1. ■ ① REBUILD（再構築）
2. ■ ② COALESCE（空き領域の再結合）
3. 表領域（TABLESPACE）の断片化を整理する
1. ■ ① SHRINK SPACE
2. ■ ② MOVE文で物理再配置
4. メンテナンス運用の自動化例（スケジュール実行）
5. SHRINK実施時の注意点
6. パフォーマンス改善の効果確認
まとめ

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';

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';

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;

1 2	ALTER INDEX idx_customer_name REBUILD ONLINE;

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

ALTER INDEX idx_customer_name REBUILD ONLINE PARALLEL 4;

1 2	ALTER INDEX idx_customer_name REBUILD ONLINE PARALLEL 4;

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

ALTER INDEX idx_customer_name COALESCE;

1 2	ALTER INDEX idx_customer_name COALESCE;

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

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

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

■ ① SHRINK SPACE

ALTER TABLE sales ENABLE ROW MOVEMENT;
ALTER TABLE sales 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;

ALTER TABLE sales MOVE TABLESPACE USERS;

ALTER INDEX idx_sales_id REBUILD;

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

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

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

BEGIN
  DBMS_SCHEDULER.CREATE_JOB (
    job_name        =&gt; 'JOB_IDX_REBUILD',
    job_type        =&gt; 'PLSQL_BLOCK',
    job_action      =&gt; '
      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      =&gt; SYSTIMESTAMP,
    repeat_interval =&gt; 'FREQ=WEEKLY;BYDAY=SUN;BYHOUR=3;BYMINUTE=0;BYSECOND=0',
    enabled         =&gt; TRUE
  );
END;
/

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');

1 2	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の運用年数が長いほど、「再構築する勇気」も性能チューニングの一部と言えます。