前阵子总结了这篇“ORACLE当中自定义函数性优化浅析”博客,里面介绍了标量子查询缓存(scalar subquery caching),如果使用标量子查询缓存,ORACLE会将子查询结果缓存在哈希表中,如果后续的记录出现同样的值,优化器通过缓存在哈希表中的值,判断重复值不用重复调用函数,直接使用上次计算结果即可。从而减少调用函数次数,从而达到优化性能的效果。另外在ORACLE 10和11中, 哈希表只包含了255个Buckets,也就是说它能存储255个不同值,如果超过这个范围,就会出现散列冲突。 更多详细新可以参考我那篇博客

当然,哈希表只包含了255个Buckets是怎么来的呢?这个是Tom大神推算而来,我也没有测试过,后面网友lfree反馈他的测试结果跟这个结果不同。他反馈在ORACLE 10g下,测试结果实际上是512, ORACLE 11g为1024。由于前阵子比较忙,拖延症犯了,另外也跟他缺少沟通,不过有个志同道合的人讨论感兴趣的技术话题是一件幸事。最近有时间,看完了他的关于这个问题的多篇文章,学到了不少东西,也咨询了一下他一下具体细节,具体测试了一下,感觉他的测试方法有点复杂,部分结论过早给出定论了! 但是自己也没有一个合理的测试验证方法。遂啃了一下Tom大神的On Caching and Evangelizing SQL这篇雄文。在这里结合自己的理解,重新演示一下,下面测试环境为Oracle 11g,关于Hash Table,估计有些人会比较懵,借用Tom大神的述说:

You cannot 'see' the hash table anywhere, it is an internal data structure that lives in your session memory for the duration of the query. Once the query is finished - it goes away.

It is a cache associated with your query - nothing more, nothing less.

You can "see" it in action by measuring how many times your function is called, for example:

首先,创建这个自定义函数,这个函数是用来验证哈希表大小的关键所在(确实是一个构造很巧妙,而且又简单的函数。大神真不是盖的)。如果对函数dbms_application_info.set_client_info不了解的,自行搜索、学习这个知识点!

create or replace function f( x in varchar2 ) return number

as

begin

        dbms_application_info.set_client_info(userenv('client_info')+1 );

        return length(x);

end

然后创建测试表,插入测试数据。然后就可以开始我们的测试,

CREATE TABLE TEST(ID NUMBER);

INSERT INTO TEST

SELECT 1 FROM DUAL UNION ALL

SELECT 1 FROM DUAL UNION ALL

SELECT 1 FROM DUAL UNION ALL

SELECT 2 FROM DUAL UNION ALL

SELECT 2 FROM DUAL UNION ALL

SELECT 2 FROM DUAL UNION ALL

SELECT 3 FROM DUAL UNION ALL

SELECT 3 FROM DUAL;

COMMIT;

准备好上述测试环境,我们就可以用下面脚本来测试、验证标量函数被调用了多少次(注意下面这段脚本会被多次使用,下面测试部分会多次使用,后续可能直接称呼其为test.sql,而不会每次贴出这段脚本)

variable cpu number;

begin

   :cpu := dbms_utility.get_cpu_time; 

      dbms_application_info.set_client_info(0);

end;

select id,(select f(id) from dual) as client_info from test;

select dbms_utility.get_cpu_time- :cpu cpu_hsecs, 

             userenv('client_info') 

from dual;

我们可以看到测试结果userenv('client_info')的值为3, 这意味着标量函数被递归调用了3次(如果不理解的话,多补一下基础知识)

如果你对这种方式存在质疑的话,也可以使用10046 trace找到SQL的真实执行计划。具体SQL如下所

alter session set events '10046 trace name context  forever,level 12'; 

 

select id,(select f(id) from dual) as client_info from test;

 

alter session set events '10046 trace name context off';  

 

SELECT T.value 

       || '/' 

       || Lower(Rtrim(I.INSTANCE, Chr(0))) 

       || '_ora_' 

       || P.spid 

       || '.trc' TRACE_FILE_NAME 

