AS400のデータベース、すなわち「DB2 for i」についてです。
AS400のテーブルのレコードを物理削除していくと、削除レコードがどんどん増えていくことになりますが、その場合、バッチ処理等で「RGZPFM(物理ファイル・メンバー再編成)」をすれば、削除レコードはクリーンアップされます。
確かにそのやり方でまったく問題無いのですが、この処理すら省く方法は無いかな~?(楽をしたい!)
ということで、物理ファイルの設定で「削除済みレコードの再使用(REUSEDLT)」というオプションがあることを知りました。
早速、試してみましたので、検証結果をまとめておきます。
テスト・テーブル
今回、TESTPF01 というテーブルを準備しました。
中身は、こんな感じです。
RUNQRY QRYFILE(TIGERDB/TESTPF01) KEY01 KEY02 FLD01 FLD02 FLD03 000001 A0001 1 1 500 000002 A0001 2 3 120 000003 A0001 3 3 150 000004 A0001 4 1- 10 値引き 000005 A0002 1 1 15,000 000006 A0002 2 1 5,000 000007 A0003 1 8 30 000008 A0003 2 8 25 000009 A0003 3 8 60 000010 A0003 4 1,000 5 000011 A0004 1 1 100 000012 A0004 2 1 200 000013 A0004 3 1 300 000014 A0004 4 1 400 000015 A0004 5 1 500
DSPFD FILE(TIGERDB/TESTPF01) : メンバーの合計数 . . . . . . . . . . . . : 1 使用可能でないメンバーの合計数 . . . . . . : 0 合計レコード数 . . . . . . . . . . . . . : 15 合計削除レコード . . . . . . . . . . . . : 0 合計メンバー・サイズ . . . . . . . . . . : 49152
物理ファイルの設定変更
テスト・テーブルの「削除済みレコードの再使用」の初期値は、「*NO」。
当然、初期値のまま、コンパイルしましたので、ここは「CHGPF」コマンドで設定変更をする必要があります。
CHGPF FILE(TIGERDB/TESTPF01) REUSEDLT(*YES)
物理ファイル変更 (CHGPF) 選択項目を入力して,実行キーを押してください。 入れたい記憶装置 . . . . . . . UNIT *ANY 強制書き出しレコード数 . . . . FRCRATIO *NONE 最大ファイル待機時間 . . . . . WAITFILE 30 最大レコード待機時間 . . . . . WAITRCD 60 オープン・データ・パス共用 . . SHARE *SAME 許される削除 レコード の最大 % . . DLTPCT *NONE 削除済みレコードの再使用 . . . REUSEDLT *YES <<<< 分類順序 . . . . . . . . . . . SRTSEQ *HEX ライブラリー . . . . . . . . . . . 言語 ID . . . . . . . . . . . . LANGID JPN レコード様式レベルの検査 . . . LVLCHK *YES メモリーに保管 . . . . . . . . KEEPINMEM *NO ノード・グループ . . . . . . . NODGRP *NONE
検証作業結果
PFの設定を変更したので、ここから検証開始です。
①物理レコード削除
UPDDTAコマンド、SQLなどでレコードを2件物理削除しました。
※5番目と6番目のレコード
000005 A0002 1 1 15,000 000006 A0002 2 1 5,000
この段階で、物理ファイルを参照してみます。
メンバーの合計数 . . . . . . . . . . . . : 1 使用可能でないメンバーの合計数 . . . . . : 0 合計レコード数 . . . . . . . . . . . . . : 13 合計削除レコード . . . . . . . . . . . . : 2 合計メンバー・サイズ . . . . . . . . . . : 53248
ここまでは、お馴染みの動きですね(合計レコード: 15 → 13件、削除レコード: 0 → 2件)
②レコード追加
次に、レコード追加です。今回は、UPDDTAで追加しました。
ファイル中のデータ処理 モード . . : 挿入 様式 . . . . : RECPF01 ファイル . : TESTPF01 KEY01: A0005 KEY02: 1 FLD01: 3 FLD02: 700 FLD03: あいう
③物理ファイル確認
2件削除し、1件追加した後で、「DSPFD」コマンドで確認です。
メンバーの合計数 . . . . . . . . . . . . : 1 使用可能でないメンバーの合計数 . . . . . : 0 合計レコード数 . . . . . . . . . . . . . : 14 合計削除レコード . . . . . . . . . . . . : 1 合計メンバー・サイズ . . . . . . . . . . : 53248
削除レコードが2件から1件へ減少し、合計レコードが13件から14件へ増加しています!!
これなら、定期的な最適化処理はいらなくなりそうですね。
注意点
SQLでの呼び出しで注意点がひとつ。
途中でレコードが挿入されるため、SELECT句でのレコード参照では、「ORDER BY」を付けないと、予期せぬ並びになってしまいます。
SELECT * FROM TIGERDB.TESTPF01 -- KEY01 KEY02 FLD01 FLD02 FLD03 -- A0001 1 1 500 -- A0001 2 3 120 -- A0001 3 3 150 -- A0001 4 1- 10 値引き -- A0005 1 3 700 あいう <<<②で追加したレコード -- A0003 1 8 30 -- A0003 2 8 25 -- A0003 3 8 60 -- A0003 4 1,000 5 -- A0004 1 1 100 -- A0004 2 1 200 -- A0004 3 1 300 -- A0004 4 1 400 -- A0004 5 1 500
まあ、そもそも「ORDER BY」を付けないケースは、ほとんど無いとは思いますが・・・。
以上で検証終了です。