表スペースからの論理スペースのリカバリー

DATAと呼ばれるテーブルスペースがあり、自動拡張がfalseに設定されています。このテーブルスペースには2つのデータファイルがあり、350 GBの物理スペースを使用するように設定されています。

1週間前、私はuser_tablespacesとdba_data_filesにクエリを実行したところ、利用可能な論理スペースが20％あることに気付きました。次に、クリーンアップを続行し、このテーブルスペースのテーブルから多くのレコードを削除しました。利用可能なスペースが大幅に増えると予想していました。残念ながら、ビューを照会したところ、使用可能なスペースが20.5％になりました。

これはデータの断片化が原因である可能性がありますか？どういうわけかテーブルスペースを「デフラグ」して、失われたスペースを回復できますか？または、テーブルスペースを最初から再作成する必要がありますか？

レコードを削除する場合、セグメントを自動的に圧縮するものは何もないため、セグメントを縮小してスペースを再利用する必要があります。これは、無駄なスペースの再利用に関する11.2管理者ガイドからの抜粋です。

時間の経過とともに、テーブルスペース内のオブジェクトの更新と削除により、個々に新しいデータに再利用するのに十分な大きさではない空のスペースのポケットが作成される可能性があります。このタイプの空の領域は、断片化された空き領域と呼ばれます。

断片化された空き領域を持つオブジェクトは、多くの無駄な領域をもたらし、データベースのパフォーマンスに影響を与える可能性があります。この領域を最適化して再利用するための好ましい方法は、オンラインセグメント圧縮を実行することです。このプロセスは、最高水準点の下の断片化された空きスペースを統合し、セグメントを圧縮します。圧縮後、最高水準点が移動し、最高水準点の上に新しい空きスペースができます。最高水位標の上のスペースが割り当て解除されます。ほとんどの操作中、セグメントはクエリとDMLに引き続き使用でき、追加のディスク領域を割り当てる必要はありません。

同じページのさらに下に、これを読むことができます：

セグメントの縮小は、オンラインのインプレース操作です。DML操作とクエリは、セグメント圧縮のデータ移動フェーズ中に発行できます。スペースが割り当て解除されるとき、同時DML操作は、縮小操作の最後に短時間ブロックされます。インデックスは、縮小操作中も維持され、操作が完了した後も使用可能です。セグメントの縮小では、追加のディスク領域を割り当てる必要はありません。

セグメントの縮小により、最高水準点の上下両方の未使用スペースが再利用されます。対照的に、スペースの割り振り解除は、最高水準点より上でのみ未使用スペースを再利用します。縮小操作では、デフォルトで、データベースがセグメントを圧縮し、最高水準点を調整して、再利用されたスペースを解放します。

このページには、例を含む問題に関する詳細情報が含まれています。

コンセプトガイドの「セグメントスペースとハイウォーターマーク」セクションも役立つ場合があります。

はい、断片化が原因です。

スペースを再利用するには、まず次のクエリでテーブルスペース内のテーブルのリストを取得します（パーティションは無視-使用している場合は質問を編集します）。

select distinct table_name from dba_tables where tablespace_name = 'DATA';

次に、各テーブルで行の移動を有効にします。

alter table TABLEINDATAPARTITION enable row movement;

次に、テーブルを縮小できます。

alter table TABLEINDATAPARTITION shrink space;

次に、データファイルを次のように圧縮します。

alter database datafile '/path/to/my/file/data01.dbf' resize 20480M;

データファイル名はDBA_DATA_FILES、すでに知っているビューから取得できます。