对于互联网企业后台的数据库来讲, 有效的性能监控与报警是非常重要的, 一般来说数据库上的并发事务大, 任何地方出错后, 就会导至数据库进入恶性循环, 如果未及时解决, 要么数据库挂起, 要么让应用挂起, 方能得到最后解脱. 有钱的单位请专门的人员进行7×24小时监控, 专门盯着数据库主机Load的变化, 或者是安装监控程序进行5分钟数据采样, 并根据Load或CPU利用率情况进行报警, 如Nagios等.

    从实际情况看来, 专人看管和5分钟的监控都不够好, 5分钟可以重起一次一般的数据库了. 监控的频率很难选择, 监控报警的标准很难确定. 关键在于要有良好的性能数据, 及根据这些性能数据的有效报警机制. 用oramon收集Oracle的运行性能数据, 将报警机制集成到实时采集oramon数据的程序中, 就完美解决了这个事情.

    昨天用Perl重写了oramon数据采集程序, 一是要集成报警功能, 二是性能测试库不一定用Oracle, 可能会用MySQL, 以后也可以用Postgre SQL等, 还是选用脚本型语言较好. oramon以十秒的频率采集数据, 在报警时没有根据一个点的数据来确认是否报警, 而一律根据最后5个采样点的数据, 也就是接近一分钟内5个数据的平均值来判断. 经过一天的测试, 最后的报警条件设置如下.

    活动会话: 如果最近5个点的活动会话数都大于大于某个值(根据各个数据库的情况, 设置不同的值)就报警. Enq会话: 如果最近5个点的处理Enqueue等待的会话数都大于10就报警. IO等待: 如果最近5个点CPU WIO的比例值都大于40就报警. CPU使用率: 如果最近5个点CPU User的比例值都大于80就报警. 并行进程: 如果最近5个点活动并行进程的值都大于4就报警.

    利用oramon收集的数据, 可以根据很多有意义的性能数据进行报警设置, 如Swap IO情况, 如physical read, db file scatter read, 平均db file sequential read的等待时间, 还可以根据从Oracle层面计算出来的IOPS量进行报警.

    将报警机制集成在数据扫描程序中, 可以使报警变得很及时, 出现情况一分钟就可以报出来. 另外根据5个点的数据来报警, 误报的机率大大降低. 例如今天就根据Enqueue等待的报警及时发现了问题. 有这样的报警系统才能掌控数据库的运行, 才能做到心中有数, 安心睡觉.