数据库rac hang，hpux 11.31 ia

whiterain

环境： hpux 11.31  IA
oracle　rac： asm + database  11.2.0.1 无任何psu
现象数据库hang， 做analyze无结果。
附件是出问题的时候，alert ,trace 文件 awr，和ash一些数据，还有一个今天早晨同时刻做的awr报表。
麻烦帮忙看看，谢谢了。

whiterain

发一个今天早晨的awr，是没出问题的时候的。

iloracle

你用oradebug 做的hanganalyze的么

iloracle

看awr 等待事件都是data dictionary  contention  而且hard parse很多 可以查一下这部分

Maclean Liu(刘相兵

        Begin        End               
Buffer Cache:         199,680M         199,680M        Std Block Size:         8K
Shared Pool Size:         204,288M         204,288M        Log Buffer:         222,536K


好大的内存

memory_max_target        536870912000          
memory_target        0

sga_max_size        429496729600          
sga_target        429496729600


Pool        Name        Begin MB        End MB        % Diff
java        free memory        1,024.00        1,024.00        0.00
large        CTWR dba buffer        26.73        26.73        0.00
large        free memory        2,483.57        2,483.57        0.00
large        krcc extent chunk        41.51        41.51        0.00
shared        CCUR        12,325.10        12,642.83        2.58
shared        KGH: NO ACCESS        4,607.37        4,646.77        0.86
shared        KGLHD        4,062.13        4,556.65        12.17
shared        PCUR        16,393.80        17,906.55        9.23
shared        SQLA        125,867.29        125,860.40        -0.01
shared        free memory        27,286.41        25,337.64        -7.14
shared        gcs resources        3,585.23        3,585.23        0.00
shared        gcs shadows        2,589.33        2,589.33        0.00
shared        kglsim object batch        2,638.21        2,638.21        0.00
        buffer_cache        199,680.00        199,168.00        -0.26
        fixed_sga        2.10        2.10        0.00
        log_buffer        217.32        217.32        0.00


shared        SQLA        125,867.29        125,860.40        -0.01

SQLA用了 125g，真的需要这么多执行计划吗？

Maclean Liu(刘相兵

硬解析 Hard parses:         349.7         7.2         
shared pool        204,288.00        204,800.00        204,288.00        222,208.00        2        GRO/IMM


我认为问题主要有2点： 大量的硬解析，  并且sga_target非常大， 这导致shared pool也非常大，要管理一个极大的shared pool成本较高， 同时在11.2.0.1上BUG也会很多



我的建议：

1、 搞清楚这么多的硬解析是必要的吗？
2、 这些SQL真的不能共享吗？
3、 如果确实无法共享，那么其实没必要搞一个这么大的shared pool，不如搞一个固定大小 小一点的shared pool，每天在业务低峰时期 flush shared pool一把
4、 不要用memory_max_target   ，这会导致一些AMM的潜在特性打开
5、 考虑升级到11.2.0.4

whiterain

从awr上来看，个人认为存在大量的硬解析。
share pool 认为不够用的了。需要从buffer cache缩小内存，给share pool增加内存。
想问一下刘大，在awr报告里面为啥sql语句的绑定用的  :1  :2 表示吧。
使用了 :SYS_B_1  --- 是不是表示用的字面变量？

whiterain

刘大，另外，我在2楼回复的awr里面，version count也非常高。

Maclean Liu(刘相兵

cursor_sharing        EXACT


ersion Count        Executions         SQL Id        SQL Module        SQL Text
2,418        82        bb2z7pb0x39gu         JDBC Thin Client        select :"SYS_B_00"*(:"SYS_B_01...
1,047        15        55wta3s2hcmwq         JDBC Thin Client        select :"SYS_B_00"*fnc_zt737(:...
948        8        312jnwszqxncj         JDBC Thin Client        select :"SYS_B_00"*fnc_zt645(:...
913        186        896ykj486xfqr         JDBC Thin Client        select /*+rule*/ standbyflag2 ...
713        19        14u0d28uv1ama         JDBC Thin Client        select :"SYS_B_00"*fnc_zt3_5(:...
631        25        gvtwtfsbf3q61         JDBC Thin Client        select :"SYS_B_00"*:"SYS_B_01"...
625        7        7cgvw4apbrj03         JDBC Thin Client        select :"SYS_B_00"*(case when ...
451        2        5mbnsp1rb3t29         JDBC Thin Client        select :"SYS_B_00"* fnc_zt650(...
352                 3ur34rc3pk43m                 select :"SYS_B_00"*(greatest(:...
290                 48cwzzvwu5wxw                 select Banksuccflag, serialno ...

但你的SQL里有：SYS_B_00，这说明 有人在session级别使用了 cursor_sharing=FORCE/similar

你需要确认一下是否是similar

另需要搞清楚 是 游标无法共享造成的硬解析 ， 还是 语句没绑定变量造成的硬解析，就SQL ordered by Version Count看 version count还不算最多


给出下面的输出：

select FORCE_MATCHING_SIGNATURE, count(1)
  from v$sql
where FORCE_MATCHING_SIGNATURE > 0
   and FORCE_MATCHING_SIGNATURE != EXACT_MATCHING_SIGNATURE
group by FORCE_MATCHING_SIGNATURE
having count(1) > 10
order by 2;

harryzhang

Dump file /app/oracle/diag/rdbms/prodb/PRODB1/incident/incdir_946536/PRODB1_lmhb_4360_i946536.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
ORACLE_HOME = /app/oracle/product/11.2.0/db_1
System name:    HP-UX
Node name:      HPPRDDB1
Release:        B.11.31
Version:        U
Machine:        ia64
Instance name: PRODB1
Redo thread mounted by this instance: 1
Oracle process number: 20
Unix process pid: 4360, image: oracle@HPPRDDB1 (LMHB)


*** 2013-09-23 09:53:36.701
*** SESSION ID:(721.1) 2013-09-23 09:53:36.701
*** CLIENT ID:() 2013-09-23 09:53:36.701
*** SERVICE NAME:(SYS$BACKGROUND) 2013-09-23 09:53:36.701
*** MODULE NAME:() 2013-09-23 09:53:36.701
*** ACTION NAME:() 2013-09-23 09:53:36.701

Dump continued from file: /app/oracle/diag/rdbms/prodb/PRODB1/trace/PRODB1_lmhb_4360.trc
ORA-29771: process USER (OSID 27774) blocks LCK0 (OSID 4470) for more than 70 seconds

========= Dump for incident 946536 (ORA 29771) ========
----- Beginning of Customized Incident Dump(s) -----
Process LCK0 (ospid: 4470) is waiting for event 'latch: call allocation'.
Process USER (ospid: 27774) is the blocker of the wait chain.
===[ Wait Chain ]===
LCK0 (ospid: 4470) waits for event 'latch: call allocation'.
USER (ospid: 27774) waits for event 'SGA: allocation forcing component growth'.
MMAN (ospid: 4362) is not in wait.
===[ Latch Chain ]===
LCK0 (ospid: 4470) waits for latch 'call allocation'.
USER (ospid: 27774) is not waiting for any latch.

whiterain

谢谢了。。

aaron8219

Execute to Parse %:        -34.71
存在大量解析

xifenfei

cursor_sharing        EXACT
sql语句估计问题不少

Start        Ela (s)        Component        Oper Typ/Mod        Init Size (M)        Delta        Target Delta        Final (M)        Sta
09/23 10:28:27        3        bufcache        SHR/IMM        199,680        -512                 199,168        COM
09/23 10:28:27        3        shared        GRO/IMM        204,288        512                 204,800        COM
09/23 09:20:25        1968        bufcache        SHR/DEF        199,680        0        -512        199,680        CAN
09/23 09:20:25        1968        shared        GRO/DEF        204,288        0        512        204,288        CAN

多次sga变动，建议设置固定值

iloracle

学习了！！！

lnwxzyp

为什么会允许在生产系统 上初始未打psu的版本呢？

whiterain

刘大，更新了。把sql的结果发出来了。

Maclean Liu(刘相兵

4499        5072530034158080000.00         31585
4500        313484016280687000.00         33435
4501        13238805257899200000.00         43711
4502        7822272079344480000.00         49153
4503        15719338505306500000.00         50457
4504        1024942222910620000.00         52438
4505        17056155637598300000.00         52815
4506        12143570950285800000.00         53716
4507        17267795289301100000.00         54203
4508        3140772749850710000.00         65319
4509        15770052094406700000.00         71383
4510        10170154879216400000.00         72483
4511        4366732071406870000.00         96351


可以看到 一个FORCE_MATCHING_SIGNATURE
可以对应9万多个 SQL版本，这说明大量SQL确实没绑定变量

whiterain

谢了，刘大，准备和开发讨论更更改的事情了。