ora 11.0.2.0 ORA-32701: Possible hangs up to hang ID=2 detected
2012-02-29 08:52阅读：
数据库跑了半年突然 alert里面突然出现了这种错误
ORA-32701: Possible hangs up to hang ID=2 detected
metalink
查了一下据说是11.0.2.0的bug，但是他的描述说这种错误时在实例刚刚开启时才会产生的。
和我这里这种情况不符啊~
adrci中show incident 看见4 5个这种事件，
show problem 木有
在alet中给的trc文件中看到如下一些信息
Incident 28081 created, dump file:
/u01/app/oracle/diag/rdbms/xxxcfg/xxxcfg1/incident/incdir_28081/xxxcfg1_dia0_10121_i28081.trc
ORA-32701: Possible hangs up to hang
ID=2 detected
HM: Requesting kill of session sid:2
with serial # 64761 (ospid:2785) on instance 1 (local
instance)
due to a GLOBAL, HIGH confidence hang with ID=2
Hang Resolution Reason: Although the number of affected
sessions did not
justify automatic hang resolution initially, this
previously
ignored
hang was automatically resolved.
Dumping process info of pid[48.2785] (sid:2,
ser#:64761)
requested by master DIA0 process on instance 1.
os thread scheduling delay history: (sampling every 1.000000
secs)
0.000000 secs at [ 01:06:18 ]
NOTE: scheduling delay has not been sampled for 0.647862 secs
0.000000 secs from [ 01:06:14 - 01:06:19 ], 5 sec avg
#5s内延迟在0.6s
0.000000 secs from [ 01:05:19 - 01:06:19 ], 1 min avg
#1min内延迟0s
0.000000 secs from [ 01:01:20 - 01:06:19 ], 5 min avg
# 5min 演出0s
loadavg : 0.36 0.30 0.27
Memory (Avail / Total) = 33548.30M / 64326.85M
##负载很低
Swap (Avail / Total) = 16386.61M / 16386.61M
*** 2012-02-04 01:06:19.652
current sql: SELECT MAX(TOTAL_MB), MIN(TOTAL_MB), SUM(TOTAL_MB),
COUNT(*) FROM V$ASM_DISKGROUP
最后查资料发现时这么解释的
这是由于11.0.2.0 默认开启了HM（health monitor
11g新特性），在这段时间某个session被阻塞了，hm把他当做了一个hang进行处理，
HM: Requesting
kill of session sid:2 with serial # 64761
Hang Resolution Reason: Although the number of affected
sessions did not
justify automatic hang resolution initially, this previously
ignored
hang was automatically resolved.
进一步查看
应为是hang住了感觉肯定是有session被这个hang挡住了，HM才会把这个行给kill掉，所以按他的提示在
/u01/app/oracle/diag/rdbms/xxxcfg/xxxcfg1/incident/incdir_28081/xxxcfg1_dia0_10121_i28081.trc
中搜寻关键字“blocking” 发现
。。。。。。。。。。。。。。
。。。。。。
Oracle session
identified by:
{
instance: 2 (yspcfg.yspcfg2)
os id: 7785
process id:
76, oracle@zywsev26 (M000)
session id: 141
session
serial #: 21785
}
is waiting for 'enq: FU -
contention' with wait info:
{
p1: 'name|mode'=
0x46550006
p2: '0'=0x0
p3: '0'=0x0
time in wait: 2 min
2 sec
timeout after: 12
min 57 sec
wait id: 1
blocking: 0 sessions
wait history:
* time
between current wait and wait #1: 0.001126 sec
1.
event: 'class slave wait'
time waited: 0.000068 sec
wait id: 0
p1: 'slave id'=0x0
}
and is
blocked
by
=> Oracle session identified by:
{
instance: 1 (yspcfg.yspcfg1)
os id: 29644
process id:
67, oracle@zywsev25 (M000)
session id:
633
session serial #: 11621
}
which is
not in a
wait:
{
last wait: 11 min 31 sec
ago
blocking: 1 session
wait history:
1. event: 'ASM file
metadata operation'
time waited: 0.021265 sec
wait id: 697
p1: 'msgop'=0x186c
p2:
'locn'=0x9
* time
between wait #1 and #2: 0.000491 sec
2.
event: 'row cache lock'
time waited: 0.000174 sec
wait id: 696
p1: 'cache id'=0x10
p2:
'mode'=0x0
p3:
'request'=0x3
* time
between wait #2 and #3: 0.000229 sec
3.
event: 'row cache lock'
time waited: 0.000245 sec
wait id: 695
p1: 'cache id'=0x10
p2:
'mode'=0x0
p3:
'request'=0x3
}
查了一下资料：
not in wait 不是idle session的意思，只是这个session挂起了，在终端ps -aus
看的话他的进程状态时S，表示当前该进程在休眠。
'not in wait' don't means
the session was idled ,we
could see the process status
was 'S' which means sleeping
at that time , sleeping
session still will be called
by CPU .
可以看到
【session id: 633
session serial #: 11621】的event:
'ASM file metadata operation'正在
blocking session
【session id: 141 session
serial #: 21785】
其current sql 为 SELECT
MAX(TOTAL_MB), MIN(TOTAL_MB), SUM(TOTAL_MB), COUNT(*) FROM
V$ASM_DISKGROUP
由于v$asm_diskgroup为一个视图，所以不存在统计信息不准影响sql性能什么的情况，另外在这个库只有3磁盘组，应该很快才对~。于是尝试执行了一下，看看能在这sql能跑多久
so~
sql>set timeing on
sql>SELECT MAX(TOTAL_MB),
MIN(TOTAL_MB), SUM(TOTAL_MB), COUNT(*) FROM
V$ASM_DISKGROUP
...........
.........
.......
....
N+分钟后~
太慢啦~~~~~~~
忍不了了。。kill 掉了这个session 怕在阻塞到别人~~~
于是在晚上夜深人静之时 trace了一下这个sql
虽然不一定能看懂trac 但是还是试一试玩意能发现啥呢
SQL>select spid from v$process
where addr=(select paddr from v$session
where sid=(select distinct sid from
v$mystat));
先查下spid 到时候好找trc
SQL>alter session set
timed_statistics =
true;
SQL>alter
session set
statistics_level=all;
SQL>alter session set
max_dump_file_size =
unlimited;
SQL>alter
session set events '10046 trace
name context forever, level
12';
SQL>SELECT MAX(TOTAL_MB),
MIN(TOTAL_MB), SUM(TOTAL_MB), COUNT(*) FROM V$ASM_DISKGROUP
。。。。。。。。。。
。。。。。。。
。。。
还得kill~、、、、
正常trc完还得
SQL>alter session set events
'10046 trace name context
off';关闭trc
完事后
先tkprof格式化一下，检查trc文件
只看到一些library lock 和pin
Elapsed times include waiting on following events:
Event waited on
Times
Max. Wait
Total Waited
----------------------------------------
Waited
----------
------------
SQL*Net message to client
2
0.00
0.00
SQL*Net message from client
1
19.52
19.52
library cache lock
2
0.00
0.00
library cache pin
2
0.00
0.00
ASM file metadata operation
1
0.01
0.01
其他感觉没啥不ok的。。。 感觉其实在解析时就卡主了。。又看见它了
ASM file metadata
operation
在网上查了下 说 ASM 实例中
Discovery String=''
没有设置，在$GI_HOME/log/gpnp/<hostname>/profiles/peer/profiles.xml也没有设置的话
asm就扫整个系统去找diskgroup组，如果盘很大就很慢~
于是查了一下
，发现所有实例都没设置啊~~~。。。。难道这是原因。。？在其他节点试了一下sql......~! 
只有一个节点会很慢~ 其他节点都正常啊~擦~~~~~
木办法
'hung analyze' & 'system
state dump' & 'error stack'
能用的都试试吧~
+ASM>select spid from v$process
where addr=(select paddr from v$session
where sid=(select distinct sid from
v$mystat));
========>
19034
+ASM1>SELECT MAX(TOTAL_MB), MIN(TOTAL_MB),
SUM(TOTAL_MB), COUNT(*) FROM V$ASM_DISKGROUP
....................................
..............hang。。。。
++++++++++++++++收集error
stack++++++++++++++++++
+ASM1> connect / as
sysdba
+ASM1>
oradebug setospid 19034
==>我的spid
+ASM1>
oradebug unlimit
+ASM1> oradebug dump errorstack
3
+ASM1> oradebug
tracefile_name
/u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_19034.trc
+++++++++++++++hung
analyze++++++++++++++++++++
+ASM>select spid from v$process
where addr=(select paddr from v$session
where sid=(select distinct sid from
v$mystat));
========>
9461
SQL>oradebug setmypid
SQL>oradebug unlimit
SQL>oradebug -g all hanganalyze
3
~~~~~~~~~Wait for
30 seconds~~~~~~~~~~
SQL>oradebug -g all hanganalyze
3
SQL>exit
===>/u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_diag_9461.trc
+++++++++++++++system
state dump++++++++++++++++
SQL>oradebug setmypid
SQL>oradebug unlimit
SQL>oradebug -g
all dump systemstate
266
~~~~~~~~~~Wait
for 30
seconds~~~~~~~~~
SQL>oradebug -g all dump
systemstate 266
SQL>oradebug
tracefile_name
/u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_ora_24150.trc
SQL>exit
因为是hang了 so决定先看hang。。。
|||||||||||||||||||||||||||||||||||||||||||
开头就提示：
HANG ANALYSIS:
instances (db_name.oracle_sid):
+asm.+asm1, +asm.+asm2
oradebug_node_dump_level:
3
analysis initiated by
oradebug
os thread scheduling delay history:
(sampling every 1.000000 secs)
0.000000 secs at [ 19:51:18
]
NOTE: scheduling delay
has not been sampled for 0.874465 secs 0.000000 secs
from [ 19:51:14 - 19:51:19 ], 5 sec avg
0.000000 secs from [ 19:50:20
- 19:51:19 ], 1 min avg
0.000000 secs from [ 19:46:20
- 19:51:19 ], 5 min avg
===============================================================================
Chains most likely to have
caused the hang:
[a] Chain 1 Signature:
'GPnP Get Item'<='rdbms ipc reply'<='enq: DD -
contention'
Chain 1
Signature Hash: 0xec6b634f
[b] Chain 2 Signature:
'GPnP Get Item'<='rdbms ipc reply'<='enq: DD -
contention'
Chain 2
Signature Hash: 0xec6b634f
[c] Chain 3 Signature:
'GPnP Get Item'<='rdbms ipc reply'<='enq: DD -
contention'
Chain 3
Signature Hash: 0xec6b634f
搜索blocked（blocking，err，ORA 。。。。）
Chain 1:
-------------------------------------------------------------------------------
Oracle session identified
by:
{
instance: 1
(+asm.+asm1)
os id:
19034
process id: 44, oracle@zywsev25 (TNS
V1-V3)
session id:
163
session serial #: 545
}
is
waiting for 'enq: DD - contention' with wait
info:
{
p1: 'name|mode'=0x44440006
p2:
'disk group'=0x0
p3:
'type'=0x1
time in wait: 5 min 13
sec
timeout after: never
wait id: 25
blocking: 0 sessions
current sql: SELECT
MAX(TOTAL_MB), MIN(TOTAL_MB), SUM(TOTAL_MB), COUNT(*) FROM
V$ASM_DISKGROUP short stack:
ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1900<-sspuser()+112<-__sighandler()<-semtimedop()+10<-skgpwwait()+160<-ksliwat()+1865<-kslwaitctx()+163<-ksqcmi()+2956<-ksqgtlctx()+3810<-ksqgelctx()+561<-kfgUseDmt()+649<-kfgTableCb()+1533<-kfgGrpTableCbInternal()+3984<-kfgGrpTableCb()+56<-qerfxFetch()+2060<-qergsFetch()+821<-opifch2()+2882<-kpoal8()+2946<-opiodr()+910<-ttcpip()+2289<-opitsk()+1670<-opiino()+966<-opiodr()+910<-opidrv()+570<-sou2o()+103<-opimai_real()+133<-ssthrdmain()+252<-main()+201<-__libc_start_main()+244
wait history:
* time between current wait and wait #1: 0.000097
sec
1. event: 'SQL*Net message
to client'
time waited: 0.000003
sec
wait id: 24
p1: 'driver
id'=0x62657100
p2: '#bytes'=0x1
* time between wait #1 and #2: 0.000351
sec
2. event: 'SQL*Net message
from client'
time waited: 1 min 50
sec
wait id: 23
p1: 'driver
id'=0x62657100
p2: '#bytes'=0x1
* time between wait #2 and #3: 0.000004
sec
3. event: 'SQL*Net message
to client'
time waited: 0.000001
sec
wait id: 22
p1: 'driver
id'=0x62657100
p2: '#bytes'=0x1
}
and is blocked
by
=> Oracle session identified
by:
{
instance: 1
(+asm.+asm1)
os id:
2789
process id: 27, oracle@zywsev25 (TNS
V1-V3)
session id: 25
session serial #: 15757
}
which is waiting for 'rdbms
ipc reply' with wait info:
{
p1:
'from_process'=0x12
p2:
'timeout'=0x7fd76d99
time in wait: 0.053898
sec
timeout after: 1.946102
sec
wait id:
1329468
blocking: 11 sessions
11个session？被它blocked？
current sql: select name_kfgrp, number_kfgrp,
incarn_kfgrp, compat_kfgrp, dbcompat_kfgrp, state_kfgrp,
flags32_kfgrp, type_kfgrp, refcnt_kfgrp, sector_kfgrp,
blksize_kfgrp, ausize_kfgrp , totmb_kfgrp, freemb_kfgrp,
coldmb_kfgrp, hotmb_kfgrp, minspc_kfgrp, usable_kfgrp,
offline_kfgrp, lflags_kfgrp from
x$kfgrp
short stack:
ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1900<-sspuser()+112<-__sighandler()<-semtimedop()+10<-skgpwwait()+160<-ksliwat()+1865<-kslwaitctx()+163<-kslwait()+141<-ksarcr()+227<-ksbwcoex()+35<-kfgbSendWithPin()+442<-kfgbSendShallow()+137<-kfgDiscoverShallow()+268<-kfgGlobalOpen()+264<-kfgDiscoverDeep()+288<-kfgDiscoverGroup()+388<-kfgTableCb()+1555<-kfgGrpTableCbInternal()+3984<-kfgGrpTableCb()+56<-qerfxFetch()+2060<-opifch2()+2882<-kpoal8()+2946<-opiodr()+910<-ttcpip()+2289<-opitsk()+1670<-opiino()+966<-opiodr()+910<-
wait history:
* time between current wait and wait #1: 0.000035
sec
1. event: 'rdbms ipc
reply'
time waited: 2.001604
sec
wait id: 1329467
p1:
'from_process'=0x12
p2: 'timeout'=0x7fd76d9b
* time between wait #1 and #2: 0.000055
sec
2. event: 'rdbms ipc
reply'
time waited: 2.000632
sec
wait id: 1329466
p1:
'from_process'=0x12
p2: 'timeout'=0x7fd76d9d
* time between wait #2 and #3: 0.000038
sec
3. event: 'rdbms ipc
reply'
time waited: 2.000581
sec
wait id: 1329465
p1:
'from_process'=0x12
p2: 'timeout'=0x7fd76d9f
}
and is blocked
by
=> Oracle session identified
by:
{
instance: 1
(+asm.+asm1)
os id:
9487
process id: 18,
oracle@zywsev25 (RBAL)
session id:
145
session serial #: 1
}
which is
waiting for 'GPnP Get Item' with wait
info:
{
time in wait: 44338 min 47 sec
我靠~~~~ 这啥玩意！
timeout after: never
wait id: 4921084
blocking: 12
sessions
current sql: <none>
short stack:
ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1900<-sspuser()+112<-__sighandler()<-__poll()+47<-sgipcwWaitHelper()+5271<-sgipcwWait()+475<-gipcWaitOsd()+281<-gipcInternalWait()+14612<-gipcWaitF()+3234<-gipcInternalRecvSync()+8743<-gipcRecvSyncF()+3343<-clsgpnpm_gipcGets()+297<-clsgpnpm_receiveMsg()+408<-clsgpnpm_exchange()+1059<-clsgpnp_profileCallUrlInt()+3568<-clsgpnp_getProfileEx()+325<-clsgpnp_dbmsGetItem()+263<-kggpnpAttrGet()+1272<-kfdParseProfileString()+885<-kfdDiscoverShallow()+1995<-kfgbDriver()+1745<-ksbabs()+
wait history:
* time between current wait and wait #1: 0.000006
sec
1. event: 'GPnP
Initialization'
time waited: 0.019363
sec
wait id: 4921083
* time between wait #1 and #2: 0.000183
sec
2. event: 'CSS
initialization'
time waited: 0.000019
sec
wait id: 4921082
* time between wait #2 and #3: 0.000068
sec
3. event: 'rdbms ipc
message'
time waited: 1.192901
sec
wait id: 4921081
p1:
'timeout'=0x12c
}
Chain 1 Signature: 'GPnP Get Item'<='rdbms
ipc reply'<='enq: DD - contention'
Chain 1 Signature Hash:
0xec6b634f
又向下看了看，，发现
Chain 2 Signature: 'GPnP Get Item'<='rdbms
ipc reply'<='enq: DD - contention'
Chain 2 Signature Hash:
0xec6b634f
is
blocked by 'instance: 1, os id: 2789, session id:
25',
which is a member of 'Chain
1'.
Chain 3 Signature: 'GPnP Get Item'<='rdbms
ipc reply'<='enq: DD - contention'
Chain 3 Signature Hash:
0xec6b634f
is blocked by 'instance: 1, os id: 2789, session id:
25',
which is a member of 'Chain
1'.
Chain 4 Signature: 'GPnP Get Item'<='rdbms
ipc reply'<='enq: DD - contention'
Chain 4 Signature Hash:
0xec6b634f
is blocked by 'instance: 1, os id: 2789, session id:
25',
which is a member of 'Chain
1'.
。。。。。。。。。。。。。。。
。。。。。。。。。。
。。。。
。。
Chain 11 Signature: 'GPnP Get Item'<='rdbms
ipc reply'<='enq: DD - contention'
Chain 11 Signature Hash:
0xec6b634f
is blocked by 'instance: 1, os id: 2789, session id:
25',
which is a member of 'Chain
1'.
全被GPnP Get
Item阻挡了，（阻挡顺序'GPnP Get Item'<='rdbms ipc
reply'<='enq: DD - contention'）
这Gpnp干嘛的~~ 擦了。。
在官档上找到的
Grid Plug and Play (GPnP) eliminates per-node configuration
data and the need for explicit add and delete nodes
steps. This allows a system administrator to take a template system
image and run it on a new node with no further configuration. This
removes many manual operations, reduces the opportunity for errors,
and encourages configurations that can be changed easily. Removal
of the per-node configuration makes the nodes easier to replace,
because they do not need to contain individually-managed
state.
主要是说gpnp是11g的一新东西，相当于一个模板或配置文件之类的，用于简化管理员在添加删除节点时的手工操作的~
整闹心之时突然发现： process id: 18,
oracle@zywsev25 (RBAL)我实在asm实例下作的select。。
估计丫整rebalance呢
~！
弄metalink查了一下发现~这尼玛就是个bug！
This is caused by non-published bug:12398300 which is a
duplicate of bug:12356910
解决方案据上面说只有重启该实例或升级到11.2.0.3!
晚些时候在重启吧~~~~~~~
...../
.../
./
/
srvctl stop instance -d xxxbak -i xxxbak2 -o abort
tail -f alertxxxxev19.log
NOTE: [emcrsp.bin@zywsev19 (TNS V1-V3) 28439] opening OCR
file
Wed Mar 07 18:05:18 2012
NOTE: ASM client yspbak2:yspbak disconnected unexpectedly.
NOTE: check client alert log.
NOTE: Trace records dumped in trace file
/u01/app/grid/diag/asm/+asm/+ASM2/trace/+ASM2_ora_11080.trc
Wed Mar 07 18:05:57 2012
NOTE: [emcrsp.bin@zywsev19 (TNS V1-V3) 28868] opening OCR
file
Wed Mar 07 18:08:21 2012
NOTE: [emcrsp.bin@zywsev19 (TNS V1-V3) 29789] opening OCR
file
Wed Mar 07 18:08:21 2012
NOTE: [emcrsp.bin@zywsev19 (TNS V1-V3) 29793] opening OCR
file
Wed Mar 07 18:08:21 2012
NOTE: [emcrsp.bin@zywsev19 (TNS V1-V3) 29797] opening OCR
file
Wed Mar 07 18:08:21 2012
NOTE: [emcrsp.bin@zywsev19 (TNS V1-V3) 29801] opening OCR
file
Wed Mar 07 18:08:22 2012
NOTE: [emcrsp.bin@zywsev19 (TNS V1-V3) 29805] opening OCR
file
Wed Mar 07 18:09:39 2012
SQL> ALTER DISKGROUP DATAG1 DISMOUNT
Wed Mar 07 18:09:39 2012
....
....
..
有hang住了。。。。。。。
擦了。。服了~~~
再
analyze 一下
SQL>oradebug setmypid
SQL>oradebug unlimit
SQL>oradebug -g all hanganalyze
3
~~~~~~~~~Wait for
30 seconds~~~~~~~~~~
SQL>oradebug -g all hanganalyze
3
SQL>exit
vi
/u01/app/grid/diag/asm/+asm/+ASM2/trace/+ASM2_diag_10330.trc
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Chains most likely to have caused the hang:
[a] Chain 1 Signature: 'GPnP Get Item'<='rdbms ipc
reply'<='enq: DD - contention'
Chain 1 Signature Hash: 0xec6b634f
[b] Chain 2 Signature: 'GPnP Get Item'<='rdbms ipc
reply'<='enq: DD - contention'
Chain 2 Signature Hash: 0xec6b634f
[c] Chain 3 Signature: 'GPnP Get Item'<='rdbms ipc
reply'<='enq: DD - contention'
Chain 3 Signature Hash: 0xec6b634f
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
。。。。。。。。。。。。。。。。。。。。。。。。。。
。。。。。。。。。。。。。。。。。。。。
。。。。。。
and is blocked by
=> Oracle session identified by:
{
instance: 2 (+asm.+asm2)
os id: 10356
process id: 18, oracle@zywsev19
(RBAL)
session id: 145
session
serial #: 1
}
which is waiting for 'GPnP
Get Item' with wait info:
{
time in wait: 6879 min 34 sec
timeout after:
never
wait id: 8041593
blocking: 4 sessions
current sql:
<none>
short stack:
ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1900<-sspuser()+112<-__sighandler()<-__poll()+47<-sgipcwWaitHelper()+5271<-sgipcwWait()+475<-gipcWaitOsd()+281<-gipcInternalWait()+14612<-gipcWaitF()+3234<-gipcInternalRecvSync()+8743<-gipcRecvSyncF()+3343<-clsgpnpm_gipcGets()+297<-clsgpnpm_receiveMsg()+408<-clsgpnpm_exchange()+1059<-clsgpnp_profileCallUrlInt()+3568<-clsgpnp_getProfileEx()+325<-clsgpnp_dbmsGetItem()+263<-kggpnpAttrGet()+1272<-kfdParseProfileString()+885<-kfdDiscoverShallow()+1995<-kfgbDriver()+1745<-ksbabs()+
wait history:
* time
between current wait and wait #1: 0.000006 sec
1.
event: 'GPnP
Initialization'
time waited: 0.019780 sec
wait id: 8041592
============================
又是它~~~~~~~~~~~~~~~~~~~~
metalink上说重启，或打补丁就能解决啊~~~。。赤裸裸的坑爹啊~~~~~
在上metalink 上查了一下 RBAL gpnp 又找到一bug：
Bug 13576394:
擦了
更闹心的是 这个bug后面写着
--->WORKAROUND: None
除了打补丁没别的办法~~了
，，，，，，，，，，，，，，，，，，，，
，，，，，，，，，，，，，，
那也不能僵着啊 明早以来那些开发的不等墨迹死我~~~~~~~~~
。。。。。。。。。。。我决定了 重启这个节点的服务器
[root#]init 6 --保佑俺啊
。。
。。
。。
重启以后我靠。。。。。。。。一切正常~~~~~~ O(∩_∩)O哈哈~
在执行
SELECT MAX(TOTAL_MB), MIN(TOTAL_MB),
SUM(TOTAL_MB), COUNT(*) FROM V$ASM_DISKGROUP；
这回瞬间就有结果了~~~
看来这个问题解决了~~
不过以后没准啥时候可能还会出这事、、、
得尽早打补丁啊~~~~~~
这事就这么着吧~~~~
过几天申请打补丁吧~~~~
补丁~~~~~待续~~
