タイガー!タイガー!じれったいぞー!(SE編)

AS400, Java, JavaEE, JSF等の開発、習慣など。日々の気づきをまとめたブログ(備忘録)

【AS400】物理ファイル「削除済みレコードの再使用」の検証

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」を付けないケースは、ほとんど無いとは思いますが・・・。

以上で検証終了です。