web-dev-qa-db-ja.com

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

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

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

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

11
Nuno Furtado

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

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

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

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

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

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

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

コンセプトガイドの "Segment Space and the High Water Mark" セクションも役立ちます。

14
Leigh Riffel

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

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

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ビューから取得できます。

9
Philᵀᴹ