oracle 表データメンテナンス方法について

Question

不要なデータの削除を行い、その後効率的に断片化解消とHWMを下げる方法について検討しています。
ネットワークやCPU・メモリ負荷も考慮した安全で確実な方法を選択したいのですがよい方法を教えてください。

現在、下記２つの手順をを検討しています。
どちらの方法がよろしいでしょうか。もしくは他に方法があればご教授お願い致します。
1.
→不要なデータをDELETE
→Data Pumpで expdp
→テーブルtruncate
→Data Pumpでimpdp
→統計情報取得
→index再構築
→プライマリーキーの統計情報再収集

→不要なデータをDELETE
→行移動の有効化
alter table 表名 enable row movement;
→表および表に依存する索引を圧縮、解放
alter table 表名 shrink space cascade;
→行移動の無効化
alter table 表名 disable row movement;
→統計情報取得
→index再構築
→プライマリーキーの統計情報再収集

※テーブルは120GB となっています。
※作業時間帯は、テーブルが稼働しない（INSER,UPDATE,DELETEされない）予定です。

Answer 1

私は1の方法を推薦します。
2に比較して処理時間的にも有利であろうということと、
shrink spaceについて、
SHIFT The Oracle - テーブルのハイウォータマーク操作
にて、

ハイウォータマークを下げることはできるが万能ではない。
レコード数が少ない場合において HWM が思ったより低下しない場合がある。
これは 行移行、行連鎖 の状態によって使用中のブロックが残っていることが考えられる。
連鎖状態を解消してから行なうと非常に効果が高い。

とあるためです。
なお1も2も統計情報取得の次にindex再構築とプライマリーキーの統計情報再収集の手順をとっていますが、
逆でindex再構築後に統計情報取得をしたほうが良いです。

BEGIN
	DBMS_STATS.GATHER_TABLE_STATS(
		OWNNAME => [Owner],
		TABNAME => [TABLE_NAME],
		CASCADE => TRUE,
		METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO'
	);
END;

のようなコードで統計情報を取得しますが、
CASCADE に Trueを指定することでIndexの統計情報も併せて取得できるためです。

Comments

[tshizuku03]

お返事が遅くなりました。ご回答ありがとうございます。
推薦していただいた１の方法で進めたいと思います。

index再構築とプライマリーキー再構築の順番については、
統計情報取得（ DBMS_STATS.GATHER_TABLE_STATS）の中で
indexの統計情報取得もあったのですね。
お恥ずかしいのですが、index再構築と統計情報についても
あまり詳しくないので、正しい順番がわかりませんでした。

教えていただき、ありがとうございます。

[nabe3]

実施の前に気を付けていただきたい点を2点追記します。

1点目
> →テーブルtruncate
> →Data Pumpでimpdp
今回の処理はテーブルをDropしていないために、impdp時に
「ORA-39151: 表"shema_name"."table_name"が存在します。
スキップのtable_exists_actionのため、すべての依存メタデータおよびデータはスキップされます」
のエラーが発生することが予想されます。
そのためimpdpの際に「table_exists_action=truncate」を指定して、
表がすでに存在する時のアクションを明示してエラーを回避する必要があります。
impdpでtruncate出来ますので、impdp前のtruncateは不要になります。

2点目
安全性を考慮し、バックアップサーバーがあるのでしたら、
一度バックアップサーバーでスクリプトを作成し、
一連の流れを検証することをお勧めします。
バックアップサーバーがない場合は出来ればフルエクスポートを取得し、
手順を1つ1つ確認しながら慎重に進めることをお勧めします。

[tshizuku03]

教えていただき、ありがとうございました。
>impdpでtruncate出来ますので、impdp前のtruncateは不要になります。
impdpでtruncateできるのですね。
エクスポート/インポートで断片化解消できる事は知っていたのですが、
impdpでtruncateできるとは知りませんでした。

バックアップサーバーというか・・・
本番サーバーとは別に開発サーバーが存在しています。
なので、開発サーバーで一連の流れの検証して手順を確立させた後、本番サーバーで作業したいと思います。
（ただ、開発サーバーも複数人で利用している為、テーブル復旧不可とかあまりにもぶっ飛んだ作業は出来なかったので、今回質問させていただいた次第です。）

1の手順で試してみます。ご相談に乗っていただきありがとうございました！

Answer 2

私も案1で良いかと思います。
案2のメリットは、オンライン中でも実施可能な点ですが記載頂いた通り、作業時間中はテーブル稼働が無いとの事なので案1で大丈夫かと。

ただ1点気になった点としては、impdp実行時にはindex再構築はさせないのでしょうか。
あえて、別出しでindex再構築を実施する意図が余りピンと来ませんでした。

Comments

[tshizuku03]

お返事が遅くなりました。ご回答ありがとうございます。
１の方法で進めたいと思います。

>impdp実行時にはindex再構築はさせないのでしょうか。
調べた限りですと、impdpのオプション(include=INDEX)を指定することで
indexもインポートできる事がわかったのですが、
impdpでindex再編成できるのでしょうか。

お恥ずかしいのですが、impdpもあまりよく理科できておりませんので
ご意見いただると大変助かります。