~パフォーマンスとストレージ効率を維持するためにやるべきこと~
はじめに
Oracleでテーブルを長期間運用していると、パフォーマンスの低下やストレージの無駄遣いが発生します。
原因は次のような問題です。
- 大量のDMLによる断片化
- 統計情報の陳腐化
- 削除済みデータの領域が解放されていない
これらは、定期的なテーブルのメンテナンスで予防・改善できます。
本記事では、Oracleにおける代表的なテーブルメンテナンス手法を図解付きで丁寧に解説します。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか?
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか?
✅ テーブルメンテナンスの目的とは?
┌──────────────────────┬────────────────────────────────────┐
│ メンテナンス目的 │ 効果 │
├──────────────────────┼────────────────────────────────────┤
│ パフォーマンス維持 │ 実行計画の最適化、I/O効率の向上 │
│ ストレージ効率の向上 │ 空き領域の回収とブロック再利用の最適化 │
│ データ整合性の補助 │ 統計情報更新や整合性チェックでクエリ精度を向上 │
│ 不要領域の可視化・整理 │ 不要ブロックの再利用または縮小 │
└──────────────────────┴────────────────────────────────────┘
① 統計情報の更新(DBMS_STATS)
Oracleオプティマイザはテーブルの統計情報をもとに実行計画を決定します。
DMLが多くなると、古い統計情報では誤った実行計画になることがあります。
✅ 実行コマンド
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'EMP', cascade => TRUE);
cascade => TRUE:対応する索引の統計情報も同時に収集
▼ 図:統計情報と実行計画の関係
┌──────────────┐ ┌─────────────┐
│ 統計情報 │ ───▶ │ オプティマイザ │
└──────────────┘ └──────┬──────┘
│
▼
┌────────────┐
│ 実行計画 │
└────────────┘
② テーブルの断片化の解消(MOVE / SHRINK)
▼ 図:テーブル断片化のイメージ
[初期状態]
┌────┬────┬────┬────┐
│ A │ B │ C │ D │
└────┴────┴────┴────┘
[DELETE B, D 実行後]
┌────┬────┬────┬────┐
│ A │ │ C │ │
└────┴────┴────┴────┘
↑ ↑
空き領域(再利用されない)
📌 MOVE:新しいセグメントへ再配置(索引はUNUSABLEに)
ALTER TABLE employees MOVE;
ALTER INDEX idx_emp_name REBUILD;
▼ 図:MOVEの概念図
┌────旧セグメント────┐ ┌──新セグメント──┐
│ A │ │ C │ │ │ A │ C │ │
└──────────────────┘ └───────────────┘
↑ ↑ ↑
B/D削除→空き 再配置で最適化
📌 SHRINK:空き領域を圧縮(オンラインで実行可)
ALTER TABLE employees ENABLE ROW MOVEMENT;
ALTER TABLE employees SHRINK SPACE;
▼ 図:SHRINKの動作イメージ
[SHRINK前]
┌────┬────┬────┬────┐
│ A │ │ C │ │
└────┴────┴────┴────┘
[SHRINK後]
┌────┬────┐
│ A │ C │ ← 空き領域は戻される
└────┴────┘
③ 未使用領域の確認と再利用
テーブルの削除操作(DELETE)は領域の解放ではなく再利用可能化にすぎません。
使用状況は次のSQLで確認可能です。
SELECT segment_name, bytes/1024/1024 AS MB
FROM user_segments
WHERE segment_type = 'TABLE' AND table_name = 'EMP';
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか?
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか?
④ SHRINK と COALESCE の違い
┌────────────┬───────────────┐
│ 操作 │ 対象・特徴 │
├────────────┼───────────────┤
│ SHRINK │ テーブル向け │
│ │ 空き領域を圧縮し │
│ │ 領域サイズも縮小 │
│ COALESCE │ インデックス向け │
│ │ 空きブロックの整理│
└────────────┴───────────────┘
⑤ ANALYZE TABLE による整合性確認
ANALYZE TABLE employees VALIDATE STRUCTURE;
- テーブルの物理構造や破損をチェック
- 注意:大規模テーブルではロックされるため、本番環境では慎重に
⑥ 不要データの削除と領域縮小
DELETE FROM sales WHERE sale_date < ADD_MONTHS(SYSDATE, -12);
ALTER TABLE sales SHRINK SPACE;
▼ 図:DELETE後の領域縮小の流れ
[DELETEだけ]
┌────┬────┬────┐
│ A │ │ C │ ← 空きブロックは残る
└────┴────┴────┘
[DELETE + SHRINK]
┌────┬────┐
│ A │ C │ ← 領域を再構成・解放
└────┴────┘
⑦ メンテナンスサイクルの目安
| メンテナンス項目 | 推奨頻度 |
|---|---|
| 統計情報の更新 | 週次〜日次(更新頻度による) |
| SHRINK / MOVE | 月次〜四半期(I/O多いテーブル) |
| 不要データの削除 | 月次(業務要件に応じて) |
| 表領域使用率の確認 | 週次〜月次 |
✅ テーブルメンテナンスのまとめ表
┌────────────────────────────┬─────────────────────────────┐
│ やるべきこと │ 実行例 │
├────────────────────────────┼─────────────────────────────┤
│ 統計情報の更新 │ DBMS_STATS.GATHER_TABLE_STATS │
│ 断片化の解消(MOVE) │ ALTER TABLE ... MOVE │
│ オンライン圧縮(SHRINK) │ ALTER TABLE ... SHRINK SPACE │
│ 削除領域の再活用 │ DELETE + SHRINK │
│ 使用状況の確認 │ user_segmentsの確認 │
└────────────────────────────┴─────────────────────────────┘
おわりに
テーブルのメンテナンスは、性能を向上させる手段ではなく、性能を保つための予防策です。
何も対策しないまま年月が経過すれば、パフォーマンスは確実に低下していきます。
✅ 「設計で性能を作り、運用で性能を守る」
この意識で、定期的なテーブルメンテナンスをルーチン化していきましょう。
[参考]
Oracle Database データベース開発ガイド 19c




コメント