お手軽バッチ・パフォーマンス改善⑦更新版

【2010/08/17 original author KAMII】

データセットのI/O効率を上げる（続き）

VSAMデータセットのCIバッファーを増やす（ランダム・アクセス）

グラフは、KSDSのキーによるランダム・アクセスにおいて、INDEXコンポーネントのアクセス・バッファー数のみを増やしてみた場合の例で、バッファー数と実行時間および発行されたI/O回数と使用されたリージョン内メモリーサイズを示しています。実行時間は、VSAMがデフォルトで設定するCIサイズ（18432バイト）でデフォルトのINDEXバッファー数（1個）の実行時間を1とした場合の相対数値です。
ランダム・アクセスではシーケンシャル・アクセスほどバッファー数増加の効果は出ません。上のグラフ（CIサイズ512バイト：INDEXレベル3）の例では、インデックス・バッファー数が4になったところで効果が頭打ちになっており、下のグラフ（CIサイズ2048バイト：INDEXレベル2）の例では、インデックス・バッファー数が2になったところで効果が頭打ちになっています。
適切なインデックス・バッファーの数はINDEXレベルと大きな関係があり、INDEXレベルが大きければそれだけ索引レコードのアクセス回数が増えるので、インデックス・バッファーが多いと索引部のI/O回数は削減されます。しかし、もう少し何とかできないのかという感じです。なお、ランダム性が高いほどDATAコンポーネントのバッファーは増やさない方がいいです。一度にいくつものデータCIを繋げて読んでも結局使われずに捨てられるだけです。しかも個々のI/O時間（データの転送時間）は長くなるので、逆に実行時間が増えてしまうことにもなります。

INDEXコンポーネントのバッファー数の変更は、JCLのDDステートメントにAMPパラメーターでBUFNIを追加することで行うことができます。

BUFNIあるいはBUFNDパラメーターではなく、BUFSPパラメーターでバッファー数ではなくバッファーの大きさで指定することもできます。
ただし、KSDSの場合はINDEXのバッファーが多く獲られるかDATAのバッファーが多く獲られるかは、プログラムがデータセットをOPENした際にデータセットをどのようにアクセス（シーケンシャル・アクセスなのかランダム・アクセスなのか）するかで変わります。COBOLのACCESS IS DYNAMICのようにどちらのアクセスも可能にするようなOPENをすると、シーケンシャル・アクセスに適したバッファー割り振りがされてしまうため、その状態でランダム・アクセスを行うと逆に実行パフォーマンスが低下しかねません。ランダム・アクセスすることがわかっていてもプログラムが両刀使いできるように作られている場合は、BUFNIで明示的にINDEXバッファーを増やす方が確実です。

【2010/08/17 original author KAMII】