主机IO、内存都一直100%，数据库非常慢，awr报告请大家帮忙看看呢

zergduan

把主机的性能监控结果发上来，你的系统到底是什么状况

lfree

感觉不是绑定的问题。
你的系统问题多多，优化sql语句，内联流量太大，到达了
Estd Interconnect traffic (KB)        24,593.61        24M .

很多语句没建立索引。

zergduan

lfree 发表于 2015-12-16 16:43
感觉不是绑定的问题。
你的系统问题多多，优化sql语句，内联流量太大，到达了
Estd Interconnect traff ...

但是gc等待不在top5， 估计搞定硬解析后，就会体现出来了~

lfree

81,601,268         53,690         1,519.86         36.45         3187.75         6083.21         22agxp9gdq847                   select ARGUMENT_NAME, DATA_TYP...
9,958,294         53,691         185.47         4.45         1018.40         4328.46         7stjrknahbpj2                   BEGIN PKG_K_ZFJK.PRC_K_INERFAC...

--这个正好成对，应该每次调用这个包就会执行最上面的语句。

--不能解决，耍的无赖，在该用户建立以一张user_arguments 表，欺骗它，我第一次遇到好像是delphi的程序。

lfree

library cache load lock，记忆里第一次遇到。

select * from v$event_name where name='library cache load lock'
l> select * from v$event_name where name='library cache load lock';

    EVENT#   EVENT_ID NAME                 PARAMETER1           PARAMETER2           PARAMETER3           WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS
---------- ---------- -------------------- -------------------- -------------------- -------------------- ------------- ----------- --------------------
       219 2952162927 library cache load l object address       lock address         100*mask+namespace      3875070507           4 Concurrency
                      ock

参数1是object address 。

select * from v$active_session_history where event='library cache load lock';
确定object address 。顺着往下查，确定是什么对象。

lfree

library cache load lock，记忆里第一次遇到。

select * from v$event_name where name='library cache load lock'
l> select * from v$event_name where name='library cache load lock';

    EVENT#   EVENT_ID NAME                 PARAMETER1           PARAMETER2           PARAMETER3           WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS
---------- ---------- -------------------- -------------------- -------------------- -------------------- ------------- ----------- --------------------
       219 2952162927 library cache load l object address       lock address         100*mask+namespace      3875070507           4 Concurrency
                      ock

参数1是object address 。

select * from v$active_session_history where event='library cache load lock';
确定object address 。顺着往下查，确定是什么对象。

zergduan

zergduan 发表于 2015-12-16 16:34
还是在做swap~

那说明你的内存不足，你应该降低SGA了

我有一个想法，内存不足导致swap，swap导致high io（rootvg） 和 high cpu~

而high cpu导致mutex（cursor: pin S wait on X） ，而mutex导致library cache load lock

所以最终还是解决swap~

LZ就是不发操作系统的性能监控结果~
只能瞎猜~

lfree

zergduan 发表于 2015-12-16 16:45
但是gc等待不在top5， 估计搞定硬解析后，就会体现出来了~

我对医保非常熟悉，医保的绑定做的相对很好的，问题主要第1个，
平时应该不会出现，结果第2个我觉得是蝴蝶效应。附带上来的。
就好像出现了行锁，tx－row lock的等待哪怕是几分钟累积起来也是很大的，但是对系统其它用户影响很小。


排除这2个因素，就是他的系统没有优化好。看看单块读的ms 9ms 这个对这样的系统会很慢的。

lfree

另外lz能提供另外一个实例的awr报表吗？
还有那个时段的addm报表，2个。
问题就好定位了。

zergduan

lfree 发表于 2015-12-16 17:05
我对医保非常熟悉，医保的绑定做的相对很好的，问题主要第1个，
平时应该不会出现，结果第2个我觉得是蝴 ...

9ms不错了吧，我认为不超过12ms都是比较优秀的~

9ms只能说是没有落在cache中，15k的硬盘再快也要6ms~