Admin Alert: IBM i ファイルを再編成してディスク・パフォーマンスを改善する、パート 1
IBM i のパフォーマンスを改善する最も簡単な方法の 1 つとして、重要なファイルすべてを定期的に再編成する方法があります。削除されたレコードが過剰に蓄積されているファイルは、読み取りに時間がかかります。リターン・レコード・ブロックそれぞれに削除されたレコードとアクティブなレコードが含まれているためです。次の 2 つのコラムで、最もアクティブなファイルを検出して編成し、ディスク処理効率を改善するためのテンプレートをご紹介します。
なぜ再編成するのか
次のように、非常に大量の削除レコードを含んだファイルを再編成するには、それ相応の理由があります。
1. ディスク・スペースの確保
ディスクが満杯になっている場合、大規模ファイルから削除レコードを絞り出すことで、かなりの非生産的なディスク・スペースを確保できます。通常のファイル再編成を利用して、ショップが 5 から 10% のディスク・スペースを利用できるようにしているのを私は見てきました。
ただし、その 5 から 10% の削除レコード・スペースが永遠に確保されるなどと、あまり期待しないでください。往々にして、ファイル再編成は、一時的なディスク・リカバリー手法です。自分のアプリケーションの動作具合によって、5 から 10% のスペースを利用できるようにしても、結果として翌日には、アプリケーションにさらに多くの削除レコードで、そのスペースを再度満杯にさせてしまうおそれがあります。定期的なファイル再編成で、削除レコード・スペースを取り戻すことができますが、経験上、強引な再編成キャンペーンを仕掛けた後は、保管のために新たにベースラインを低く設定してしまいます。しかし、ファイル再編成をそこそこ使用することで、利用可能なディスク・スペースを増やすことができます。再び取り込むことができるディスク・スペース量が限界に達したら、次のように他の手法で、さらにディスク・スペースを確保する必要があります。
- 大量のアクティブ・レコードを含む作業ファイルを特定し、消去する。
- 企業ポリシーにしたがって、指定数年分のレコードのみ保存するという、レコード保存ポリシーを適用する。
- 過剰なスプール・ファイルをクリーンアップする。
- 廃止されたファイルおよび冗長ファイルを除去する。
再編成は、ディスク・スペース確保と言うパズルの 1 ピースに過ぎません。IBM i ディスク・スペースについて詳しくは、この記事の最後にある「Related Stories」セクションをご覧ください。
2.パフォーマンス改善
大量の削除レコードがあるファイルの処理には時間がかかります。大量の削除レコード (数百万レコード) がある、または削除レコード対アクティブ・レコード率が 1:1 以上のアクティブ・レコードで、レコード単位で読み取るディスク・アクティビティーにより、そのファイルを読み取るごとに処理が遅くなる可能性があります。これは、アプリケーションがレコードを要求すると、IBM i は、次に読み取る予定のレコードを含んでいるかもしれないレコードのブロックを返し、レコードが要求されるたびに、複数回のディスク読み取りをする必要をなくしているためです。ファイルに大量の削除レコードが入っていた場合、IBM i は、ディスク読み取りを行うたびに、それほど多くのアクティブ・レコードを返すことはできません。つまり、定期的に再編成されているファイルを読み取る場合より、極めて大量の削除レコードがあるファイルを読み取るほうが、時間がかかるということです。定期的な再編成は、常時使用されているファイルについて、ディスク読み取りパフォーマンスとバッチ・ジョブ・パフォーマンスの改善に役立ちます。
ファイルを効果的に再編成する手順
定期的なディスク再編成の恩恵を受けるには、効果的なディスク再編成戦略の次の 4 つの手順に従う必要があります。
- 再編成の必要なファイルおよびメンバーを特定する手順をセットアップする。
- Reorganize Physical File Member (RGZPFM) ステートメントを正しくセットアップする。
- 重要なファイルを再編成できる回数を特定する。
- クリアして、繰り返す。
この記事では手順 1 を説明します。次回に、ファイルを再編成してアプリケーション効率を向上させるいくつかの方法を含め、手順 2 から 4 について説明します。
手順 1:
再編成の必要なファイルおよびメンバーを特定する手順をセットアップする
成熟したオペレーティング・システムである IBM は、どのファイルに大量の削除レコードが含まれているのかを迅速に特定する、多数のツールを提供してきました。これらのツールは 2003 年に遡って入手することができます。私が作成したユーティリティーは REORGMAP で、IBM i システム上の全ファイルを照合し、各ファイルにあるアクティブ・レコードと削除レコードの数をリストします。このユーティリティーは、削除レコード情報についてマイニングできる qgpl/reorgmap という作業ファイルに情報を出力します。
このユーティリティーを作成した数週間後、物理ファイルのメンバーごとにアクティブ・レコードと削除レコードの情報を表示するよう REORGMAP を修正しました。この 2 つの記事で説明した手法は 2014 年の i 7.1/6.1 時点で有効で、私はまだこのユーティリティーを使用しています。まとめると、これら 2 つの記事では、どの IBM i ファイルが、再編成が必要か判断する場合に使用できる、ファイル情報ファイルを作成するためのテンプレートを形成することができます。
過剰な削除ファイルを取り除くため、どのファイルを再編成する必要があるかを特定するには、次を実行します。
1. 情報ファイル、qgpl/reorgmap ファイルを自動的に作成するよう定期ジョブをセットアップします。このファイルの作成方法を示す私の記事については、下記の「Related Stories」セクションにあるリンクをご覧ください。自分の好みのスケジュールでジョブを実行するようにセットアップします。
2. qgpl/reorgmap ファイルが作成されたら、次の SQL ステートメントを使用して、どのファイルに最も大量の削除レコードがあるか特定します。
SELECT * FROM qgpl/reorgmap ORDER BY mlndtr desc
SQL を使用しているため、Start SQL (STRSQL) コマンドを使用するか、Microsoft Access や Microsoft Excel などの外部アプリケーション、または別のサーバーにあるカスタム作成のアプリケーションからステートメントを実行して、このコマンドを実行することができます。
3. 返された SQL リストは、どのシステム・ファイルに最も大量の削除レコードがあるかを表示し、削除レコードがある全ファイルを降順に表示します。最も削除レコードが多いファイルが先頭に、次に削除レコードが多いファイルを 2 番目にといった具合に表示します。
ここから、どのファイルを再編成する必要があるか特定できます。
この続きはパート2をご覧ください
パート2では、次のように少なくとも 4 種類の方法で IBM i 物理ファイルを再編成できる方法を見ていきたいと思います。
- おなじみの退屈な再編成手法
- 再編成を取り消しできる部分ファイル再編成
- 関連する物理ファイルを再編成する際に、関連する論理ファイル・アクセス・パスを再ビルドする方法の変更
- ファイルがアクティブ中にファイルを再編成するためのオプション
