SETOBJACC/CLRPOOL命令使用

li6612773

实验了一下，把pf加入内存后再处理，一个6400万的表12分钟处理完。 但是，可悲的是没加到内存里处理的时候也是12分钟，对于有读写，顺序访问的表没必要用setobjacc

http://blog.chinaunix.net/uid-2271579-id-3487396.html

passthru

"把pf加入内存后再处理，一个6400万的表12分钟处理完..."

‘处理’是什么？

在270环境下，读6400万条记录大约512秒。如果需12分钟，肯定每一条记录要经过‘处理’。用setobjacc把pf表装载或没有装载，这个pf表6400万条记录‘处理’，时间上都是一样。所以，肯定是每一条记录处理的时间与装载时间差别可以到用setobjacc的时间效果可以忽略不计。

li6612773

为了做测试，虚拟了一个场景，从表T1中读出，然后写入另一张表，再update T1的某个字段。

uxyzp

270是啥……

li6612773

机器回复 4# uxyzp


   

qiao_zq

楼主能否将在2种不同情况下具体的i/o次数列出来？

li6612773

回复 6# qiao_zq
由于是顺序访问，具体的IO应该和之前是相同的。
这个实验也验证了setobjacc在实际应用中只适合带key pf的随机访问场景，而对于顺序访问的应用作用微乎其微。

以下是IBM的专家在讨论中给出的建议，这里同时也感谢一下：

key和LF提升访问数据的效率的前提是访问的数据量占全表的15%以下，访问的数据越小，效率提升越高。有些业务应用，不得不按照某个key来遍历全表，即按照某个列的顺序来访问全表数据，这种情况下，由于对于每个key的值，我们无法预计下一个要读取的记录在哪里，所以，无法使用预读取技术，大量的随机读取，会导致访问效率的急剧下降。此时，将PF和LF通过setobjacc置入private pool才有明显的性能提升。也就是您说的频繁随机读取数据，这种情况，才需要setobjacc。setobjacc大多在日终批处理或联机业务的静态参数表使用。

没有办法，让pf加载到内存中后，更新和写数据的时候和物理磁盘脱钩，实现近似于完全内存操作的效果，以提高效率。
答：pf加载到内存中后，更新和写数据就是在内存中完成的。对于单纯的写操作来说，内存操作和磁盘操作，效率差别不大，因为写入cache就算写操作完成。除非有特殊的设置，要求一定数据落硬盘。


   

passthru

呵呵，节后，我测试一把再续这个话题。之前楼主所说的，我表示怀疑。