[原]由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方面的改善还是成效显著的。