[转] sql_id VS hash_value
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[转] sql_id VS hash_value相关的知识,希望对你有一定的参考价值。
有没有发现,v$session,v$sql,v$sqlarea,v$sqltext,v$sql_shared_cursor等试图连接的时候经常会用到hash_value,sql_id,但是他们2个之间到底有什么不可告人的关系呢?
Talnel以及评论的一坨人(包括jonathan)给了一个蛮不错的解释:
SQL_ID is just a fancy representation of hash value
[email protected]>select kglnahsv, kglnahsh from x$kglob where kglnaobj =‘select ‘‘landrover‘‘ from dual‘; KGLNAHSV KGLNAHSH --------------------------------- ---------- 8605074c682c4c4da7d495aacf3751e2 3476509154 8605074c682c4c4da7d495aacf3751e2 3476509154 [email protected]>select sql_id, hash_value, old_hash_value from v$sql where sql_text =‘select ‘‘landrover‘‘ from dual‘; SQL_ID HASH_VALUE OLD_HASH_VALUE ------------- ---------- -------------- agp4ppb7mfng2 3476509154 3053997704
同时,10g+提供了一个sql_id到hash_value转换的方法:
[email protected]>select dbms_utility.SQLID_TO_SQLHASH(‘agp4ppb7mfng2‘) hash_value FROM DUAL; HASH_VALUE ---------- 3476509154
10g以后,他们的关系是这样的:
1)oracle 用MD5算法对library cache obj 进行哈希,生成一个128bit的hash value,也就是KGLNAHSV(16进制).
2)KGLNAHSV的低64bit作为SQL_ID(32进制).
3)KGLNAHSV的低32bit作为HASH_VALUE(10进制)
因为10g+的哈希算法变了,所以10g之前的hash_value其实v$sql.old_hash_value。
但是需要说的是,library cache obj实际上还是通过hash_value+address的方式来组织的,Tanel只说了sql_id的后4 bytes是hash_value,但是没有说前4 bytes代表什么含义,个人觉得KGLNAHSV中有一部分应该是代表了address的,因为既然hash_value是sql_id的子集,如果sql_id可以唯一确定一个obj,那单独用hash_value肯定会存在不同SQL_ID但HASH_VALUE冲突的情况,尽管目前没人遇到过或者证明过,以他得话来说,可能性是1 in 4 billion。
至于oracle推出SQL_ID的意义,Tanel认为只是hash_value的一个更友好的别名。按照jonathan的说法,以后的版本可能会逐渐淘汰4 bytes的HASH_VALUE,而改用8 bytes的SQL_ID(也许名字会不一样),因为他更精确。但是现有的代码很多地方都还使用的32-bit的hash_value,所以hash_value需要做到向后兼容,就像当初10g逐渐淘汰9i的哈希算法一样(v$sql.old_hash_value)。这可能就是sql_id的意义所在。
具体计算可以参考:
关于sql_id与hash_value
Oracle sql_id and hash value
转自: http://www.johnnydb.com/2012/03/sql_id-vs-hash_value/
以上是关于[转] sql_id VS hash_value的主要内容,如果未能解决你的问题,请参考以下文章
[20171227]表的FULL_HASH_VALUE值的计算.txt