[原]由clob引发的性能问题所想到的（不是解决方案的方案）
前文再续，书接上一回，今天回到单位，终于可以在生产机器上进一步观察了，由于烂糟的设计，通过调整索引来提供性能是行不通了（也许是我的火候还不够），于是把最终目的定为减少可怕的 physical read 上，也就是把那堆clob缓存到内存中。
将clob缓冲的语句是：
alter table table_name modify lob(lob_column) ( cache | cache reads ) ;回滚的语句是：
alter table table_name modify lob(lob_column) ( nocache ) ;
把那个烂糟语句所用到的表的 clob 都缓冲进内存里。
做完之后，使用系统的人没有打电话上来，证明没有对业务系统造成冲击。我们对比一下调整前后的情况：
调整前：
[root@rac1-node01 ~]# iostat -k 5 5 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 1.98 0.00 47.52 0 48 sda1 0.00 0.00 0.00 0 0 sda2 1.98 0.00 47.52 0 48 sdb 2727.72 43097.03 50.00 43528 50*** sdc 0.00 0.00 0.00 0 0 sdc1 0.00 0.00 0.00 0 0 sdd 0.00 0.00 0.00 0 0 sde 0.00 0.00 0.00 0 0 sde1 0.00 0.00 0.00 0 0 sdf 0.00 0.00 0.00 0 0 sdg 0.00 0.00 0.00 0 0 sdg1 0.00 0.00 0.00 0 0 sdh 0.00 0.00 0.00 0 0 sdi 0.00 0.00 0.00 0 0 sdi1 0.00 0.00 0.00 0 0 dm-0 11.88 0.00 47.52 0 48 dm-1 0.00 0.00 0.00 0 0 dm-2 0.00 0.00 0.00 0 0 emcpowera 2.97 0.99 0.50 1 0 emcpowera1 2.97 0.99 0.50 1 0 emcpowerb 0.00 0.00 0.00 0 0
可以看到 sdb 的 tps 和 kB_read/s，都很大，这个还不是峰值呢，有时我能观察到100MB/s的传输率，如果按照我们以前的测试数据来看，最高的传输率能到140MB/s左右，没剩多少I/O能力让这个oracle 折腾的啦
调整之后：
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 1.98 0.00 51.49 0 52 sda1 0.00 0.00 0.00 0 0 sda2 1.98 0.00 51.49 0 52 sdb 147.52 2273.27 6.93 2296 7*** sdc 0.00 0.00 0.00 0 0 sdc1 0.00 0.00 0.00 0 0 sdd 0.00 0.00 0.00 0 0 sde 0.00 0.00 0.00 0 0 sde1 0.00 0.00 0.00 0 0 sdf 0.00 0.00 0.00 0 0 sdg 0.00 0.00 0.00 0 0 sdg1 0.00 0.00 0.00 0 0 sdh 0.00 0.00 0.00 0 0 sdi 0.00 0.00 0.00 0 0 sdi1 0.00 0.00 0.00 0 0 dm-0 12.87 0.00 51.49 0 52 dm-1 0.00 0.00 0.00 0 0 dm-2 0.00 0.00 0.00 0 0 emcpowera 4.95 1.98 0.99 2 1 emcpowera1 4.95 1.98 0.99 2 1 emcpowerb 0.00 0.00 0.00 0 0
注意这个基本上就是峰值了，可以看到这次调整大大地减少了 physical read 所产生的负面影响。
我们再看看AWR的对比报告：
明显 physical read 降低 71%。而内存方面，Buffer Cache 抢走了Shared Poll 100M左右的内存，约3%的波动。
再看看等待事件方面的变化：
CPU Time方面略有所降，估计原因是CPU在等待数据块的过程中，闩自旋的时间变短了所造成的，但是这个效果不太明显，毕竟这次调整没有调整到Top SQL的执行计划。direct path read 大大降低，但是db file sequential read 和 db file scattered read的比率上升了，我估计是由于对这些clob的缓存冲击了db buffer cache所造成的，但总的来说，在IO方面的改善还是成效显著的。
优质内容筛选与推荐>>1、Entity Framework Code First使用者的福音 --- EF Power Tool使用记之一
2、【转】数据库常用面试题
3、hdu6465 高斯消元
4、持续集成 - 省事方便的自动构建
5、关于HTTP协议，一篇就够了