[20241115]软解析与修改mutex值的问题.txt
--//一般前4字节表示持有muext的数量，后4字节表示阻塞该mutex的sid。在intel系列CPU有时候显示是反过来。
$ mod_addr.sh 7309f5c0 0 1
0x7309f5c0: 0x00000001
$ disp_addr.sh 7309f5b0 0 12 wx
0x7309f5b0: 0x61562170 0x00000000 0x61562170 0x00000000
0x7309f5c0: 0x00000001 0x00000000 0x00000011 0x000092b1
~~~~~~~~~
0x7309f5d0: 0x000193b7 0x00000000 0x61452798 0x00000000
$ disp_addr.sh 7309f5b0 0 6 gx
0x7309f5b0: 0x0000000061562170 0x0000000061562170
0x7309f5c0: 0x0000000000000001 0x000092b100000011
~~~~~~~~~~~~~~~~~~
0x7309f5d0: 0x00000000000193b7 0x0000000061452798
--//在tpt ashtop的现在p2raw时也存在类似问题。
--//我一直以为前4字节表示持有muext的数量不是0，不影响其他会话的执行相关语句，看来有点错误，通过演示说明问题。
1.环境：
SCOTT@book01p> @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.
SCOTT@book01p> select * from dept where deptno=40;
DEPTNO DNAME LOC
---------- ------------------------------ -------------
40 OPERATIONS BOSTON
SCOTT@book01p> @ hash
HASH_VALUE SQL_ID CHILD_NUMBER KGL_BUCKET PLAN_HASH_VALUE HASH_HEX SQL_EXEC_START SQL_EXEC_ID
---------- ------------- ------------ ---------- --------------- ---------- ------------------- -----------
3912471479 14ymr4znm74xr 0 103351 2852011669 e93393b7 2024-11-15 09:37:34 16777234
2.测试：
--//session 1:
SCOTT@book01p> @ spid
==============================
SID : 395
SERIAL# : 45513
PROCESS : 4321
SERVER : DEDICATED
SPID : 4323
PID : 63
P_SERIAL# : 9
KILL_COMMAND : alter system kill session '395,45513' immediate;
PL/SQL procedure successfully completed.
SCOTT@book01p> select * from dept where deptno=40;
DEPTNO DNAME LOC
---------- ------------------------------ -------------
40 OPERATIONS BOSTON
--//注在此之前这条语句已经执行多次。
--//window 1:
$ mod_addr.sh 7309f5c0 0 1
0x7309f5c0: 0x00000001
$ disp_addr.sh 7309f5b0 0 12 wx
0x7309f5b0: 0x61562170 0x00000000 0x61562170 0x00000000
0x7309f5c0: 0x00000001 0x00000000 0x00000011 0x000092b1
~~~~~~~~~~
0x7309f5d0: 0x000193b7 0x00000000 0x61452798 0x00000000
--//session 1:
SCOTT@book01p> select * from dept where deptno=40;
DEPTNO DNAME LOC
---------- ------------------------------ -------------
40 OPERATIONS BOSTON
--//确实可以正常执行，理论讲在打开session_cached_cursors>0的情况下，该光标已经cache了。
$ disp_addr.sh 7309f5b0 0 12 wx
0x7309f5b0: 0x61562170 0x00000000 0x61562170 0x00000000
0x7309f5c0: 0x00000001 0x00000000 0x00000011 0x000092b1
0x7309f5d0: 0x000193b7 0x00000000 0x61452798 0x00000000
--//gets数量不变，说明该光标已经cache了。
--//这个时候查询select * from v$open_cursor where sid=395;会挂起!!
3.继续测试：
--//session 1,退出重新登录：
SCOTT@book01p> select * from dept where deptno=40;
--//挂起!!
--//重新登录后第1次执行软解析。
SYS@book> @ ashtop event,p1raw,p1,p2raw,p3raw 1=1 &30s
Total Distinct Distinct Distinct
Seconds AAS %This EVENT P1RAW P1 P2RAW P3RAW FIRST_SEEN LAST_SEEN Execs Seen Tstamps Execs Seen1
--------- ------- ------- ------------------------------------------ ----------------- ---------- ----------------- ----------------- ------------------- ------------------- ---------- -------- -----------
16 .5 50% | library cache: bucket mutex X 00000000000193B7 103351 0000000000000001 000000000000003E 2024-11-15 09:12:06 2024-11-15 09:12:35 1 16 16
11 .4 34% | 103351 2024-11-15 09:12:10 2024-11-15 09:12:34 1 11 11
2 .1 6% | 3 2024-11-15 09:12:07 2024-11-15 09:12:16 1 2 2
2 .1 6% | 131072 2024-11-15 09:12:30 2024-11-15 09:12:34 2 2 2
1 .0 3% | 65536 2024-11-15 09:12:32 2024-11-15 09:12:32 1 1 1
--//查看30s，显示library cache: bucket mutex X最多消耗16-18秒。P2RAW=0000000000000001，P3raw=000000000000003E,0x3e = 62。
--//window 1:
$ mod_addr.sh 7309f5c0 0 0
0x7309f5c0: 0x00000000
--//session 1,执行完成。
COTT@book01p> select * from dept where deptno=40;
DEPTNO DNAME LOC
---------- ------------------------------ -------------
40 OPERATIONS BOSTON
--//window 1:
$ mod_addr.sh 7309f5c0 0 1
0x7309f5c0: 0x00000001
--//session 1,第2次执行。
SCOTT@book01p> select * from dept where deptno=40;
DEPTNO DNAME LOC
---------- ------------------------------ -------------
40 OPERATIONS BOSTON
--//也就是讲在软解析的情况下前4字节表示持有muext的数量不等于0的情况下也会影响其他程序的sql语句运行。
--//特别是一些程序喜欢反复登录执行1次，马上退出的情况，这样基本每次登录执行的都是软解析。
--//另外在这样的情况下测试环境无法查询select * from v$open_cursor where sid=395;以及使用mutexprofz.sql脚本。
--//因为设置mod_addr.sh 7309f5c0 0 1的原因。
$ mod_addr.sh 7309f5c0 0 0
0x7309f5c0: 0x00000000
SYS@book> select * from v$open_cursor where sid=395 and sql_id='14ymr4znm74xr'
2 @pr
==============================
SADDR : 000000007B972150
SID : 395
USER_NAME : SCOTT
ADDRESS : 0000000061562170
HASH_VALUE : 3912471479
SQL_ID : 14ymr4znm74xr
SQL_TEXT : select * from dept where deptno=40
LAST_SQL_ACTIVE_TIME : 2024-11-15 09:17:06
SQL_EXEC_ID :
CURSOR_TYPE : SESSION CURSOR CACHED
CHILD_ADDRESS : 0000000061560A10
CON_ID : 3
PL/SQL procedure successfully completed.
SYS@book> @ mutexprofz idn,hash,val,loc,maddr "ts>='2024-11-15 09:15:00' "
-- MutexProf by Tanel Poder (http://www.tanelpoder.com)
-- Showing profile of top 20 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 HASH VAL GET_LOCATION mutex_addr OBJECT_NAME
---------- -------------- --------------- ---------- ---------- ---------------- --------------------------------- -------------------- ----------------
55027 Library Cache 103351 0000000000000001 kglic1 49 000000007309F5C0 (name not found)
43788 Library Cache 103351 0000000000000001 kglhdgn1 62 000000007309F5C0 (name not found)
--//GET_LOCATION=kglic1 49, 应该是测试时select * from v$open_cursor where sid=395;以及使用mutexprofz.sql脚本引起的。
3.另外我设置set statementcache 100也一样，第1次执行挂起。第2次执行正常。
--//window 1:
$ mod_addr.sh 7309f5c0 0 1
0x7309f5c0: 0x00000001
--//session 1,重新登录：
SCOTT@book01p> set statementcache 100
SCOTT@book01p> select * from dept where deptno=40;
--//挂起。
DEPTNO DNAME LOC
---------- ------------------------------ -------------
40 OPERATIONS BOSTON
--//window 1:
$ mod_addr.sh 7309f5c0 0 0
0x7309f5c0: 0x00000001
--//session 1
SCOTT@book01p> select * from dept where deptno=40;
DEPTNO DNAME LOC
---------- ------------------------------ -------------
40 OPERATIONS BOSTON
4.最后一旦进入软软解析，muext前4字节后4字节有值，都不会影响sql语句的执行，这时sql的执行已经光标已经cache，直接选择子光标
堆6的执行计划。
$ mod_addr.sh 7309f5c0 0 1
0x7309f5c0: 0x00000001
$ mod_addr.sh 7309f5c4 0 1
0x7309f5c4: 0x00000001
--//session 1
SCOTT@book01p> select * from dept where deptno=40;
DEPTNO DNAME LOC
---------- ------------------------------ -------------
40 OPERATIONS BOSTON
--//多次执行没有问题。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/267265/viewspace-3050260/ ，如需转载，请注明出处，否则将追究法律责任。
最新文章
- [20261008]验证Shared Memory Segments key以及Semaphore Arrays Key(11g).txt
- [20261008]gdb引入结构体是否可行.txt
- [20261008]bpftrace定义结构体例子.txt
- [20261007]关于oracle sskgph2函数.txt
- [20261007]oracle Semaphore Arrays Key值的冲突.txt
- [20261004]oracle sskgph2函数等价c以及python脚本.txt
- [20261004]bpftrace查看oracle函数调用堆栈问题.txt
- [20261002]验证sskgphpjw函数参与运算的字符串是否存在规律.txt
- [20261002]oracle Semaphore Arrays Key值的计算2.txt
- [20261001]oracle Semaphore Arrays Key值的计算.txt
