Just another IT site ※IT系の記事は当方環境での実施内容となるため実施する場合は自己責任でお願いいたします。At Your Own Risk!! TURN BACK WHILE YOU CAN
PR

【Ask_AI】Oracleの断片化解消について

※IT系の記事は当方環境での実施内容となるため実施する場合は自己責任でお願いいたします。スクリプトはAI生成のものも多いのでコピー＆ペーストの際は文字コードに注意ください！
2026.05.26

【AIによる概要】

oracle テーブル デフラグにあたる機能はあるか

Oracleには、表（テーブル）の断片化を解消・再編成して空き領域を回収する「デフラグ」に相当する機能が複数用意されています。代表的な機能としてセグメント縮小（SHRINK）と表の移動（MOVE）があり、状況に応じて使い分けられます。 [1, 2, 3]
主なデフラグ・再編成機能の比較

機能 [1, 2, 3, 4, 5] 概要 ダウンタイム オンライン実行 関連するインデックス
セグメント縮小
(SHRINK)		 行の断片化を解消し、不要になった領域（HWM：ハイウォーターマーク）を下げる。 基本的に不要（最小限） 可能（オンラインで実施可能） インデックスも自動で保守されるため、再構築の必要がない。
表の移動
(MOVE)		 テーブルデータを新しい領域へ再配置し、領域をリセットする。 DML（更新系）処理が不可 標準では不可（12.2以降ではオンラインMOVEも可能） MOVE後に全インデックスの再構築（REBUILD）が必須。

各機能の実行方法（コマンド例）
それぞれのコマンドを実行する際は、要件に合わせて選択・調整してください。
1. セグメント縮小（SHRINK）
表への更新処理（DML）を継続しながらデフラグを行いたい場合に最適です。
sql
-- 1. 行の移動を許可する（SHRINKの前提条件）
ALTER TABLE テーブル名 ENABLE ROW MOVEMENT;

-- 2. セグメント縮小を実行
ALTER TABLE テーブル名 SHRINK SPACE;

-- （補足）LOB列が含まれている場合のコマンド
ALTER TABLE テーブル名 MODIFY LOB (LOB列名) (SHRINK SPACE);
コードは注意してご使用ください。

2. 表の移動（MOVE）
データを全く新しい領域に物理的に書き直すため、最も確実に断片化を解消できます。
sql
-- 1. 表を移動して再編成
ALTER TABLE テーブル名 MOVE;

-- （補足）Enterprise EditionでオンラインMOVEを利用する場合
ALTER TABLE テーブル名 MOVE ONLINE;
コードは注意してご使用ください。
注意： 通常の ALTER TABLE MOVE を行った後は、そのテーブルに付与されているすべてのインデックスが使用禁止（UNUSABLE）になります。そのため、以下のコマンドでインデックスを再構築してください。 [1, 2]
sql
ALTER INDEX インデックス名 REBUILD;
コードは注意してご使用ください。

詳細なパラメータの指定や制限事項については、Oracle Database 管理者ガイド をご参照ください。

あなたが話した内容: バージョンによって性能の違いはあるか

Oracleのデフラグ（再編成）機能は、使用するバージョンによって「実行できる機能（オンライン化）」や「内部の処理効率（性能・リソース消費）」が大きく進化しています。 [1]
特に大きな違いが出るポイントを3つの軸に分けて解説します。
1. 「MOVE」機能の進化（ダウンタイムの解消）
最も劇的な性能・仕様の違いは、データを物理的に書き直す MOVE 操作の進化です。
  • Oracle 12c R1 以前：通常のテーブルに対する MOVE は完全に「オフライン」処理でした。実行中は一切の DML（追加・更新・削除）がロックされるため、大規模なデフラグには長時間のダウンタイムが必要でした。
  • Oracle 12c R2 以降：ALTER TABLE ... MOVE ONLINE が導入されました。
    • 性能への影響：業務を一切止めずに（オンラインで）高速な物理デフラグが可能になりました。

  • Oracle 19c / 21c / 23c 以降：オンラインMOVEの内部最適化がさらに進み、同時実行されるトランザクション（更新処理）への競合（ラッチやロックの負荷）が大幅に軽減されています。 [1, 2, 3]

2. 「SHRINK」機能の性能差（CPU・I/O負荷と内部バグ）
SHRINK SPACE（セグメント縮小）は Oracle 10g で導入された歴史の長い機能ですが、バージョンによって内部の処理効率が異なります。 [1]
  • 古いバージョン（11gなど）：SHRINK は「行を1件ずつ消して、空き領域に挿入し直す」という内部処理（行移動）を多量の DELETE/INSERT のように繰り返します。そのため、データ量が膨大だと膨大な UNDO/REDO ログが生成され、I/O性能を著しく圧迫する問題がありました。
  • 新しいバージョン（19cや23cなど）：内部のブロック処理ブロック単位のアルゴリズムが改良され、不必要なログ生成の抑制や CPU 効率が向上しています。
  • バグの修正：古いバージョンでは、SHRINK 実行中や実行直後にオプティマイザの統計情報との乖離が原因で、一時的に特定の SQL の実行計画が悪化（性能劣化）する既知の事象がありました。近年のバージョン（19cの最新RUなど）では、これら SHRINK に纏わる多くの内部バグやエッジケースが修正され、安定性が増しています。 [1]

