Oracle 10.2.0.3 Bind Peeked Parallel Bug

昨晚11:30,客户电话,报告数据库服务器CPU负载陡然上升到95%以上,并且报ORA-4031错误。12:00赶到现场。 查看故障发生期间的AWR报告。 1. 最高的等待事件是“latch: library cache lock”和“latch: library cache” 2. Shared Pool Memory Usage 达到了98% (Shared Pool Size: 4,096M) 3. SQL ordered by Elapsed Time部分显示一条SQL占用了91.9%的总时间 4. SQL ordered by CPU Time 部分显示同样这条SQL占用了91.9%的CPU时间 5. SQL ordered by Sharable Memory部分,大批Executions=N/A的SQL,并且最高的一条SQL已经消耗了将近2G的Sharable Memory 6. SQL ordered by Version Count部分,刚才那句占用了将近2G缓存的SQL有高达77,237的Version Count 至此,大概可以猜测整个问题的发生原因了。因为过度的Version Count导致Shared Pool消耗殆尽,在Library Cache中开始频繁获取空闲空间以parse新进的SQL,于是产生大量的library cache latch,最终Shared Pool中再也无法找到足够解析一个SQL的空闲空间,于是报ORA-4031。整个系统全线崩溃。 那么现在问题就在于为什么会有如此巨大的Version Count?…

Oracle广州招聘高级售前顾问

代发招聘,我怎么不去做HR? 广州数据库售前部门,需要一个高级销售顾问。有意者请直接邮件给George Qi (祁国辉):guohui.qi [at] oracle.com POSITION SUMMARY : 1. Partner with CMU, FSI, MRD and GEH Sales Representatives by providing the necessary support to compete effectively with key competitors 2. Provide technical pre-sales services to customers (technical support, presentations, demonstrations, pilots, installations) using Oracle database (main focus) and related technologies (first-level knowledge on Fusion…

DBA的6:30

昨天晚上跟几个大学时候一宿舍的哥们儿high到临晨3点半,嗯,我们去三里屯看了钢管舞,mm很是不敬业嘛,表情忒冷漠了。sorry,跑题了。 早上手机响,客户电话,一看时间,6:30,上帝啊~~~~ “忽然一个SQL不走索引,走分区全表扫了,CPU Load极高” “表分析了吗?” “分析了” “索引呢?” “用的DBMS_STATS包,cascade=true,昨天还是好的” “加partname参数,单独分析一下这个分区,不行再给我电话” Zzzzzzzzz 手机响,客户电话,7:20,牛魔王啊~~~~ “还是不行啊” “嗯…..” “再不改成使用索引,没法儿开业了,要不你赶紧过来一趟?” “大哥,我才睡了3个多小时” “那也没办法啊” “你上MSN,等我一会儿” “好” 然后起床,开笔记本,幸好家里是WiFi,可以趴床上直接MSN。 “现在你们能改程序吗” “开发就在旁边” “加hint,改程序,一劳永逸” “怎么改” “帖给我你那条忽然不走索引的SQL” “select ….” “select /*+ INDEX(Table_name Index_name)*/ ….” “OK,这样走索引了,马上让开发改” “好,那我睡了” Zzzzzzzz 手机响,客户电话,8:30,香蕉你个疤瘌啊~~~~ “我们还想把一条SQL用hint固定执行计划,但是这条SQL加了hint也不走索引” “SQL我看看” “select /*+ (Table_name Index_name)*/ ….” “你这hint写的也不对啊,少了个INDEX,应该是select /*+ INDEX(Table_name Index_name)*/” “。。。。我晕了,4点被抓过来干活的” “你狠” 然后我就不困了。。。所以有这篇blog。 BTW: 客户的DBA跟我是哥们儿了,所以万一你看到这篇文章,一笑了之哈。