分类： 系统运维
2014-08-27 11:32:39
影响AS400平台应用系统运行性能的项目实施误区和纠正做法
一、问题的提出
1） PF带KEY
用DDS创建PF时，就指定记录的KEY，即索引键字。采用操作系统默认值创建PF带KEY，是实时维护键字排序。
在OS400下，用PF带KEY，操作系统只保留index文件，而没有按自然顺序输入的记录排序的记录文件。随着PF数据的日积月累，记录数不断增加，操作系统如果要实时维护索引文件的排序，就要耗费系统处理资源。如果在应用系统交易高峰期，或批处理时间段，操作系统除了要实时PF带KEY的索引文件的排序，还要实时维护这个PF相关的LF文件排序。这样重叠排序会增加系统资源的开销，缩短应用系统单位时间运行的有限时间。
2） 对多键字、又为一索引记录格式的文件LF采用动态索引操作
只有当组合键字的长度等于索引文件的键字的长度，索引文件使用才是最快的。
如果组合键字小于索引文件的长度，操作系统对每次操作代码的设置（SET），就要对这个索引文件重新排序，会增加系统资源的开销，缩短应用系统单位时间运行的有限时间。
3） 在程序代码中使用动态QUERY操作。
因为在CL中每一次运行OPNQRYF，在ASP临时数据内，如果这个query文件没有存在，就意味操作系统要创建一个临时的，且满足索引条件的数据文件。对海量记录数的PF来说，创建一个这样的文件要耗费系统资源，降低应用系统单位时间的有效运行时间。
4） 在代码中大量使用连接文件。
因为连接文件需要用键字进行连接，对海量记录的索引文件连接，连接文件相当于索引文件的条件筛选，操作系统维护这个索引文件的条件筛选，需要系统开销。
二、纠正方法
A） 保持PF原始输入的自然顺序。这样做可以很容易检查到断点环境的PF数据。
B） 在PF下创建LF，即index文件。对项目实施规划设计时，把可预见的所有LF文件，都用LF的多记录文件进行创建，因为这样创建，操作系统会对每一个LF的记录格式产生一个索引文件。对稍后期的LF文件，即在这个PF下创建LF时用多记录格式后，再补充创建相关的LF文件，采用另创建一个LF的文件做法，保持每一个索引文件有一个排序。
C） 对动态query的做法，可以采MQT 用SQL命令触发的数据重整形式代替动态query的做法。
D）对多文件关联的查询文件，尽量少用连接文件，或不用连接问题，而采MQT 用SQL命令触发排序和数据重整的做法。