eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

« Google Book上的Oracle图书 | Blog首页 | 不丹 与 梁朝伟、刘嘉玲的婚礼 »

歌华经历的数据库"攻击"

上周五,到歌华帮助诊断了一起数据库故障。
在故障时,数据库及其缓慢,用户任何请求都无法响应,数据库体现以"Cache buffer Chain" 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,最终转嫁到数据库上的负荷就成为了灾难。有时候在应用程序端做出适当限制和约束是必须的
奥运期间,安保第一,要加强防范。数据库也是如此!

-The End-


历史上的今天...
    >> 2012-07-22文章:
    >> 2007-07-22文章:
    >> 2006-07-22文章:

无觅

By eygle on 2008-07-22 09:21 | Comments (15) | Case | 1981 |

15 Comments

想请教:您是如何定位执行这2条SQL的client的呢?

分析监听器日志文件!

数据库体现以"Cache buffer Chian"
^_^错别字哦。

歌华?是不是就是卖奥运门票的那家?eygle叫人家送几张开幕式的票子吧。嘿嘿……

谁能送我两张奥运门票啊!!!

to Julia:你让eygle教我Oracle,我送你两张奥运门票,哈哈。我目前还有羽毛球,篮球,足球,跆拳道,棒球,:-)

呜哇~~~~~~~~好啊,附送Julia教你煲汤课程,你不要随便说说啊~~~~~~~~~~~

还有普通广东话、广东普通话、正宗广东话课程可以选择 !!

一旦学会煲汤,‘后患无穷’,哈哈,我只学Oracle。

你想要什么票? :-)

DB2更美好!

哈哈,其实这个系统是我们公司做的,问题也已经发现,看来客户对我们缺乏信心啊。

哈,世界是真小!
可以考虑改改程序防止类似的事情发生。

btw:看你们更改了些参数,你们应用有已知性问题?

Eric, 我都不好意思要,那么难买的票~ 我还是看看能不能买到残奥会的好了...

主要调整了cursor_sharing参数,应用的架构导致不能使用绑定变量;
另外那两个该死的sql让我很头痛,数据库方面想不出什么太好的调整方案,最后勉强在条件中加了时间条件,再建个索引,然后限制单位时间内点击次数;
感觉主要的问题还是设计问题,不过修改设计已然不可能鸟;
根据墨菲定律,奥运期间…… god bless me! ^^

路过,看看能不能留言


CopyRight © 2004~2020 云和恩墨,成就未来!, All rights reserved.
数据恢复·紧急救援·性能优化 云和恩墨 24x7 热线电话:400-600-8755 业务咨询:010-59007017-7040 or 7037 业务合作: marketing@enmotech.com