修改glogin.sql引发的生产系统监控的虚假报警

问题提出：
生产系统，收到报警邮件说open_cursors过多，马上登录到服务器上检查，发现open cursor最多的一个session才打开100多个cursor，应该没什么问题。但是一个小时后，又收到报警邮件，重新登录服务器，还是没什么异常。而且之后每个小时（这个规律是后来才发现的）都会收到报警邮件，每次都没有任何异常，这下找不到头绪了。[@more@]晚上回家，又收到这样的邮件，于是把所有这类邮件从第一封开始到最后一封看了一遍，又看了一遍发信的时间，才注意到每个小时都会发一封报警邮件。登录生产，检查监控的脚本（脚本为另一个同事写的，而且已经半年多没收到这样的报警了），脚本中定义的也是一个小时检查一次，也就是说每次监控脚本运行，都会发邮件出来，肯定是监控不对了。
生产系统是两台机器的RAC系统，从邮件标题看，信是从DB1发出的，检查DB1的脚本，没有任何异常。后来发现DB2从来没有发邮件出来，那么DB2的脚本应该是完全正确的，于是拿DB2的脚本去跟DB1的核对，看是否是DB1的脚本出现错误了。结果发现DB2监控脚本里面的提示全部是DB1的提示，于是把里面的提示全部改成DB2，然后运行一遍，马上收到了报警邮件，这说明问题是处在DB2上的。而由于当初上RAC的时候，这个监控脚本没有修改，导致DB2的邮件报警出现的却是DB1的提示，所以到DB1上死活也找不出问题所在。
查看监控脚本，是使用一个查询，如果查询返回的结果是3行，则说明没有异常，因为3行正好是sql提示和返回no rows的提示信息，如果返回大于3行，则发报警邮件，查看返回结果，发现每次执行返回结果都正好四行，而但sql的返回结果都是空。仔细查看，发现最后面有一行提示信息Executed in 0.807 seconds，到此问题已经完全暴露了出来了。
因为我习惯在glogin.sql中加上set timing on设置，这样每个sql执行完就会知道执行了多少分钟。那天因为频繁在DB2上操作，每次都设置set timing on太麻烦，于是就把它加到了glogin.sql中去了，这样就导致了监控脚本的返回会比原先多一行，而正好我只设置了DB2，没有设置DB1，而DB2报警邮件的提示却是DB1，误导了视线。一连串的正好导致了问题的发生。
总结：任何返回错误、报警、提示信息的地方，返回的结果一定要正确，这个在编写任何程序的时候，尤其大量使用CRTL+C和CTRL+V的时候尤其要注意。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25016/viewspace-927380/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25016/viewspace-927380/