3月27日 简单任务 （4）更大的意外

昨天晚上调整了表结构，我建议把REDO LOG也相应做些调整。目前南坪系统的LOG BUFFER是1M，REDO LOG文件大小是61M，人和系统的LOG BUFFER是120K，REDO LOG文件大小是100M，不过人和系统每个日志组有2个成员。对于这种REDO量十分高的系统，使用2个成员虽然增加了可靠性，但是对性能的负面影响也是很大的。因此我建议将人和系统的REDO LOG成员改为1个。

昨天晚上调整建表脚本的同时，我针对数据库进行了一些调整，其中SGA和REDO的调整如下：

参数	当前值	建议值	设置原则
DB CACHE SIZE	NP:3072M RH:2048M	NP:4096M RH:2048M	对于本系统，在内存充足的情况下，设置DB CACHE，尽量使DB BUFFER的命中率提高。如果人和系统扩容后内存充足，增加DB CACHE的大小，可以提高查询和单条INSERT的性能（如不使用FORALL操作）
DB KEEP SIZE	未设置	NP:300M RH:300M	将HISTABLE以外的常用对象放入KEEP池
LOG BUFFER	NP: 1024000 RH: 124416	NP:20M RH:20M	设置LOG BUFFER的原则是使系统在忙时不出现log buffer space等待
SHARED POOL SIZE	NP: 314572800 RH: 318767104	NP:400M RH:400M	设置比较合理的时候，不会出现较多的LIBRARY CACHE和SHARED POOL闩锁等待
REDO LOG文件	NP:61M RH:100M	2000M	业务高峰期，减少日志切换

南坪系统的REDO LOG文件以前存放在HDISK2上，而UNDO,TEMP以及一部分索引所在的表空间也使用了HDISK2，为了减少IO方面的争用，把这些索引存放在其他表空间上，同时把UNDO表空间移到HDISK3上。

对于SM_HISTABLE参数调整如下：

南坪和人和平面的SM_HISTABLE表的存储参数设置建议如下：

参数	当前值	建议值	说明
FREELISTS	1	8	不小于最大并发插入进程的数量
INITIAL	64K	8M
NEXT	64K	8M
INITRANS	未设置	8

对于南坪和人和平面的SM_HISTABLE表的索引的存储参数设置建议如下：

参数	当前值	建议值	说明
FREELISTS	1	8	不小于最大并发插入进程的数量
INITIAL	64K	4M	最小设置为2M
NEXT	64K	4M	最小设置为2M
INITRANS	未设置	8

昨天晚上停了1个小时数据库，还好华为的短信平台设计的很灵活，数据库停止后，所有的话单被暂存在内存中，内存缓冲区满和后会转储到文件中。因此停数据库对短信业务并无影响。数据库重启后，1小时的短信话单被集中写入，事后经过业务部门的确认，最高峰的时候，南坪和人和系统短信话单的插入数量达到了惊人的5800条/秒，而从系统监控上看，CPU负载不到50%，IO负载也在40%左右，看样子系统还是有很大潜力的，以这样的性能情况来看，这个项目应该可以圆满的结束了。

按照以往的惯例，做完实施后的第二天早上我早早就到了客户现场，系统运行的很平稳，CPU使用率在20以下，IO也很小。这是我意料之中的事情，于是我打电话和余经理通报了一下今天的情况。然后进行了两项测试，第一项测试是创建一张和原来一样的表，测试一下调整了REDO后，性能有多大的提升。测试结果让我感到十分惊讶：

基线1（RUNID 10）		优化前南坪的REDO LOG设置
指标或参数		数值	备注
LOG BUFFER		1000K
日志组数量		8
日志文件大小		60000K
表分区方式		范围
执行次数		50000
执行时间		37968
平均每个INSERT的时间		0.75936
日志切换时间		11秒
主要等待事件		LOG BUFFER SPACE  BUFFER BUSY WAIT LOG SYNC
基线2 (RUNID 11)	优化后的测试基线
指标或参数	数值			备注
LOG BUFFER	20M
日志组数量	3
日志文件大小	1500M
表分区方式	范围
执行次数	50000
执行时间	24189
平均每个INSERT的时间	0.48378			提高57％
日志切换时间	5分钟
主要等待事件	BUFFER BUSY WAIT

本次测试是模拟实际生产环境中写入进程的工作，先启动7个插入进程进行插入操作，在第8个进程中使用PROFILER进行跟踪，每个批次插入800条记录，循环50000次。优化前和优化后的性能对比十分惊人，居然性能提升了57%。这是我预想不到的。后来我又在人和的系统上做了一个同样的测试，虽然性能提升没有南坪那么明显，不过性能也提升了38%。

我马上给北京的老方打了个电话，告诉他这里的优化效果。老方感到十分惊讶，这个项目真可谓是柳暗花明，原本以为很难搞定的项目居然通过简单的调整了一些参数就取得了这么大的效果。

下午的总结会上，大家心情都不错，小余望着窗外久违的阳光说：“按理说，这么好的天就不应该上班，应该找个茶馆喝茶去”。大家听了都乐了，我说：“干脆我们找个茶馆去开会算了”。任务完成的不错，大家的心情当然就好。

这个优化项目很成功，第二年除夕的时候，我收到了小余的一条短信：“今天系统一切正常，谢谢你，祝你新年愉快”。春节的时候收到远在千里之外的美女的祝福，确实是件很爽的事情。