[skgmhash] oracle,执行dbms_workload_repository.create_snapshot出现hang，等待事件enq: WF – contention...

背景介绍：

有一套在HP上跑的10.2.0.5的RAC系统，我们手动执行AWR快照出现Hang住的情况。

问题分析：

对于Hang住的情况，我们一般先查v$session，看看这个会话的等待事件是什么。但是这里情况稍微有些不一样，当我们执行DBMS_WORKLOAD_REPOSITORY去创建快照的时候，该进程会去调用m000进程去完成这个操作，当m000进程完成作业之后，才会返回给我们的session。今天这个案例的情况就在于我们的session所处的等待事件是enq:wf-contention。而我们的m000进程所处的等待是gc cr request。

SQL> select sid,serial#,sql_id,blocking_instance,blocking_session from gv$session where sid=2347;

SID SERIAL# SQL_ID EVENT BLOCKING_INSTANCE BLOCKING_SESSION

---------- ---------- ----- ----------------- -----------------

2347 1048 bc7gjv3ppdtbz enq: WF - contention 2                  3369

SQL> select sid,serial#,paddr,prev_sql_id,sql_id,event,blocking_session from v$session where sid=3369;

SID SERIAL# EVENT BLOCKING_ SESSION

--- ------- --------- -----------------

3369 17015 gc cr request

因为m000无法正常执行结束，所以这个进程自己产生了trace。我们来看下m000的trace文件。

Unix process pid: 21851, image: oracle@RX9800_2 (m000)

*** 2014-02-26 09:35:29.046

*** ACTION NAME:(Auto-Flush Slave Action) 2014-02-26 09:35:29.045

*** MODULE NAME:(MMON_SLAVE) 2014-02-26 09:35:29.045

*** SERVICE NAME:(SYS$BACKGROUND) 2014-02-26 09:35:29.045

*** SESSION ID:(3369.17015) 2014-02-26 09:35:29.045

kjbhistory[0xa2b0.30000,(pkey 8990.0)(where 1)]

*** 2014-02-26 09:35:29.046

GLOBAL CACHE ELEMENT DUMP (address: c0000001adfca2b8):

id1: 0xa2b0 id2: 0x30000 pkey: OBJ#8990 block: (3/41648)

lock: NC rls: 0x0000 acq: 0x0003 latch: 12

flags: 0x41 fair: 0 recovery: 0 fpin: 'kdswh02: kdsgrp'

bscn: 0x0.0 bctx: 0000000000000000 write: 0 scan: 0x0 xflg: 0 xid: 0x0.0.0

lcp: c000000c2e6b1598 lnk: [c000000c2e6b15b8,c000000c2e6b15b8] lch: [c000000a74f77d48,c000000a74f77d48]

seq: 27830 hist: 7 352 329 144:1 502 465 7 352 329 144:1

LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:

flg: 0x00080000 state: READING mode: EXCL

pin: 'kdswh02: kdsgrp'

addr: c000000a74f77c38 obj: 8990 cls: DATA bscn: 0x0.0

GCS CLIENT c0000001adfca328,4639 sq[0000000000000000,0000000000000000] resp[0000000000000000,0xa2b0.30000] pkey 8990.0

grant 0 cvt 0 mdrole 0x0 st 0x20 GRANTQ rl LOCAL

master 0 owner 1 sid 1 remote[0000000000000000,0] hist 0xcd0672cd

history 0xd.0xb.0x27.0x1.0xd.0x3. cflag 0x0 sender 0 flags 0x0 replay# 0

disk: 0x0000.00000000 write request: 0x0000.00000000

pi scn: 0x0000.00000000

msgseq 0x0 updseq 0x0 reqids[4638,0,0] infop 0x0

pkey 8990.0

hv 69 [stat 0x0, 0->0, wm 32767, RMno 0, reminc 38, dom 0]

kjga st 0x4, step 0.0.0, cinc 40, rmno 11, flags 0x0

lb 0, hb 0, myb 37974, drmb 37974, apifrz 0

在这个trace文件里面，我们可以看到我们的gc请求在对象obj为8990上。物理位置位于3号文件的第41648个block上面。那么究竟为什么不能把这个块获取过来呢？我们进一步做了hanganalyze和systemdump。这里因为是gc问题需要做全局的hanganalyze和systemdump。最终会把信息生成到diag文件上面。我们先看下节点1上的diag文件，有以下内容：