ITPub博客

首页 > 数据库 > 数据库开发技术 > 修改glogin.sql引发的生产系统监控的虚假报警

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

原创 数据库开发技术 作者:zhang41082 时间:2019-03-28 11:18:04 0 删除 编辑
问题提出:
生产系统,收到报警邮件说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/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 纪念二姨父!
请登录后发表评论 登录
全部评论

注册时间:2002-10-11

  • 博文量
    105
  • 访问量
    83253