3. 自動デフラグ機能（自動セグメント・アドバイザ）の賢さ
Oracle がバックグラウンドで「どのテーブルがどれだけ断片化しているか」を診断する セグメント・アドバイザ（Segment Advisor） の精度も変化しています。 [1]
  • 近年のバージョン（19c以降など）：機械学習や過去の統計情報を加味し、より正確に「デフラグによってどれだけ領域が回収できるか、どれだけ I/O 効率が上がるか」の予測精度が向上しています。無駄なデフラグ処理によるシステム負荷（オーバーヘッド）自体を回避できるようになっています。 [1, 2]

まとめ：現在の推奨アプローチ
  1. Oracle 12c R1 以前：ダウンタイムを最小限にするため、基本的には SHRINK SPACE を選択。ただし、I/O 負荷が高いため夜間などの低負荷時間帯に実行する。
  2. Oracle 12c R2 / 19c 以降：最もクリーンかつ安全に断片化を解消できる ALTER TABLE ... MOVE ONLINE を第一選択とする。 [1, 2]

もし現在システム構築や移行（アップグレード）を検討されている場合、適用しているバージョン（19cなど）のパッチレベル（RU: Release Update）によっても細かい挙動の安定性が異なります。 [1]
現在利用している（または検討している）具体的なOracleのバージョンを教えていただければ、より絞った注意点（インデックスの自動再構築の挙動など）をお伝えできますがいかがでしょうか？

You said: 再編成を行うコマンドを実行することと、エクスポートとインポートを実行することと比較すると結果に差はあるか
テーブルの再編成（MOVE や SHRINK）と、エクスポート／インポート（expdp / impdp）は、「断片化を解消して空き領域を回収する」という最終目的は同じですが、完了後の内部状態やシステムへの影響（結果）には明確な差があります。
それぞれの違いを4つの視点で比較します。
1. 物理的な並び順とパフォーマンス（結果の差）
  • 再編成（MOVE）：データをそのまま新しい領域に「スライド」させて詰め直すイメージです。データの物理的な格納順序（並び順）は、基本的に元の状態を維持します。
  • エクスポート／インポート（Datapump）：データを一度ファイルに書き出し、テーブルを完全に作り直してデータを「一から挿入（INSERT）」します。
    • 結果の差：インポート時にデータが整然とブロックに詰め込まれるため、直後のデータ検索（フルテーブルスキャンなど）のパフォーマンスはエクスポート／インポートの方が向上しやすい傾向にあります。

2. 空き領域の回収効率（HWMの引き下げ）
  • 再編成（SHRINK）：構造上、一部の空き領域（エクステント）が完全に解放しきれず、領域の削減率が MOVE やインポートに比べて一歩劣る場合があります。
  • エクスポート／インポート：テーブルオブジェクト自体を新規作成（初期化）してデータを流し込むため、無駄な空き領域（ハイウォーターマーク）が確実にゼロになり、領域回収の効率は最も高くなります。

3. オブジェクトの定義と「付随するデータ」の状態
  • 再編成（MOVE / SHRINK）：テーブルの器はそのままで中身を整理するため、統計情報や依存オブジェクトへの影響は最小限です。
  • エクスポート／インポート：オブジェクトの「再作成」になるため、以下の挙動に注意が必要です。
    • 統計情報のクリア：インポート時に統計情報が再計算（またはエクスポート時のものが移行）されますが、実行計画が変化するリスクが再編成より高くなります。
    • LOBやパーティション：エクスポート/インポートのパラメータ（TRANSFORM など）を誤ると、元のストレージパラメータ（初期サイズなど）が変わってしまう可能性があります。

4. 実行時の運用の差（ダウンタイムとリスク）
最も大きな違いは、作業中のリスクと手間にあります。

比較項目 再編成（MOVE ONLINE など） エクスポート／インポート（Datapump）
作業の手間 SQLコマンドを数行実行するだけで完結。 バックアップファイルの出力先（ディレクトリ）の確保や、各種パラメータの指定が必要。
一時領域の消費 データベース内の表領域（Tablespace）の空き容量を使用。 データベース外（OSのディスク）にエクスポートファイル分の空き容量が必要。
インデックス 近年のオンラインMOVEやSHRINKなら自動保守。 インポート後にインデックスが自動作成されるが、件数が多いと非常に時間がかかる。

まとめ：どちらを選ぶべきか？
  • 「再編成（MOVE / SHRINK）」を選ぶべきケース：
    • 運用の手間を減らしたいとき。
    • OSのディスク容量に余裕がないとき。
    • Oracle 12c R2以降で、オンライン（業務を止めず）にデフラグしたいとき。

  • 「エクスポート／インポート」を選ぶべきケース：
    • データ移行やバージョンアップを同時に行うとき。
    • テーブルの構造やストレージパラメータ自体をきれいにリセットしたいとき。
    • ダウンタイム（メンテナンス時間）が十分に確保されており、確実な領域回収とパフォーマンス向上を狙いたいとき。

💡 次のステップに向けて、以下の詳細をお調べすることも可能です。
  1. エクスポート／インポート（impdp）を行う際の具体的な手順やおすすめのパラメータ仕様
  2. 対象テーブルに LOB列（大容量データ）やパーティション が含まれている場合の注意点
  3. 今回のデフラグ作業に割り当てられる ダウンタイム（停止時間）の有無

ご興味のある項目や、現在の状況に合わせて知りたい内容があれば番号などで教えてください。

タイトルとURLをコピーしました