ここではDb2 for i、IBM iの日常運用について見直してみる。Db2 for i は運用がほとんど自動化されており、ユーザーが介在すべき運用管理項目はごく少ない。
だが、以下の点についてはデータベース運用の観点で必ず確認すべきポイントと言える。
物理ファイル（テーブル）の保守
削除済みレコード件数の確認とファイル再編成
これには事前準備として、対象データベースファイルの情報抽出が必要である。
以下のようにDSPFDコマンドで、対象データベースファイルの分析用情報を取得する。
以降の分析では、上記ファイルをQUERYで参照する。その際、以下の条件でレコード選択する。
①以下のフィールドを選択する
MBLIB、MBFILE、MBNAME、MBNRCD（現行レコード数）、MBNDTR（削除レコード数）、MBDSZ2（データベースサイズ）
②以下の条件でレコードを抽出する
MBNDTR GT 0 かつ MBFILE NLIKE ‘QADB%’ かつ MBLIB NLIKEE ‘Q%’
＊ユーザーライブラリーがQxxxで始まる場合は、そのライブラリーも分析対象に含まれるように条件を修正する
③MBDSZ2の降順でソートする
DSPFD出力結果の確認
上記QUERYの参照例が図表1である。
まず、削除済みレコード件数を確認する。削除済みレコードはアプリケーションから削除済みだが、ストレージ領域からは未削除のレコードである。この割合が大きいと、全件読み込み処理などで余計な処理時間が発生するなど、パフォーマンスに悪影響を与えるため定期的に削除することを推奨する。
図表1は業務稼働機でない環境のため規模が小さいが、たとえば000015のMPLTRNは現行32レコードに対し削除済みが約4倍の122レコード存在している。実環境でこのように削除レコードの割合が大きいファイルを再編成（削除済みレコードを消去）することで、パフォーマンス面での効果を期待できる。
本番環境のIBM iでは、レコード件数が億単位の物理ファイル・テーブルも比較的多く存在しているが、そのような大きなテーブルを利用している場合はディスクスペース削減の観点でも効果が期待できる。
活動状態ファイル再編成の実行方法
RGZPFMコマンドは、ENDSBS *ALLコマンドなどユーザーからのアクセスを制限して実行する方法に加え、活動状態再編成とでも呼ぶべき方法でも実行できる。
前提として該当ファイルがジャーナルされていることが必要で、RGZPFMコマンドでALWCANCEL(*YES)とLOCK(*SHRUPD か *EXCLRD)を付加して、再編成を実行する（図表2）。
LOCKパラメータで、*SHRUPDはRGZPFMコマンド実行中に他のジョブから読み取り、更新、追加、削除を許容する。*EXCLRDは、他のジョブから読み取りが可能となる。
削除レコード数の定常的な監視方法
定常的に削除レコード数を監視したいテーブル・物理ファイルが存在する場合は、CHGPFコマンド等で DLTPCTパラメータを指定できる（図表3）。
DLTPCT（デフォルトは*NONE）に監視したい削除レコードの割合の閾値%を指定すると、その閾値%を超えた削除レコードが検知された際に、CPF4653 メンバーXXXのDLTPCTパラメータ値を超えている、つまりデータ・レコード数に対する削除レコード数の比率が限界を超えている旨のメッセージが送出される（図表4）。
削除済みレコード
https://www.ibm.com/support/knowledgecenter/ja/ssw_ibm_i_74/dbp/rbafoadr.htm
ファイル再編成による使用状況改善確認
さて、RGZPFMコマンドでファイルの使用状況は改善されたのだろうか。それは、該当ファイルの物理I/O数や論理I/O数が再編成後に減少したかどうかで確認できる。
QSYS2.SYSTABLESTATビューを利用すると、このカウントを取得し、システム上のテーブル（物理ファイル）の統計情報・メタデータを参照できる。
ファイル再編成の結果を確認するSQLサンプルとして、以下を紹介する。
このサンプルをファイル再編成の実行前後に取得することで、変化を確認する。実行結果例は図表5である。
この例では論理READ回数の多い上位20ファイルを取得するが、条件式を変更して、RGZPFMコマンドを実行したファイルの情報だけを直接参照するようにしてもいいだろう。
上記で使用されているSQLは、以下の処理を実行する。
NUMBER_DELETED_ROWS：削除済みレコード件数
LOGICAL_READS：IPL後の論理READ回数
PHYSICAL_READS：IPL後の物理READ回数
SEQUENTIAL_READS：IPL後のシーケンシャル（順次）READ回数
RANDOM_READS：IPL後のランダムREAD回数
QSYS2.SYSTABLESTATビュー
https://www.ibm.com/support/knowledgecenter/ja/ssw_ibm_i_74/db2/rbafzcatsyststat.htm
図表5でファイル再編成の効果を確認するには、以下の点に注意する。
①DATA_SIZEファイル再編成前後でファイルサイズの縮小を確認する。
②NUMBER_DELETED_ROWSファイル再編成後は0になっていることを確認する。
③LOGICAL_READSはメモリ上でのファイルREAD回数、PHYSICAL_READSはストレージ上のファイルREAD回数を表す。ファイル再編成前後にこの2つが減少することを確認する。PHYSICAL_READSの多いファイルが使用頻度の高いファイルである場合は、適切なタイミング（IPL後や該当業務のピーク前など）にSETOBJJACCコマンドでメモリ上に強制ロードすることで、さらにパフォーマンス改善が期待できる。
④SEQUENTIAL_READSは順次読み取りされた回数、RANDOM_READSはキーアクセスでランダムREADされた回数を表す。この値もファイル再編成で効果があれば、回数が減少する。
エキスパート・キャッシュの設定
WRKSYSSTSコマンドを実行し、PF11キーを複数回押下して図表6の画面を表示する。
この画面上のPAGINGオプション欄を*CALC とすることで、エキスパート・キャッシュが有効となる。
*FIXED（エキスパート・キャッシュを使用しない）はAS/400 V1から存在するモードで、あえて利点を挙げるとすれば、ストレージとメモリ間をより小さいブロック単位で転送する、更新されたDBレコードをより頻繁に書き出す、という挙動によりメモリ使用量を最小化できる点である。
しかし昨今のPOWER5〜9モデルでは、AS/400時代よりはるかに潤沢なメモリを搭載しているので、原則的には*CALCに指定することを推奨する。
これによりエキスパート・キャッシュが有効となり、十分なメモリが使用可能な場合、より大きな単位でストレージからメモリへデータを転送する、ストレージへのデータ書き出し頻度を低減する、より多く参照されるファイルが常駐する可能性が高まる、などの効果によりパフォーマンス上のメリットを享受できる。
システム値 QPFRADJ
この値もIBM i パフォーマンスチューニングの基礎設定だが、あらためて見直しておこう。WRKSYSVAL QPFRADJコマンドを実行すると、現在の値が確認できる（図表7）。
設定可能な値は0、1、2、3であるが、特別な理由がない限りは2または3を推奨する。2の場合はIPL時と稼働中、定期的にパフォーマンスの自動調整を実施する。3の場合はIPL時の調整は行わず、稼働中の定期的なパフォーマンスチューニングのみを実行する。
自社システムでは実運用を通じて確認し、最適な値を決定するのが確実である。ちなみに実行されるパフォーマンス調整は以下の内容である。
*MACHNE：プールのサイズ調整
*BASE：プール・活動レベルの調整（*BASEプール内で同時に競合できるシステム・スレッドとユーザー・スレッドの最大数の調整）
*INTERACT：プールのサイズ調整と活動レベル調整
*SOOL：プールのサイズ調整と活動レベル調整
*SHRPOOL：1〜60のプールサイズ調整と活動レベル調整
著者
佐々木 幹雄氏
日本アイ・ビー・エム株式会社
パワーシステムテクニカルセールス
シニアITスペシャリスト
AS/400利用のお客様担当SEから出発し、さまざまなテクニカル職種を担当。現在はPower Systemsはじめインフラ提案・アーキテクチャ設計を主に担当している。
［i Magazine 2021 Winter（2021年1月）掲載］
特集｜Db2 for i 最新Tips～多彩な角度からDb2 for iの高度活用にアプローチする
PART 1 Db2 for i の歴史と拡張の方向性
PART 2 Db2 for i サービスとIBM i サービスの機能拡張
PART 3 IBM i Access Client Solutions（ACS）のDb2 for i 関連機能
PART 4 Db2 for iの日常運用を見直す
PART 5 Node.js on IBM iのDb2 for i 関連機能
PART 6 Db2 Mirror for iの概要と運用時の考慮点
Column SQLサンプルの活用法（IFSオブジェクトの管理）
