wisdomone的top 5 library cache mutex x

wisdomone1

各位大牛好：
    awr中top5排首为library cache mutex x;
Top 5 Timed Foreground Events

Event        Waits        Time(s)        Avg wait (ms)        % DB time        Wait Class
library cache: mutex X        38,001,653        1,097,433        29        66.95        Concurrency
db file sequential read        10,093,326        352,657        35        21.51        User I/O
DB CPU                 115,600                 7.05         
latch: cache buffers chains        800,279        34,512        43        2.11        Concurrency
db file scattered read        226,327        6,741        30        0.41        User I/O


---硬解析很低；   
User calls:         56,660.4         93.8                  
Parses:         1,881.1         3.1         

--version_count也不高，最高才80个

Version Count        Executions         SQL Id        SQL Module        SQL Text
80        81,143        ayvfafpr53d34                 insert into CP_TMS.TMS_MAIL_PO...
63        382,695        g61pdxvgp6wgt                 update tms_mail_monitor_info s...
35        1,308,456        2mn1hhpgw9n6g                 select * from ( select p.*, w....
35        1,308,456        2mn1hhpgw9n6g                 select * from ( select p.*, w....
30        182,654        4a4kr636txhw4                 insert into CP_TMS.TMS_MAIL_MO...
23        677        cxfspv17xb542                 insert /*+ append */ into vw_e...
22        5        adfcd02jcf4xc         DBMS_SCHEDULER        INSERT /*+append*/ INTO SE_TMP...


--Library Cache Activity,reload和invalidations有些高吧

Namespace        Get Requests        Pct Miss        Pin Requests        Pct Miss        Reloads        Invali- dations
SQL AREA        5,752,404        0.04        77,676,677        0.15        21,945        12,119

---如上皆不明显，是否为BUG呢？
https://support.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=488376014159452&id=727400.1&_afrWindowMode=0&_adf.ctrl-state=1d92goqdrn_333

我根据如上的MOS文档727400.1好像也不是BUG;


再看TOP 5第二个等待事件：
db file sequential read
此事件产生原因：
1,过小的buffer cache，导致过量的IO
2,选取了过差的索引或不合理的索引，导致IO增加
3,索引的CLUSTERING FACTOR过高；导致IO增加
4,行链接或迁移产生过量多余的IO
5,统计信息不准导致CBO选用了INDEX SCAN，IO增加

查看AWR中的IO统计部分，在此我仅摘举几条，属于表空间tms和tms_idx的数据文件平均读取时间大大超过了20ms;
Tablespace        Filename        Reads        Av Reads/s        Av Rd(ms)        Av Blks/Rd        Writes        Av Writes/s        Buffer Waits        Av Buf Wt(ms
File IO Stats

TMS        +DATA2/tmsdb/datafile/tms.280.814312597        9,215        3        55.62        20.00        24,603        7        10        81.00

TMS_IDX        +DATAIDX/tmsdb/datafile/tms_idx.260.813374823        63,947        18        40.25        1.00        71,569        20        128        21.72

另外：
Load Profile
Per Second        Per Transaction        Per Exec        Per Cal       
Block changes:         95,415.6         157.9         
基本每秒为700m的数据量变化，数据库蛮BUSY的

－－如下可知主机CPU很闲；压力很低；而ORACLE占用的CPU很低，仅25.9%
Host CPU (CPUs: 128 Cores: 64 Sockets: 8)

Load Average Begin        Load Average End        %User        %System        %WIO        %Idle
116.51         70.94         23.3         2.3         31.5         73.1

Instance CPU

%Total CPU        %Busy CPU        %DB time waiting for CPU (Resource Manager)
25.9         96.2         0.0

我想请问的是：

基于这个awr,
问题：
1,诊断思路是如何的呢，我的思路对吗?
2,大家谈谈思路与方法

tom0732

Bug 13810393 - Deadlock waiting for 'library cache: mutex x' while producing an ORA-4031 diagnostic dump [ID 13810393.8]
这个补丁打过没有。

wisdomone1

目前仅有AWR，谢谢TOM0732.大家继续哟，谢谢

wisdomone1

tom0732 发表于 2013-6-18 18:18
Bug 13810393 - Deadlock waiting for 'library cache: mutex x' while producing an ORA-4031 diagnostic  ...

        Bug 13810393 - Deadlock waiting for 'library cache: mutex x' while producing an ORA-4031 diagnostic dump [ID 13810393.8]

此BUG在抛出ORA-4031 DUMP时产生，本系统和这个并不相符啊；alert没报这个错误 啊

digdeep

你的RAC，目的是HA，没有使用LB?
为什么SQL都是dbms_scheduler?

redo和逻辑读 太多了，估计存储抗不住了。
至于 library cache mutex x，可能是bug。也可以从v$session_wait入手查看。

digdeep

SQL ordered by Parse Calls 部分比较奇怪。

wisdomone1

另一同事正在跟踪后续，可能是BUG；已打了PSU

wisdomone1

digdeep 发表于 2013-6-19 15:00
你的RAC，目的是HA，没有使用LB?
为什么SQL都是dbms_scheduler?

为何没开LOAD BALANCE，客户让关了。具体也不清楚为何CLOSE IT

wisdomone1

digdeep 发表于 2013-6-19 16:31
SQL ordered by Parse Calls 部分比较奇怪。

我看PARSE CALLS很正常啊。为何说奇怪？？parse_calls包括hard and sort parse,
parse_calls基本=exections