[20190423]那个更快的疑问3.txt

--//前一阵子,做了11g在单表单条记录唯一索引扫描的测试,摘要如下:
--//参考链接:
http://blog.itpub.net/267265/viewspace-2636321/
http://blog.itpub.net/267265/viewspace-2636342/

--//在链接中我解析唯一索引查询的情况，为什么10g快于11g，链接：http://blog.itpub.net/267265/viewspace-2639920/
--//差异在于10g很少做times的系统调用上.10g下仅仅116次.而11g高达200179.(getrusage与times调用次数比大约是7:2)
--//我当时的感觉10g漏写times系统函数调用，导致这样的情况，11g把它补上了。
--//实际上有网友提出疑问.我的测试下的结论有问题.当时测试的情况如下:
--//11g的测试:
$ strace -f -c sqlplus -s -l scott/book @m1.txt 1e5 id=1_unique_index 0 >/dev/null
...
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 72.78    0.043919           0    700708           getrusage
 19.80    0.011947           0    200179           times
  6.67    0.004024         671         6         3 wait4
  0.24    0.000147          29         5           clone
  0.18    0.000106           0       375         2 read
  0.16    0.000096           0       264       106 open
...
------ ----------- ----------- --------- --------- ----------------
100.00    0.060341                902967       206 total

--//1e5次执行times调用消耗0.011947秒,放大10倍(我每个session执行次数是1e6)也就是0.119470秒,什么可能产生这么大的差异.
--//仔细查看,我觉得strace跟踪记录的syscallsyscall.linux标准C函数.看不出oracle内部函数调用次数.
--//我当时的解析是这增加的times调用一定是11g版本唯一索引扫描中增加几个oracle内部函数调用,导致11g的唯一索引
--//扫描更慢,如何验证我当时确实不知道? 最近shared latch测试,建立一些gdb脚本,有了这些脚本可以latch获得释放的情况.

1.环境:
SCOTT@book> @ ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

2.建立测试脚本:

create table t as select rownum id from dual ;
create unique index pk_t on t(id);
alter table t modify id  not null ;
create table job_times (sid number, time_ela number,method var