绑定变量窥视之cursor pin S wait on X 单步调试

作者简介:孙显鹏,Oracle 十年从业经验,拥有11G ocp认证,精通内部原理,擅长调优,解决疑难问题,致力于帮助客户解决生产过程过出现的性能问题,提高生产效率!爱好书法!

 

目标:

通过gdb单步调试模拟 cursor: pin S wait on X 等待以及内部原理,解释为什么绑定变量窥视会请求 mutex cursor: pin X 锁.

测试环境:

Linux 7+Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 – 64bit Production

步骤:

session A:

session B:

窗口(root):

session A:

由于刷新共享池,SESSION A 需要硬解析需要窥视绑定变量,需要申请 mutex cursor: pin X ,而我们使用gdb在窥视步骤中设置了断点,此时session A等待,接下来gdb调试下一步

session A 获取 cursor X ,如下:)

窗口:

session C:

(此时session A 在子游标上持有cursor X,session C 执行查询需要申请 cursor S,模式不兼容等待)

我们查询等待事件:

查看session C stack call:

kkscsSearchChildList 搜索child cursor list

kkscsCheckCursor 检查child cursor

kxsGetRuntimeLock kgxSharedExamine 尝试获取child cursor上的SHRD 共享PIN

尝试获取失败后 进入Mutex等待 kgxWait

 

查看trace systemstate 266:

窗口:

我们继续在该窗口执行cont,session A会释放X锁,session C 等待消失

总结:

我们使用gdb在session A设置kxsPeekBinds断点进行单步调试,然后刷新共享池,session A执行SQL,此时session A 必须要进行绑定变量窥视需要在子游标请求 mutex cursor pin X,

session A 执行kxsPeekBinds 操作停止,我们手动让session A 获的 mutex cursor pin X 然后停止前进,session C 执行SQL语句因内存中已经存在请求 mutex cursor pin S,S和X不

兼容,出现等待cursor: pin S wait on X,使用 oradebug 我们很清楚看到这一步骤。

 

未经允许不得转载:Oracle一体机用户组 » 绑定变量窥视之cursor pin S wait on X 单步调试

相关推荐