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的调整如下：

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

对于SM_HISTABLE参数调整如下：

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

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

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

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

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

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

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

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