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

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



VSAM/KSDSデータセットBUFNI別100,000レコード検索処理時間




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を追加することで行うことができます。

//KEYFILE  DD DISP=SHR,DSN=dsname,
//            AMP='BUFNI=4'




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