[20260809]Row Cache Mutex 定位具体对象的方法.txt
--//利用sql语句select sid from v$mystat where rownum=1;密集执行时会出现row cache mutex等待事件，测试是否能定位具体对象。
--//主要原因执行如下查询，没有返回记录。
SYS@book> select * from v$rowcache_parent where UTL_RAW.cast_to_varchar2(key) like '%X$KSUMYSTA%';
no rows selected
SYS@book> select * from v$rowcache_parent where UTL_RAW.cast_to_varchar2(key) like '%X$KSUSGIF%';
no rows selected
--//似乎X表在数据字典里面没有记录.在11g做了类似查询也是没有记录。
1.环境：
SYS@book> @ ver2
==============================
PORT_STRING : x86_64/Linux 2.4.xx
VERSION : 21.0.0.0.0
BANNER : Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
BANNER_FULL : Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
BANNER_LEGACY : Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
CON_ID : 0
PL/SQL procedure successfully completed.
2.测试脚本：
$ cat zz6.txt
set verify off
variable v_method varchar2(30);
exec :v_method := '&&2';
declare
v_sid number;
v_d date;
v varchar2(30);
begin
for i in 1 .. &&1 loop
select /*+ &3 */ sid into v_sid from v$mystat where rownum=1;
end loop;
end ;
/
quit
--//注：加入&3，这样可以导致每个会话执行的sql语句不同，我开始以为可以避免cursor: pin S等待事件，忘记了每次执行都会递归执
--//行如下SQL语句:
--//SQL ID: 87gaftwrm2h68 Plan Hash: 1072382624
--//select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname from obj$ o where o.obj#=:1
3.测试：
$ zzdate;seq 50 | xargs -IQ -P 50 sqlplus -s -l '/ as sysdba' @zz6.txt 8e4 test1 Q > /dev/null ; zzdate
trunc(sysdate)+16/24+07/1440+03/86400 -1786262823.274741932
trunc(sysdate)+16/24+09/1440+58/86400 1786262998.804645670
--//Sum = 175.529903738
SYS@book> @ ashtop event 1=1 trunc(sysdate)+16/24+07/1440+03/86400 trunc(sysdate)+16/24+09/1440+58/86400
Total Distinct Distinct Distinct
Seconds AAS %This EVENT FIRST_SEEN LAST_SEEN Execs Seen Tstamps Execs Seen1
--------- ------- ------- ------------------------------------------ ------------------- ------------------- ---------- -------- -----------
4501 25.7 53% | library cache: bucket mutex X 2026-08-09 16:07:07 2026-08-09 16:09:57 4 164 167
2262 12.9 27% | 2026-08-09 16:07:05 2026-08-09 16:09:57 247 140 385
737 4.2 9% | library cache: mutex X 2026-08-09 16:07:09 2026-08-09 16:09:55 1 131 131
647 3.7 8% | row cache mutex 2026-08-09 16:07:06 2026-08-09 16:09:50 1 40 40
314 1.8 4% | cursor: pin S 2026-08-09 16:07:07 2026-08-09 16:09:48 1 42 42
18 .1 0% | db file sequential read 2026-08-09 16:07:50 2026-08-09 16:09:50 7 18 18
5 .0 0% | latch: session allocation 2026-08-09 16:07:26 2026-08-09 16:08:57 1 3 3
3 .0 0% | log file parallel write 2026-08-09 16:08:54 2026-08-09 16:09:32 1 2 2
1 .0 0% | LGWR any worker group 2026-08-09 16:08:54 2026-08-09 16:08:54 1 1 1
1 .0 0% | control file parallel write 2026-08-09 16:08:32 2026-08-09 16:08:32 1 1 1
1 .0 0% | direct path sync 2026-08-09 16:09:32 2026-08-09 16:09:32 1 1 1
1 .0 0% | log file sync 2026-08-09 16:08:56 2026-08-09 16:08:56 1 1 1
12 rows selected.
--//前面已经分析出现library cache: bucket mutex X，library cache: mutex X的主要原因是在实例对象上存在争用，不再展开分析。
--//重点关注row cache mutex等待事件。
SYS@book> @ ev_namezpr 'row cache mutex'
==============================
EVENT# : 359
EVENT_ID : 306610566
NAME : row cache mutex
PARAMETER1 : cache id
PARAMETER2 : where requested
PARAMETER3 :
WAIT_CLASS_ID : 3875070507
WAIT_CLASS# : 4
WAIT_CLASS : Concurrency
DISPLAY_NAME : row cache mutex
CON_ID : 0
PL/SQL procedure successfully completed.
SYS@book> @ ashtop event,p1,p2raw "event='row cache mutex'" trunc(sysdate)+16/24+07/1440+03/86400 trunc(sysdate)+16/24+09/1440+58/86400
Total Distinct Distinct Distinct
Seconds AAS %This EVENT P1 P2RAW FIRST_SEEN LAST_SEEN Execs Seen Tstamps Execs Seen1
--------- ------- ------- ----------------- ---- ----------------- ------------------- ------------------- ---------- -------- -----------
396 2.3 61% | row cache mutex 8 0000000000000013 2026-08-09 16:07:07 2026-08-09 16:09:50 1 35 35
246 1.4 38% | row cache mutex 8 0000000000000011 2026-08-09 16:07:06 2026-08-09 16:09:50 1 36 36
2 .0 0% | row cache mutex 11 000000000000000A 2026-08-09 16:07:16 2026-08-09 16:07:17 1 2 2
2 .0 0% | row cache mutex 11 000000000000000E 2026-08-09 16:07:08 2026-08-09 16:07:13 1 2 2
1 .0 0% | row cache mutex 8 000000000000000E 2026-08-09 16:09:28 2026-08-09 16:09:28 1 1 1
--//P1= 8，11，如果查看
SYS@book> select distinct cache#,cache_name from v$rowcache_parent where cache# in (8,11);
CACHE# CACHE_NAME
---------- ----------------------------------------------------------------
8 dc_objects
11 dc_objects
--//奇怪CACHE#=8，11对应都是CACHE_NAME=dc_objects。
--//知道P1raw，p2raw信息无法定位具体对象的，因为mutex一般执行很快，很少成为主要等待事件，oracle留给诊断的信息很少。仅仅
--//出现了sleep，在 x$mutex_sleep_history中才有记录，想象是一块内存区域记录这些信息会反复使用，一般定时mmon进程会记录到
--//dba_hist_mutex_sleep表中，而记录在dba_hist_mutex_sleep表中有丢失许多关键信息，只有即使分析x$mutex_sleep_history才能
--//获得比较准确的信息。
SYS@book> @mutexprofz idn,maddr,idnhex,hash,loc "ts >= trunc(sysdate)+16/24+07/1440+03/86400 and mutex_type='Row Cache'"
-- MutexProf by Tanel Poder (http://www.tanelpoder.com)
-- Showing profile of top 50 sleeps...
-- column info : id idn hash hash_value=>hash_value ts=>sleep_timestamp
-- req=>requesting_session blk=>blocking_session val=>mutex_value maddr=>mutex_addr
SUM_SLEEPS GETS_DIFF MUTEX_TYPE IDN mutex_addr IDNHEX HASH GET_LOCATION SQL_ID OBJECT_NAME
---------- --------- ---------- ---------- -------------------- --------- ---------- --------------------------------- ------- -----------------------------
26 417989 Row Cache 0 0000000067304770 00000000 [10] kqreqd (name not found)
24 761382 Row Cache 134224505 00000000778EC500 08001A79 [19] kqrpre (name not found)
23 1070425 Row Cache 134224506 00000000778EC518 08001A7A [17] kqrCreateUsingSecondaryKey (name not found)
23 311544 Row Cache 0 0000000067311450 00000000 [10] kqreqd (name not found)
23 3167254 Row Cache 134224506 00000000778EC518 08001A7A [19] kqrpre (name not found)
17 274410 Row Cache 0 0000000067311450 00000000 [14] kqrScan (name not found)
16 235869 Row Cache 0 0000000067304770 00000000 [14] kqrScan (name not found)
14 1331002 Row Cache 134224505 00000000778EC500 08001A79 [17] kqrCreateUsingSecondaryKey (name not found)
12 9129225 Row Cache 0 0000000065CB7500 00000000 [10] kqreqd (name not found)
4 4527951 Row Cache 0 0000000065CB7A30 00000000 [10] kqreqd (name not found)
4 6440502 Row Cache 0 0000000065353E78 00000000 [10] kqreqd (name not found)
3 Row Cache 0 0000000065CB9E80 00000000 [01] kqrHashTableInsert (name not found)
3 Row Cache 0 00000000726812D0 00000000 [14] kqrScan (name not found)
2 Row Cache 0 0000000065CBB340 00000000 [01] kqrHashTableInsert (name not found)
1 Row Cache 0 0000000065CBA8E0 00000000 [10] kqreqd (name not found)
1 Row Cache 0 00000000726812D0 00000000 [10] kqreqd (name not found)
1 Row Cache 0 0000000063A3A570 00000000 [10] kqreqd (name not found)
17 rows selected.
--//前面p2raw=0000000000000013，0000000000000011转换10进制就是19，17,注意看GET_LOCATION前面的数字一致。
--//也就是知道p1raw,p2raw无法定位具体那个对象，仅仅知道大致的方向。
--//注意看IDN=134224505，134224506转换16进制，对应08001A79，08001A7A(不知道是否巧合2者差1)。
--//猜测前面的08对应cache_id.这样后面 0x1a79，0x1a7a定义hash值。
--//0x1a79 = 6777 0x1a7a = 6778.
SYS@book> @ dc/dc_objects "hash=6777"
no rows selected
SYS@book> @ dc/dc_objects "hash=6778"
no rows selected
--//奇怪无法查询到相关信息，难道这么快从数据字典缓存消失了。
--//再次执行测试：
$ zzdate;seq 50 | xargs -IQ -P 50 sqlplus -s -l '/ as sysdba' @zz6.txt 8e4 test1 Q > /dev/null ; zzdate
SYS@book> @ dc/dc_objects "hash in(6777)"
no rows selected
SYS@book> @ dc/dc_objects "hash in(6778)"
no rows selected
SYS@book> @ dc/dc_objects "hash in(6777,6778)"
USERNAME DC_OBJ_NAME KEY_STR_LEN HASH_HEX INDX HASH ADDRESS CACHE# CACHE_NAME EXISTENT LOCK_MODE LOCK_REQUEST TXN SADDR INST_LOCK_REQUEST INST_LOCK_RELEASE IN INST_LOC INST_LOC CON_ID
-------- ----------- ----------- -------- ------ ------ ---------------- ------ ---------- -------- ---------- ------------ ---------------- ---------------- ----------------- ----------------- -- -------- -------- ------
SYS 0 0x1a79 6095 6777 0000000067311348 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6114 6778 0000000065353D70 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a79 6096 6777 0000000065CBBC98 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a79 6097 6777 0000000065CBB768 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a79 6098 6777 0000000065CBB238 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a79 6099 6777 0000000065CBAD08 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a79 6100 6777 0000000065CBA7D8 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a79 6101 6777 0000000065CB73F8 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a79 6102 6777 000000006BAB68B0 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a79 6103 6777 0000000063A3A468 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6104 6778 0000000067304668 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6105 6778 0000000065CBA2A8 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6106 6778 0000000065CB9D78 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6107 6778 0000000065CB9848 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6108 6778 0000000065CB9318 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6109 6778 0000000065CB8DE8 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6110 6778 0000000065CB88B8 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6111 6778 0000000065CB8388 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6112 6778 0000000065CB7E58 11 dc_objects N 0 0 00 00 0 0 00 00 1
SYS 0 0x1a7a 6113 6778 0000000065CB7928 11 dc_objects N 0 0 00 00 0 0 00 00 1
KOTTBX$ 7 0x1a7a 2002 6778 000000006FB8D328 8 dc_objects Y 0 0 00 00 0 0 00 00 2
21 rows selected.
--//注：前者查询可以利用 x$kqrfp的索引，后者选择全表扫描。理论2者都应该查询到结果，也许遇到bug。
--//后记：理论使用@ dc/dc_objects "hash in(6777)"应该可以查询到，是否遇到某种bug，就算查询不到应该建立1条记录。而不是建
--//立这么多条记录。
SYS@book> @ dc/dc_objects "DC_OBJ_NAME='DEPT'"
USERNAME DC_OBJ_NAME KEY_STR_LEN HASH_HEX INDX HASH ADDRESS CACHE# CACHE_NAME EXISTENT LOCK_MODE LOCK_REQUEST TXN SADDR INST_LOCK_REQUEST INST_LOCK_RELEASE IN INST_LOC INST_LOC CON_ID
-------- ----------- ----------- -------- ------ ------ ---------------- ---------- -------------------- -------- ---------- ------------ ---------------- ---------------- ----------------- ----------------- -- -------- -------- ------
SCOTT DEPT 4 0x3df8 4585 15864 000000006640CA20 8 dc_objects Y 0 0 00 00 0 0 00 00 3
SCOTT DEPT 4 0x2271 1977 8817 000000006640CA20 8 dc_objects Y 0 0 00 00 0 0 00 00 3
--//怎么会出现2条。
SYS@book> select * from v$rowcache_parent where hash=15864;
no rows selected
SYS@book> select * from v$rowcache_parent where hash=8817;
no rows selected
--//单独查询缺省没有返回。
SYS@book> select * from v$rowcache_parent where hash in (15864,8817);
INDX HASH ADDRESS CACHE# CACHE_NAME EXISTENT LOCK_MODE LOCK_REQUEST TXN SADDR INST_LOCK_REQUEST INST_LOCK_RELEASE IN INST_LOC INST_LOC KEY CON_ID
------ ---------- ---------------- ---------- -------------------- -------- ---------- ------------ ---------------- ---------------- ----------------- ----------------- -- -------- -------- ------------------------------ ------
1982 8817 000000006640CA20 8 dc_objects Y 0 0 00 00 0 0 00 00 6D0000000400444550540000000000 3
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
00000000000000000000
4590 15864 000000006640CA20 8 dc_objects Y 0 0 00 00 0 0 00 00 6D0000000400444550540000000000 3
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
000000000000000000000000000000
00000000000000000000
--//address=000000006640CA20都是相同的。
SYS@book> @ xind x$kqrfp
IF $ OCCUR IN MIDDLE DO NOT USING \$ !! ,for example:
@ xind x$table_name
@ xind x$kglob$|x$kgldp$
DERIVED_TABLES TABLE_NAME INDEX_NUMBER COLUMN_NAME COLUMN_POSITION CON_ID
------------------------------ ------------------------------ ------------ ------------------------------ --------------- ------
X$KQRFP 1 KQRFPHSH 0 0
--//CACHE#=11，EXISTENT=N,这些对象根本不存在，根据上午的测试：
--//[20260809]跟踪执行select sid from v$mystat where rownum=1;.txt
--//大致可以确定object_id=4294951107,4294951930,对象名 V$MYSTAT,X$KSUSGIF.
--//转储row cache信息看看。
SYS@book> alter session set events 'immediate trace name row_cache level 12';
Session altered.
SYS@book> alter session set events 'immediate trace name row_cache off';
Session altered.
--//注意跟踪文件的BUCKET从1开始计数。对应bucket的值等于hash+1.
$ awk '/^BUCKET 6778:/,/^ BUCKET 6779/' /u01/app/oracle/diag/rdbms/book/book/trace/book_ora_4198.trc > 6777-6778.txt
$ grep objectno 6777-6778.txt| uniq -c
10 objectno=4294951930 ownerid=0 nsp=0
12 objectno=4294951107 ownerid=0 nsp=0
SYS@book> select * from gv$fixed_table where object_id in ( 4294951107, 4294951930);
INST_ID NAME OBJECT_ID TYPE TABLE_NUM CON_ID
---------- ------------------------------ ---------- ------------------------------ ---------- ----------
1 X$KSUSGIF 4294951930 TABLE 52 0
1 V$MYSTAT 4294951107 VIEW 65537 0
--//通过这里基本可以确定对象号。为什么EXISTENT=N，不是很清楚，也许正是找不到，导致每次查询都要访问数据字典，猜测遇到bug。
--//内容太多，仅仅贴出部分信息：
BUCKET 6778:
row cache parent object: addr=0x6b933e60 cid=11(dc_objects)
conid=1 conuid=1 inc=1, pdbinc=1
hash=0 typ=41 transaction=(nil) flags=00000001
version=1 mtx version=41
objectno=4294951930 ownerid=0 nsp=0
~~~~~~~~~~~~~~~~~~~~
own=0x6b933f30[0x6b933f30,0x6b933f30] wat=0x6b933f40[0x6b933f40,0x6b933f40] mode=N req=N
status=EMPTY/-/-/-/-/-/-/-/-/-/-/- KGH unpinned CLONE primary=0x67311348 count=10
set=0, complete=FALSE
data=
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 ffffc3fa 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000100 00000000
6b933e60 00000000 6b934250 00000000 6b934250 00000000 00000001 40d79a79
6b933e60 00000000 63a3a878 00000000 7785f128 00000000
--//ffffc3fa = 4294951930
...
BUCKET 6779:
row cache parent object: addr=0x70f29c10 cid=11(dc_objects)
conid=1 conuid=1 inc=1, pdbinc=1
hash=0 typ=41 transaction=(nil) flags=00000001
version=1 mtx version=41
objectno=4294951107 ownerid=0 nsp=0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
own=0x70f29ce0[0x70f29ce0,0x70f29ce0] wat=0x70f29cf0[0x70f29cf0,0x70f29cf0] mode=N req=N
status=EMPTY/-/-/-/-/-/-/-/-/-/-/- KGH unpinned CLONE primary=0x67304668 count=12
set=0, complete=FALSE
data=
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 ffffc0c3 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000100 00000000
70f29c10 00000000 70f2a000 00000000 70f2a000 00000000 00000001 46ad9a7a
70f29c10 00000000 65354180 00000000 7785f138 00000000
--//ffffc0c3 = 4294951107
--//顺便想了解对应hash值oracle如何计算的，那位了解这方面信息。
4.附上测试使用代码：
$ cat dc/dc_objects.sql
column DC_PROP_NAME format a28
column CACHE_NAME format a20
column EXISTENT format a8
column KEY_OID$ format a32
column dc_obj_name format a32
column dc_obj_name1 format a32
column username format a20
column con_id format 99999
column indx format 99999
column hash format 99999
column key noprint
SELECT *
FROM (SELECT --TO_NUMBER ( (SUBSTR (key, 7, 2) || SUBSTR (key, 5, 2) || SUBSTR (key, 3, 2) || SUBSTR (key, 1, 2)), 'XXXXXXXX') Schema_User_ID ,
(SELECT username
FROM cdb_users
WHERE con_id= v.con_id and user_id =
TO_NUMBER (
(SUBSTR (key, 7, 2) || SUBSTR (key, 5, 2) || SUBSTR (key, 3, 2) || SUBSTR (key, 1, 2))
,'XXXXXXXX'))
username
--,RTRIM (UTL_RAW.cast_to_varchar2 (SUBSTR (v.key, 13)), CHR (0)) dc_obj_name
--,TO_NUMBER (TRIM (BOTH '0' FROM SUBSTR (key, 11, 2) || SUBSTR (key, 9, 2)), 'XXXX') key_str_len
,UTL_RAW.cast_to_varchar2 (SUBSTR (v.key, 13,2*TO_NUMBER ( SUBSTR (key, 11, 2) || SUBSTR (key, 9, 2), 'XXXX'))) dc_obj_name
,TO_NUMBER ( SUBSTR (key, 11, 2) || SUBSTR (key, 9, 2), 'XXXX') key_str_len
,'0x'||to_char(v.hash,'FMxxxxx') hash_hex
,v.*
FROM v$rowcache_parent v
WHERE cache# in (8,11)
)
WHERE (&1)
ORDER BY key;
column key print
column hash clear
[20260809]Row Cache Mutex 定位具体对象的方法.txt
![[20260809]Row Cache Mutex 定位具体对象的方法.txt](http://pic.xiahunao.cn/yaotu/[20260809]Row Cache Mutex 定位具体对象的方法.txt)