上周五，到歌华帮助诊断了一起数据库故障，并且进一步的达成了长期合作意向。
在故障时，数据库及其缓慢，用户任何请求都无法响应，数据库体现以"Cache buffer Chian" Latch竞争处于等待，CPU 100%。
由于是Oracle10g的数据库，到现场采集了几个AWR报告，找到了当时的问题。
注意到故障时段每秒逻辑读为：Logical reads: 84,949.93 ，这远远超出了正常范围。
而进一步的，在问题时段，Buffer Gets 最高的两个SQL分别执行了3168次和2926次：
而正常情况下，这两个SQL执行次数都在20次左右，这两个超长执行的SQL就是问题的罪魁祸首了。
在进一步的诊断发现，这两个SQL都是一个客户端不断发出的。我和客户开玩笑，这就是数据库攻击啊。
也许在客户端按一个F5,最终转嫁到数据库上的负荷就成为了灾难。有时候在应用程序端做出适当限制和约束是必须的。
奥运期间，安保第一，要加强防范。数据库也是如此！
在故障时，数据库及其缓慢，用户任何请求都无法响应，数据库体现以"Cache buffer Chian" Latch竞争处于等待，CPU 100%。
由于是Oracle10g的数据库，到现场采集了几个AWR报告，找到了当时的问题。
注意到故障时段每秒逻辑读为：Logical reads: 84,949.93 ，这远远超出了正常范围。
而进一步的，在问题时段，Buffer Gets 最高的两个SQL分别执行了3168次和2926次：
Buffer Gets Executions
70,568,785 3,168
69,189,653 2,926
而正常情况下，这两个SQL执行次数都在20次左右，这两个超长执行的SQL就是问题的罪魁祸首了。
在进一步的诊断发现，这两个SQL都是一个客户端不断发出的。我和客户开玩笑，这就是数据库攻击啊。
也许在客户端按一个F5,最终转嫁到数据库上的负荷就成为了灾难。有时候在应用程序端做出适当限制和约束是必须的。
奥运期间，安保第一，要加强防范。数据库也是如此！
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
