Home > TSOP > sql_id VS hash_value

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

sys@TESTDB>select kglnahsv, kglnahsh from x$kglob where kglnaobj ='select ''landrover'' from dual';

KGLNAHSV                            KGLNAHSH
--------------------------------- ----------
8605074c682c4c4da7d495aacf3751e2  3476509154
8605074c682c4c4da7d495aacf3751e2  3476509154

sys@TESTDB>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转换的方法:

sys@TESTDB>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

Categories: TSOP Tags:
  1. No comments yet.
  1. No trackbacks yet.