カラム・オーガナイズ 表のスペース再利用

カラム・オーガナイズ 表からデータが削除されると、削除されたデータをページが保持するストレージ・エクステントは、スペース・レクラメーションの候補になります。 スペース再利用プロセスはこのようなエクステントを検出して、それらが保持していたページを表スペースのストレージに返却します。 その結果、それらのページは表スペース内の任意の表が再利用できるようになります。

このプロセスは、 REORG TABLE コマンドに RECLAIM EXTENTS オプションを指定することによって手動で開始することも、自動化アプローチを使用することもできます。 DB2_WORKLOAD レジストリー変数を ANALYTICSに設定すると、デフォルト・ポリシーが適用され、すべての カラム・オーガナイズ 表に対して自動再利用がアクティブになるように auto_reorg データベース構成パラメーターが設定されます。 詳しくは、 表と索引の自動再編成の有効化 および 自動保守ポリシーの構成を参照してください。

再編成モニタリング・インフラストラクチャーにより、表の再編成操作の進行状況をモニターできます。 ADMIN_GET_TAB_INFO 表関数は、表の再利用可能スペースの推定量を返します。この値を参考にして、表の再編成操作が必要となる時点を判断できます。

注: ADMIN_GET_TAB_INFO 表関数からの RECLAIMABLE_SPACE 出力は、 RUNSTATS コマンドが実行された時刻に適用される見積もりであるため、この情報は カラム・オーガナイズ 表では古くなっている可能性があります。

削除後のスペース再利用

カラム・オーガナイズ 表の行が削除されると、その行は物理的に削除されるのではなく、論理的に削除されます。 その結果、削除された行が使用していたスペースを後続のトランザクションで利用することはできず、スペース再利用が行われるまで利用不可の状態になります。 例えば、表を作成して、バッチ操作 A で 100 万行を挿入したとします。 バッチ操作 A 後のディスク上の表のサイズは 5 MB です。 しばらく後、バッチ操作 B で、さらに 100 万行を挿入します。 この時点で、表はディスク上の 10 MB を使用しています。 次に、バッチ操作 A で挿入した行をすべて削除したとします。その場合、ディスク上の表のサイズは 10 MB のままです。 ここで、3 番目のバッチ操作 C を実行してさらに 100 万行を表に挿入すると、さらに 5 MB のスペースが必要になります。 ( 行オーガナイズ 表では、バッチ操作 C で挿入される行は、バッチ操作 A から削除された行によって空いたスペースを使用します。) バッチ操作 A で挿入した行が使用していたスペースを再利用するには、REORG TABLE コマンドが必要です。 エクステント内の行がすべて削除されるまで、エクステントを再利用することはできません。
注: ラージ・オブジェクト (LOB) データがカラムナ表から削除された場合、データ・ストレージは再利用のために表スペースに戻されることも、将来使用するために解放されることもありません。

更新後のスペース再利用

カラム・オーガナイズ 表の行が更新されると、まず既存の行が削除され、その行の新しいコピーが表の末尾に挿入されます。 したがって、スペース再利用が行われるまでの間は、行を更新すると、行を更新した回数に比例して消費スペースが増えていきます。 更新された行が含まれているエクステントのすべての行は、エクステントの再利用前に削除される必要があります。

表の自動再圧縮後のスペース再利用

表の自動再圧縮フィーチャーは、新しい圧縮デーモンを使用して、圧縮ディクショナリーの作成前に挿入された行を含む表を非同期にチェックします。 その後これらの行がその場で再圧縮され、エクステントが空になります。 これらの空のエクステントは、後で REORG TABLE ... RECLAIM EXTENTSを使用して再利用できます。 解放され再利用されるエクステントは、同じ表スペース内の他の表により再使用できます。