library cache中parent cursor 及child cursor 问题

tolywang

原帖由 Yong Huang 于 2010-11-3 23:28 发表
> 第二种是A发出的语句经过对象名称转化后和在shared pool 中的SQL文本一模一样，父游标可以共享，

Again, if the initial SQL text doesn't match, the parent cursor is not shared. "语句经过对象名称转化后" is done in the second step, which already passed the initial text match.

Note:296377.1 has the words "The fundementals are that the parent is not shared, it is the children which determine shareability." I think the first part is meaningless, or should not be understood literally. I say the parent is shared only in the sense that this same SQL (same in terms of SQL text or hash value or sql ID) is executed or attempted to execute another time.

Yong Huang

是的，我错误地将base objects 的转换这一步放在了查找共享父游标之前，查看了V$SQL_SHARED_CURSOR ， 所有相关 mismatch 的内容都是针
对 the existing child cursor ， 包括 TRANSLATION_MISMATCH （The base objects of the existing child cursor do not match）， 可以看
出各种 mismatch 已经是在针对子游标共享需要的条件了 。  查找是否有共享的父游标和硬解析是两个不同的过程，父游标共享与否和硬解析没有直接关系，
子游标的共享状态决定软硬解析 。     



更正：

第一种是A发出的原始SQL语句和其他用户B之前发出的SQL文本一模一样，父亲游标可以共享，但是因为优化器环境设置不同( OPTIMIZER_MISMATCH)，  绑定变量的值的长度在第二次执行的时候发生显著
的变化(BIND_MISMATCH) , 授权关系不匹配(AUTH_CHECK_MISMATCH ) 或者 基础物件转换不匹配(TRANSLATION_MISMATCH) 等导致子游标不能共享，需要新生成一个子游标 。 这与SQL共享(即游标共享)
是有关系的 。 这种情况下的执行计划可能不同，也可能相同((我们可以通过plan_hash_value看出));   这里因为除SQL TEXT之外的其他条件不符合，所以reload 也不会发生 。子游标就是new create and load，
应该是硬解析 。具体的mismatch可以查询 V$SQL_SHARED_CURSOR .  

第二种是A发出的原始SQL语句和与在shared pool 中的SQL文本一模一样，父游标可以共享，子游标不存在所谓的mismatch ,  目前也存在于库缓存中，可以共享子游标，那么应该是软解析 。

第三种，父游标可以共享， 不同的是，子游标本来是可以共享的，但是目前被交换出(aged out)库缓存，这时会reload 子游标，也就是利用父游标的信息重新构造出一个子游标 ，Oracle已经知道应该共享哪
个子游标，只是它暂时被交换出库缓存， reload应该不属于硬解析(但是也需要消耗硬件资源)， 是否属于软解析呢 ？ 因为比较消耗硬件资源， 应该也不是软解析。虽然被aged out 出库缓存，但是可能某个
地方会记录这个子游标的一些信息，而不需要重新生成子游标的相关信息(比如执行计划或执行计划之外的其他辅助信息等),  而只需要reload (消耗的资源介于硬解析和软解析之间 ？ )。

[ 本帖最后由 tolywang 于 2010-11-4 11:46 编辑 ]

ccsnmoracle

原帖由 tolywang 于 2010-11-4 10:37 发表
  
第一种是A发出的原始SQL语句和其他用户B之前发出的SQL文本一模一样，父亲游标可以共享，但是因为优化器环境设置不同( OPTIMIZER_MISMATCH)，  绑定变量的值的长度在第二次执行的时候发生显著
的变化(BIND_MISMATCH) , 授权关系不匹配(AUTH_CHECK_MISMATCH ) 或者 基础物件转换不匹配(TRANSLATION_MISMATCH) 等导致子游标不能共享，需要新生成一个子游标 。 这与SQL共享(即游标共享)
是有关系的 。 这种情况下的执行计划可能不同，也可能相同((我们可以通过plan_hash_value看出));   这里因为除SQL TEXT之外的其他条件不符合，所以reload 也不会发生 。子游标就是new create and load，
应该是硬解析 。具体的mismatch可以查询 V$SQL_SHARED_CURSOR .  

第二种是A发出的原始SQL语句和与在shared pool 中的SQL文本一模一样，父游标可以共享，子游标不存在所谓的mismatch ,  目前也存在于库缓存中，可以共享子游标，那么应该是软解析 。

第三种，父游标可以共享， 不同的是，子游标本来是可以共享的，但是目前被交换出(aged out)库缓存，这时会reload 子游标，也就是利用父游标的信息重新构造出一个子游标 ，Oracle已经知道应该共享哪
个子游标，只是它暂时被交换出库缓存， reload应该不属于硬解析(但是也需要消耗硬件资源)， 是否属于软解析呢 ？ 因为比较消耗硬件资源， 应该也不是软解析。虽然被aged out 出库缓存，但是可能某个
地方会记录这个子游标的一些信息，而不需要重新生成子游标的相关信息(比如执行计划或执行计划之外的其他辅助信息等),  而只需要reload (消耗的资源介于硬解析和软解析之间 ？ )。

学习了。