SSD与Fusion IO 实测随机读写 IOPS
现在的SSD和Fusion IO,不同厂家的做法也很不一样,这里整理一些实测值供参考。单盘挂PC,SSD SLC Iops 8k 随机读16500,Iops 8k 随机写11700 SSD MLC Iops 8k 随机读7074,Iops 8k 随机写3065 Fusion IO MLC Iops 8k 随机读53000,Iops 8k 随机写14200 Fusion IO MLC Iops 16k 随机读35000。Iops 16K 随机写6600这里Fusion IO是我压测的,写在4ms的响应时间内有个高峰,估计到2000多IOPS,但随着压力增大,很快就降下来,大部分时间都在12000上波动。附上B2B一哥们的SSD测试结果,其中SLC与我们测试结果相近。一款MLC的SSD测试结果:8k ra
enqueue HW wait 引起表空间突然大量扩展
我们在10.2.0.4上遇到过好几次了,enqueue HW wait不仅堵塞了事务,表空间也一下被用了很多,后来每次都预留几十GB的空间,但事务还是被堵塞,下面说说这个WAIT。在高并发的oltp数据库,平时150多的active session,数据库的总session数会经常波动,可能从1000波动到1500或2000,几分钟后又回到1000左右。一个表同时有大量的insert或update时,会有enq HW wait。因为insert/update会请求空间,而如果HWM下的free list 用完,没有剩余的数据块时,请求段内的空数据块,高水位往上移。而每个请求都需要HW enqeue。出现排队,此时如果高水位之
prepare statement cache size influence database
调整prepare statement cache size对数据库的影响,简单的说这个statement cache设置在应用端,缓存了应用到数据库的一些sql。[@more@]关于这个参数的说明: Statement caching improves performance by caching executable statements that are used repeatedly, such as in a loop or in a method that is called repeatedly. Starting from JDBC 3.0, JDBC standards define a statement-caching interface. Statement caching can do the following: * Prevent the overhead of repeated cursor creation * Prevent repeat
加数据文件引起load上升
昨天同时说数据库的load突然飙升了一下,幸好应用没有什么异常。记得上次也是linux上添加ext3上的数据文件,把os给搞hang,怎么也ssh不进去,后来重启解决的。避免添加 datafile给数据库造成冲击的方法,一是选择业务低峰操作;二,一次添加几个文件,停几分钟,再添加其他的。用sar -B发现4:00PM 有较大的pgpgout11:00:01 AM pgpgin/s pgpgout/s fault/s majflt/s03:20:01 PM 1744.57 210.01 6474.38 0.0003:30:01 PM 1769.84 209.52 6422.80 0.0003:40:01 PM 1844.21 223.05 6708.21 0.0003:50:01 PM 1800.47 211.58 6500.01 0.0004:00:
11g卸载脚本
今天在装完11g后想卸载,从runInstaller找不到卸载的入口了。最后发现$ORACLE_HOME目录下有卸载脚本,跑完后很干净,重装很顺利。oracle确实为用户考虑了很多东西。[@more@]
oracle从10.2.0.4升级到11.2.0.1的三种升级方法
最近做了下实验,尝试oracle dataguard 从10.2.0.4升级到11.2.0.1,可以有三种升级方式。