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

« 案例分析:事情的开始是这样的 | Blog首页 | 《Oracle DBA手记 2》即将出版 »

案情分析:数据库的基本情况

今天又遇到了一些问题,然后又有了新的发现,从1.3G的sysstemstate dump文件中看到很多明确的线索。

继续说一下数据库的基本状况,原本是10.2.0.3的数据库,然后升级到10.2.0.4,数据库硬解析稍高,相关数据是15分钟的采样:
User calls: 10,845.57 166.13
Parses: 3,100.26 47.49
Hard parses: 368.77 5.65

通常row cache objects的竞争高,可能会考虑到DC层指标会高,其实不然:
dc_histogram_data 20,773,204 0.03 0   0 13,568
dc_histogram_defs 10,247,344 0.06 0   0 8,351
dc_object_grants 491 8.96 0   0 38
dc_object_ids 26,478,232 0.00 0   0 1,470
dc_objects 435,039 0.19 0   0 770
dc_profiles 1,546 0.00 0   0 1
dc_rollback_segments 9,579 0.00 0   0 829
dc_segments 2,813,316 0.04 0   4 1,556
dc_sequences 4,814 0.19 0   4,814 5
dc_table_scns 26,895 0.09 0   61 35
dc_tablespace_quotas 2 100.00 0   0 1
dc_tablespaces 782,069 0.00 0   0 17
dc_usernames 42,627 0.04 0   0 13
dc_users 760,063 0.00 0   0 53

看起来dc_object_ids,dc_histogram_data 稍微高一点。

数据库不存在简单的SQL问题、Sequence问题,物化视图的Bug已经考虑屏蔽掉,升级后证实与其无关,Cursor Pin S的相关Bug也与此无关。

Row Cache的使用主要集中在以下三个方面:
row cache objects kqrpre: find obj 0 162,138 161,288
row cache objects kqreqd 0 151,788 153,686
row cache objects kqreqd: reget 0 151,463 152,029

内存管理都是静态的,不存在动态调整引发问题的可能。内存基本设置如下:

BeginEnd

Buffer Cache: 20,480M 20,480MStd Block Size: 8K
Shared Pool Size: 4,000M 4,000MLog Buffer: 14,284K

这些都是关键的因素,有些我现在还在思考。



历史上的今天...
    >> 2008-10-15文章:
    >> 2006-10-15文章:
    >> 2004-10-15文章:
           关于PUSH_SUBQ提示的说明
           Dataguard配置Step by Step

无觅

By eygle on 2010-10-15 00:26 | Comments (11) | Case | 2636 |

11 Comments

上一篇鄙人的发言, 号称成功了. 实际上是失踪了. 郁闷.

如果我也懂该多好。。。

我来学习一下~~

暂时还不太明白!

DDL吧,这么麻烦?

要不就是分区

bug 5570942的状况和这个很相识,但是你说已经排除物化视图bug了
期待后续

我能来现场学习么?

就是小罗上次说的那个诡异的库啊,大师出手果然不同凡响啊

1) 建议收集更细粒度的数据,Session wait, SQL,wait_event等。
2) 曾经越到过同样的问题,能否检查下Top exec SqL情况,sql的执行次数等。


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