FROM   (SELECT P.spid 

        FROM   v$mystat M, 

               v$session S, 

               v$process P 

        WHERE  M.statistic# = 1 

               AND S.sid = M.sid 

               AND P.addr = S.paddr) P, 

       (SELECT T.INSTANCE 

        FROM   v$thread T, 

               v$parameter V 

        WHERE  V.name = 'thread' 

               AND ( V.value = 0 

                      OR T.thread# = To_number(V.value) )) I, 

       (SELECT value 

        FROM   v$parameter 

        WHERE  name = 'user_dump_dest') T;

找到测试生成的trace文件,格式化后,如下截图所示,FAST DUAL表示执行子查询的次数,也就是递归调用次数。

[oracle@DB-Server trace]$ tkprof gsp_ora_11336.trc klb_out.txt

删除这个表,然后我们构造一个拥有从1到255的新表,然后执行test.sql,测试看看标量函数会调用多少次,如下所示:

SQL> drop table test purge;

 

Table dropped.

 

SQL> create table test as select rownum id from dual connect by level<=255;

 

Table created.

如下所示,可以看到当前情况下,标量函数执行了255次

然后插入1、2、 3 三个值,我们再执行一下test.sql,看看优化器是否使用哈希表中缓存的记录,减少函数调用次数。如下所示,函数还是只调用了255次。

INSERT INTO TEST

SELECT 1 FROM DUAL UNION ALL

SELECT 2 FROM DUAL UNION ALL

SELECT 3 FROM DUAL;

COMMIT;

然后我们清空表TEST中的数据,然后使用下面脚本构造相关数据后, 执行test.sql继续我们的测试。

SQL> TRUNCATE TABLE TEST;

 

Table truncated.

 

SQL> DECLARE RowIndex NUMBER;

  2  BEGIN

  3  RowIndex :=1;

  4  WHILE RowIndex <= 255 LOOP

  5      INSERT INTO TEST

  6      SELECT RowIndex  FROM DUAL;

  7      

  8       RowIndex := RowIndex +1;

  9  END LOOP;

 10  COMMIT;

 11  END;

 12  /

 

PL/SQL procedure successfully completed.

 

SQL> DECLARE RowIndex NUMBER;

  2  BEGIN

  3  RowIndex :=1;

  4  WHILE RowIndex <= 255 LOOP

  5      INSERT INTO TEST

  6      SELECT RowIndex  FROM DUAL;

  7      

  8       RowIndex := RowIndex +1;

  9  END LOOP;

 10  COMMIT;

 11  END;

 12  /

 

PL/SQL procedure successfully completed.

 

SQL> 

其实这里出现这个问题,是因为1-255中,有些数因为HASH冲突,导致无法缓存到哈希表中,我们来验证测试一下,如下所示,9和16出现HASH冲突(为什么会出现HASH冲突,这个不清楚,因为我们不清楚它的HASH算法),由于9和16出现HASH 冲突,从而导致16无法缓存到哈希表,从而导致两条16的记录调用了两次,所以标量函数被调用了3次。但是如果出现冲突的记录,两次重复出现,那么它会重用上一次的调用函数的结果。如下测试所示:

我们继续往表TEST里面插入一条ID=16的记录, 我们开始测试

SQL> INSERT INTO TEST VALUES(16);

 

1 row created.

 

SQL> COMMIT;

 

SQL> select id,(select f(id) from dual) from test where id in (9,16);

 

        ID (SELECTF(ID)FROMDUAL)

---------- ---------------------

         9                     9

        16                    16

         9                     9

        16                    16

        16                    16

 

SQL> select dbms_utility.get_cpu_time- :cpu cpu_hsecs, userenv('client_info') from dual;

 

 CPU_HSECS USERENV('CLIENT_INFO')

---------- ----------------------------------------------------------------

         1 3

如上所示,自定义函数调用的次数还是3, 按照推理:ID=9的记录调用一次自定义函数,然后ID=16的记录出现HASH冲突,调用一次自定义函数,然后到记录ID=9,发现可以从内存中的哈希表取值,跳过调用自定义函数,接着到ID=16,由于哈希冲突,哈希表没有缓存相关记录,那么还会调用一次自定义函数,再接下来ID=16的记录,由于两次重复出现,那么它会重用上一次的调用函数的结果。所以调用次数为3

如果我们接下来继续插入两条记录,一条为9,一条为16,那么调用自定义函数的次数就会变为4,如下所示:

SQL> insert into test values(9);

 

1 row created.

 

SQL> insert into test values(16);

 

1 row created.

 

SQL> commit;

 

Commit complete.

 

SQL> variable cpu number;

SQL> begin

  2     :cpu := dbms_utility.get_cpu_time; 

  3       dbms_application_info.set_client_info(0);

  4  end;

  5  /

 

PL/SQL procedure successfully completed.

 

SQL>    

SQL> select id,(select f(id) from dual) from test where id in(9,16);

 

 

        ID (SELECTF(ID)FROMDUAL)

---------- ---------------------

         9                     9

        16                    16

         9                     9

        16                    16

        16                    16

         9                     9

        16                    16

 

7 rows selected.

 

SQL> SQL> select dbms_utility.get_cpu_time- :cpu cpu_hsecs, userenv('client_info') from dual;

 

 CPU_HSECS USERENV('CLIENT_INFO')

---------- ----------------------------------------------------------------

         1 4

 

SQL> 

如果我们插入数据的顺序修改一下,如下所示,此时的测试结果就能理解了(之前我一直没有理解清楚,注意之前的截图,你就能理解一二了,如果插入1~255  然后插入 1~255 这里函数的调用次数为306, 如果插入的记录为1、1、2、2 ....255、255 函数调用次数为255)

SQL> TRUNCATE TABLE TEST;

 

Table truncated.

 

SQL> DECLARE RowIndex NUMBER;

  2  BEGIN

  3  RowIndex :=1;

  4  WHILE RowIndex <= 255 LOOP

  5      INSERT INTO TEST

  6      SELECT RowIndex  FROM DUAL UNION ALL

  7      SELECT RowIndex  FROM DUAL;

  8      

  9       RowIndex := RowIndex +1;

 10  END LOOP;

 11  COMMIT;

 12  END;

 13  /

 

PL/SQL procedure successfully completed.

那么我们接下来分析一下,标量子查询缓存中生成的哈希表到底能缓存多少条记录呢?

推理如下 306-255 =51  表示1-255 记录里面,有51个记录跟其它记录存在哈希冲突,那么哈希表中实际缓存255-51=204条记录,然后我们将上面实验的值放大到510,继续测试

TRUNCATE TABLE TEST;

 

DECLARE RowIndex NUMBER;

BEGIN

RowIndex :=1;

WHILE RowIndex <= 510 LOOP

    INSERT INTO TEST

    SELECT RowIndex  FROM DUAL;

    

     RowIndex := RowIndex +1;

END LOOP;

COMMIT;

END;

/

 

DECLARE RowIndex NUMBER;

BEGIN

RowIndex :=1;

WHILE RowIndex <= 510 LOOP

    INSERT INTO TEST

    SELECT RowIndex  FROM DUAL;

    

     RowIndex := RowIndex +1;

END LOOP;

COMMIT;

END;

/

接着分析, 707- 510 = 197  这意味着197个数据存在哈希冲突, 假设内存中的哈希表缓存了510-197=313条记录, 那么313 + 197 + 197 = 707。 假设这个哈希表只能缓存255 bucket的话, 那么按照推理,函数调用次数应该为255 +(510-255)*2 = 765次,显然跟实际次数有出入,那么说明这个值应该大于255。

SQL> select 313 +197 from dual;

313+197

----------

510

SQL> select 313 + 197 + 197 from dual;

313+197+197

-----------

707

我们继续放大插入的值,继续后面测试,后面测试其实我已经无法继续推理,例如,插入2048连续记录,然后插入2048条连续记录,测试发现函数的调用次数为3592

假设哈希表只能缓存1024条记录, 那么 1024+ (2048-1024)*2 = 3072  < 3592 ,这是否意味着哈希表不止缓存1024条记录,其实,到目前为止,我们只发现了部分记录存在HASH冲突,上述测试也是存在假设前提的,例如9 跟 16 存在HAST冲突,那么是否还存在其它值跟它们HASH 冲突呢? 测试越来越复杂,个人在这上面花费了大量的时间,其实是有点不划算的。

透过现象看本质,有时候,局限于知识、认知、眼界,可能并不能透过现象看到本质,更何况这个也是封闭的,官方没有相关解释。所以我们只能透过现象做出一些推理和论证,而很难跨过现象直至本质。

结论:

网友lfree的反馈是对的。标量子查询缓存(scalar subquery caching)中的哈希表缓存的buckets,在ORACLE 10g / 11g 下面确实不止255, 但是这个值到底是多少,这篇博文无法给出一个确切值!

参考资料:

https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:2683853500346598211

https://blogs.oracle.com/oraclemagazine/on-caching-and-evangelizing-sql

ORACLE中Scalar subquery Caching的hash table大小测试浅析的更多相关文章

  1. 【Oracle】Oracle中复合数据类型

    1,常见的操作数据库的技术有那些 jdbc     使用java 访问数据库的技术    PLSQL  (procedure  过程化sql) 在数据库内部操作数据的技术    proc/c++    ...

  2. [转载] 散列表(Hash Table)从理论到实用(中)

    转载自:白话算法(6) 散列表(Hash Table)从理论到实用(中) 不用链接法,还有别的方法能处理碰撞吗?扪心自问,我不敢问这个问题.链接法如此的自然.直接,以至于我不敢相信还有别的(甚至是更好 ...

  3. ORACLE中RECORD、VARRAY、TABLE的使用详解(转)

    原文地址:ORACLE中RECORD.VARRAY.TABLE的使用详解

  4. ORACLE中RECORD、VARRAY、TABLE、IS REF CURSOR 的使用及实例详解

    ORACLE中RECORD.VARRAY.TAB.IS REF CURSOR LE的使用及实例详解 create or replaceprocedure PRO_RECORD_ROW_TAB_EXAM ...

  5. Bullet:关于ORACLE中的HASH JOIN的参数变化

    Oracle在7.3引入了hash join. 但是在Oracle 10g及其以后的Oracle数据库版本中,优化器,实际是CBO,也是因为HASH JOIN仅适用于CBO,在解析目标SQL时是否考虑 ...

  6. Oracle中使用Table()函数解决For循环中不写成 in (l_idlist)形式的问题

    转: Oracle中使用Table()函数解决For循环中不写成 in (l_idlist)形式的问题 在实际PL/SQL编程中,我们要对动态取出来的一组数据,进行For循环处理,其基本程序逻辑为: ...

  7. [转]Oracle中Hint深入理解

    原文地址:http://czmmiao.iteye.com/blog/1478465 Hint概述 基于代价的优化器是很聪明的,在绝大多数情况下它会选择正确的优化器,减轻了DBA的负担.但有时它也聪明 ...

  8. Oracle中Hint深入理解(原创)

    http://czmmiao.iteye.com/blog/1478465 Hint概述  基于代价的优化器是很聪明的,在绝大多数情况下它会选择正确的优化器,减轻了DBA的负担.但有时它也聪明反被聪明 ...

  9. Oracle中Hint深入理解

    Hint概述 基于代价的优化器是很聪明的,在绝大多数情况下它会选择正确的优化器,减轻了DBA的负担.但有时它也聪明反被聪明误,选择了很差的执行计划,使某个语句的执行变得奇慢无比. 此时就需要DBA进行 ...

随机推荐

  1. mysql 开发基础系列20 事务控制和锁定语句(上)

    一.概述 在mysql 里不同存储引擎有不同的锁,默认情况下,表锁和行锁都是自动获得的,不需要额外的命令, 有的情况下,用户需要明确地进行锁表或者进行事务的控制,以便确保整个事务的完整性.这样就需要使 ...

  2. 使用redis进行基于shiro的session集群共享

    之前写过一篇nginx多tomcat负载均衡,主要记录了使用nginx对多个tomcat 进行负载均衡,其实进行负载均衡之前还有一个问题没有解决,那就是集群间的session共享,不然用户在登录网站之 ...

  3. 关于JBoss7.X修改post传输数据量(max-post-size)的问题

    转自: https://blog.csdn.net/zhangyunhao108/article/details/53140569 JBoss7.X修改max-post-size在网上百度了好久,都不 ...

  4. Java设计模式学习记录-状态模式

    前言 状态模式是一种行为模式,用于解决系统中复杂的对象状态转换以及各个状态下的封装等问题.状态模式是将一个对象的状态从该对象中分离出来,封装到专门的状态类中,使得对象的状态可以灵活多变.这样在客户端使 ...

  5. Docker的基本操作与示例

    一.RunC RunC是一个由OCI(Open Container Initiative)制定的标准化轻量容器运行工具.OCI是专门致力于制定容器格式和运行时开放的工业化标准的组织.那容器标准化后Do ...

  6. SQL 注入漏洞

    首先要知道sql注入形成的原因:用户输入的数据被sql解释器执行 sql注入又分:数字型,字符型,cookie 注入,post注入,延时注入,搜索注入,base64注入 如何甄别一个模块是否有sql注 ...

  7. 向treeview中加载数据

    1.获取树节点的值,用事件AfterSelect加载(id值的获取,用name来获取) 2.双击treeview控件得到 private void treeView1_AfterSelect(obje ...

  8. spring_08aop原理及案例

    *参考优质文档: https://www.cnblogs.com/xrq730/p/4919025.html 一.简介 aop(Aspect Oriented Programming)是面向切面编程, ...

  9. 黑客常用 Linux 入侵常用命令

    大学曾误入歧途算是一个脚本小子.... 系统 # uname -a # 查看内核/操作系统/CPU信息 # head -n 1 /etc/issue # 查看操作系统版本 # cat /proc/cp ...

  10. Vue项目build打包部署到Tomcat后,刷新报404错误解决方案

    问题描述: 一.更新依赖,并打包项目 cd /root/.jenkins/workspace/v-test;npm installcd /root/.jenkins/workspace/v-test; ...