アクセス・パス・サイズ (インデックスと論理ファイル)

アクセスパスの論理ページサイズが、V4 のどこかのリリースをさかいにして 4 or 8K から 64K に変わっています。

Modernizing iSeries Application Data Access - a Roadmap Cornerstone の「4.2.2 SQL Indexes compared with keyed logical files」にインデックスとキー付き論理ファイルの比較が載っていますが、その中に"インデックスの論理ページサイズは 64K でキー付き論理ファイルは 8K である"旨の記述があります。
この違いについてはマニュアル等にもあまり記述が見つからなかったのですが、一応関係があって指標になりそうなのが「アクセス・パス・サイズ」という属性のようです。

かなり古い Redbook で The System Administrator's Companion to AS/400 Availability and Recovery というものがありますが、意外と有用な記述があります。たとえば「16.14 Considerations for 1TB Maximum Access Path Size」とか。


キー付き論理ファイル

昔からあるファイル (論理ファイル) を DSPFD コマンドで見てみましょう。
「アクセス・パス・サイズ」は「*MAX4GB」になっています。

全然別のファイルですが、新しく作成したインデックスを作成して見てみると、「アクセス・パス・サイズ」は「*MAX1TB」になっているのがわかります。

次に、こうした「*MAX4GB」のファイルが、現行のシステム上のどのくらいあるのだろうか、という思いますよね。
それを見る方法があります。

まず、出力ファイルを指定して、あるライブラリーの中のすべての論理ファイルの属性をリストします。

SQL や QRY などで、LGAPSZ というカラムを選択対象にして、他の見たいカラムを指定します。

だいたいこんなかんじの SQL でしょうか。

こんなかんじで結果がでてきます。
LGAPSZ が '0' のもののリストで、それが「*MAX4GB」になっているファイルの、当ライブラリーの中の全てということになります。

上の例で指定するのを忘れましたが、ファイル・タイプの指定 (データ or ソース) が LGDTAT というカラムによってできます。
LF の場合はあまり関係ないと思いますが、PF の場合には WHERE で "='D'" を指定しておいた方がいいでしょう。

インデックス

以前、別の例でも使いましたが、この環境の QIWS/QCUSTCDT というファイルには新規に作成したインデックスがついています。
それを材料にしてみましょう。

今度は「*MAX1TB」になっているかどうか、の確認をしてみましょう。

新規に作成したインデックスがでてきます。

テーブル

新しく作成したテーブルではどうなるでしょうか。

PF (物理ファイル) の場合もほとんど同じような手順になります。

カラム名が若干違いますが、ほとんど同じような SQL で結果を見ることができます。

TOKMSP_TBL は、さきほど CREATE TABLE QEOL/TOKMSP_TBL LIKE で作成したテーブルです。
「アクセス・パス・サイズ」が「*MAX1TB」、「アクセス・パス」が「到着順」になっているのがわかりますね。


変更 (PF の場合)

CHGPF コマンドでこの属性を変更することもできます。
ただし、実際にはインデックスの再作成がバックエンドで行われるので、コマンド自体は割合早く終わってしまいますが、データの大量に入っているファイルの場合はアクセス・パスが正しい状態になるまでアクセスできなくなってしまいます。もうそうなったらアクセス・パスのリビルドが終了するのを待つしかありません。もし実行される場合は、きちんと時間のある時に行ってください。

今までの手順で確認してみましょう。
ちゃんと変わっていますね。

変更 (LF の場合)

CHGLF コマンドでも同様にこの属性を変更できます。
当たり前と言えば当たり前ですが、インデックスの再作成が行われます。アクセス・パスのリビルドは CPU を大変消費しますし、なによりそれが完了しないとアクセスできません。十分に気をつけて、当コマンドの実行は行ってください。

ちゃんと CHGLF したものだけ変わっていますね。

[Top Pageに戻る]

Ads by TOK2