[20190322]测试相同语句遇到导致cursor pin S的疑问.txt
[20190322]测试相同语句遇到导致cursor pin S的疑问.txt
--//昨天测试遇到的情况,链接:http://blog.itpub.net/267265/viewspace-2638857/
--//我一直认为打散sql语句,避开cursor: pin S等待事件,能够提高执行效率.而测试结果有点出乎意料.
--//反而是测试2快于测试1,很难理解为什么会出现这样的情况,今天继续探究看看.
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 job_times (sid number, time_ela number,method varchar2(20));
$ cat m1.txt
set verify off
insert into job_times values ( sys_context ('userenv', 'sid') ,dbms_utility.get_time ,'&&2') ;
commit ;
declare
v_id number;
v_d date;
begin
for i in 1 .. &&1 loop
select /*+ &&3 */ 1 into v_id from dual ;
--select /*+ &&3 */ sysdate into v_d from dual ;
end loop;
end ;
/
update job_times set time_ela = dbms_utility.get_time - time_ela where sid=sys_context ('userenv', 'sid') and method='&&2';
commit;
quit
$ cat m2.txt
set verify off
insert into job_times values ( sys_context ('userenv', 'sid') ,dbms_utility.get_time ,'&&2') ;
commit ;
declare
v_id number;
v_d date;
begin
for i in 1 .. &&1 loop
select 1 into v_id from dual ;
--//select sysdate into v_d from dual ;
end loop;
end ;
/
update job_times set time_ela = dbms_utility.get_time - time_ela where sid=sys_context ('userenv', 'sid') and method='&&2';
commit;
quit
--//通过加入注解&&3,产生每个会话执行语句不同,对比看看.昨天的测试第2种情况快于第1种情况,不理解,我再次重复测试:
3.测试:
--//测试最好避开整点的awr生成以及其它对数据库的操作,
seq 1 40 | xargs -I {} echo 'seq {} | xargs -I %# -P {} bash -c "sqlplus -s -l scott/book @m1.txt 1e6 m1_{} %# >/dev/null"' | bash
seq 1 40 | xargs -I {} echo 'seq {} | xargs -I %# -P {} bash -c "sqlplus -s -l scott/book @m2.txt 1e6 m2_{} %# >/dev/null"' | bash
$ sqlplus -s -l scott/book <<< "select method,count(*),round(avg(TIME_ELA),0),sum(TIME_ELA) from job_times where method like 'm%' group by method order by to_number(substr(method,4)),4;" | egrep "^|m1_.*$"
METHOD COUNT(*) ROUND(AVG(TIME_ELA),0) SUM(TIME_ELA)
------ -------- ---------------------- -------------
m2_1 1 1802 1802
m1_1 1 1841 1841
m1_2 2 1677 3354
m2_2 2 1697 3393
m2_3 3 1660 4981
m1_3 3 1691 5074
m1_4 4 1672 6688
m2_4 4 1704 6816
m1_5 5 1588 7941
m2_5 5 1717 8586
m1_6 6 1584 9505
m2_6 6 1655 9931
m1_7 7 1595 11162
m2_7 7 1628 11395
m1_8 8 1599 12790
m2_8 8 1758 14067
m1_9 9 1600 14400
m2_9 9 1659 14935
m1_10 10 1595 15953
m2_10 10 1670 16701
m1_11 11 1584 17429
m2_11 11 1696 18653
m1_12 12 1586 19029
m2_12 12 1710 20519
m1_13 13 1683 21877
m2_13 13 1834 23844
m1_14 14 1757 24596
m2_14 14 1913 26777
m1_15 15 1832 27473
m2_15 15 2061 30919
m1_16 16 1913 30600
m2_16 16 2078 33247
m1_17 17 1975 33568
m2_17 17 2130 36203
m1_18 18 2057 37023
m2_18 18 2245 40418
m1_19 19 2131 40485
m2_19 19 2332 44301
m1_20 20 2246 44913
m2_20 20 2397 47932
m1_21 21 2318 48674
m2_21 21 2537 53285
m1_22 22 2430 53456
m2_22 22 2646 58218
m1_23 23 2538 58365
m2_23 23 2735 62906
m1_24 24 2664 63927
m2_24 24 2866 68789
m1_25 25 2795 69875
m2_25 25 2998 74952
m1_26 26 2835 73716
m2_26 26 3134 81489
m1_27 27 2967 80114
m2_27 27 3239 87444
m1_28 28 3088 86477
m2_28 28 3371 94391
m1_29 29 3172 91990
m2_29 29 3536 102550
m1_30 30 3303 99083
m2_30 30 3660 109802
m1_31 31 3377 104679
m2_31 31 3979 123359
m1_32 32 3560 113920
m2_32 32 4179 133740
m1_33 33 3608 119055
m2_33 33 4335 143050
m1_34 34 3732 126880
m2_34 34 4404 149722
m1_35 35 3760 131615
m2_35 35 4277 149679
m1_36 36 3948 142134
m2_36 36 4714 169701
m1_37 37 4098 151626
m2_37 37 4889 180908
m1_38 38 4066 154523
m2_38 38 5033 191253
m1_39 39 4153 161969
m2_39 39 5149 200827
m1_40 40 4394 175767
m2_40 40 5182 207291
80 rows selected.
--//大部分情况下都是测试1快于测试2.设置grep支持彩色.比较好观察.还有一种方法在vim下:set hls,查询/^m1.*$,这样也可以.
$ sqlplus -s -l scott/book <<< "select method,count(*),round(avg(TIME_ELA),0),sum(TIME_ELA) from job_times where method like 'm%' group by method order by to_number(substr(method,4)),4;" | egrep "^|m1_.*$"
--//也就是我前面的测试有问题??? 如果执行如下:
--//注:我注解select /*+ &&3 */ 1 into v_id from dual ;改为执行select /*+ &&3 */ sysdate into v_d from dual ;
seq 150 | xargs -I %# -P 150 bash -c "sqlplus -s -l scott/book @m1.txt 1e6 X1_150 %# >/dev/null"
seq 150 | xargs -I %# -P 150 bash -c "sqlplus -s -l scott/book @m2.txt 1e6 X2_150 %# >/dev/null"
SCOTT@book> select method,count(*),round(avg(TIME_ELA),0),sum(TIME_ELA) from job_times where method like 'X%' group by method order by to_number(substr(method,4)),3;
METHOD COUNT(*) ROUND(AVG(TIME_ELA),0) SUM(TIME_ELA)
-------------------- ---------- ---------------------- -------------
X2_150 150 19268 2890191
X1_150 150 19768 2965136
--//为什么呢?并发用户多了吗?我仔细想想,问题估计在开始阶段,测试1 150个连接开始执行大量的非绑定变量语句要硬解析,这样开始出现大量
--//latch: shared pool等待事件,而引起的这样的情况,如果开始脚本加入适当的延迟,测试才比较准确.修改脚本如下:
$ cat m1.txt
set verify off
insert into job_times values ( sys_context ('userenv', 'sid') ,dbms_utility.get_time ,'&&2') ;
commit ;
host sleep $(echo &&3/50 | bc -l )
declare
v_id number;
v_d date;
begin
for i in 1 .. &&1 loop
select /*+ &&3 */ 1 into v_id from dual ;
--select /*+ &&3 */ sysdate into v_d from dual ;
end loop;
end ;
/
update job_times set time_ela = dbms_utility.get_time - time_ela where sid=sys_context ('userenv', 'sid') and method='&&2';
commit;
quit
$ cat m2.txt
set verify off
insert into job_times values ( sys_context ('userenv', 'sid') ,dbms_utility.get_time ,'&&2') ;
commit ;
host sleep $(echo &&3/50| bc -l )
declare
v_id number;
v_d date;
begin
for i in 1 .. &&1 loop
select 1 into v_id from dual ;
--select sysdate into v_d from dual ;
end loop;
end ;
/
update job_times set time_ela = dbms_utility.get_time - time_ela where sid=sys_context ('userenv', 'sid') and method='&&2';
commit;
quit
$ seq 150 | xargs -I %# -P 150 bash -c "sqlplus -s -l scott/book @m1.txt 1e6 A1_150 %# >/dev/null"
$ seq 150 | xargs -I %# -P 150 bash -c "sqlplus -s -l scott/book @m2.txt 1e6 A2_150 %# >/dev/null"
--//实际上我在测试时还犯了一个严重错误,实际上到一定时间,看latch: shared pool的等待事件最后SECONDS_IN_WAIT是不变的,
--//实际上v$session记录的最后1个等待事件,非常容易存在疑惑.
SCOTT@book> @ wait
P1RAW P2RAW P3RAW P1 P2 P3 SID SERIAL# SEQ# EVENT STATUS STATE WAIT_TIME_MICRO SECONDS_IN_WAIT WAIT_CLASS
---------------- ---------------- ----- ---------- --- -- --- ------- ---- --------------------------- -------- ----------------- --------------- --------------- ------------
...
0000000062657100 0000000000000001 00 1650815232 1 0 333 95 28 SQL*Net message from client ACTIVE WAITED KNOWN TIME 305362 144 Idle
000000006010D860 0000000000000150 00 1611716704 336 0 6 145 30 latch: shared pool ACTIVE WAITED KNOWN TIME 34009 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 21 131 30 latch: shared pool ACTIVE WAITED KNOWN TIME 30997 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 67 115 31 latch: shared pool ACTIVE WAITED KNOWN TIME 31987 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 132 87 30 latch: shared pool ACTIVE WAITED SHORT TIME 17 141 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 170 719 31 latch: shared pool ACTIVE WAITED KNOWN TIME 33078 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 246 89 33 latch: shared pool ACTIVE WAITED KNOWN TIME 28119 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 320 57 30 latch: shared pool ACTIVE WAITED KNOWN TIME 35783 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 255 789 31 latch: shared pool ACTIVE WAITED KNOWN TIME 28109 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 257 157 33 latch: shared pool ACTIVE WAITED KNOWN TIME 34000 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 262 125 30 latch: shared pool ACTIVE WAITED KNOWN TIME 30084 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 284 111 30 latch: shared pool ACTIVE WAITED KNOWN TIME 26152 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 290 33 32 latch: shared pool ACTIVE WAITED KNOWN TIME 31020 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 298 403 30 latch: shared pool ACTIVE WAITED KNOWN TIME 35788 138 Concurrency
000000006010D860 0000000000000150 00 1611716704 336 0 247 121 30 latch: shared pool ACTIVE WAITED KNOWN TIME 32958 138 Concurrency
150 rows selected.
SCOTT@book> select method,count(*),round(avg(TIME_ELA),0),sum(TIME_ELA) from job_times where method like 'A%' group by method order by to_number(substr(method,4)),3;
METHOD COUNT(*) ROUND(AVG(TIME_ELA),0) SUM(TIME_ELA)
-------------------- ---------- ---------------------- -------------
A1_150 150 16718 2507696
A2_150 150 18234 2735046
--//这样测试1就快于测试2.
--//改成执行select sysdate into v_d from dual ;代码看看.
$ seq 150 | xargs -I %# -P 150 bash -c "sqlplus -s -l scott/book @m1.txt 1e6 B1_150 %# >/dev/null"
$ seq 150 | xargs -I %# -P 150 bash -c "sqlplus -s -l scott/book @m2.txt 1e6 B2_150 %# >/dev/null"
SCOTT@book> select method,count(*),round(avg(TIME_ELA),0),sum(TIME_ELA) from job_times group by method order by method;
METHOD COUNT(*) ROUND(AVG(TIME_ELA),0) SUM(TIME_ELA)
-------------------- ---------- ---------------------- -------------
A1_150 150 16718 2507696
A2_150 150 18234 2735046
B1_150 150 17613 2641914
B2_150 150 21185 3177713
--//你可以可以看出sql语句分散后大概提高10%上下.
--//另外我的测试还加入了sleep,
$ seq 150 | xargs | tr ' ' + | bc -l
11325
--//11325/50 = 226.5秒,排除这个因素.平均每个扣除226.5/150 = 1.51秒.哎!!脚本写的有问题,考虑欠缺,应该sleep在前面,再次重复测试:
--//从这次测试也看出,自己的测试设计不严谨,没有考虑一些细节问题,从另外一个方面也可以看出不使用绑定变量对数据库的危害,特别是oltp系统.
--//补充:
$ cat m1.txt
set verify off
host sleep $(echo &&3/50 | bc -l )
insert into job_times values ( sys_context ('userenv', 'sid') ,dbms_utility.get_time ,'&&2') ;
commit ;
declare
v_id number;
v_d date;
begin
for i in 1 .. &&1 loop
--select /*+ &&3 */ 1 into v_id from dual ;
select /*+ &&3 */ sysdate into v_d from dual ;
end loop;
end ;
/
update job_times set time_ela = dbms_utility.get_time - time_ela where sid=sys_context ('userenv', 'sid') and method='&&2';
commit;
quit
$ cat m2.txt
set verify off
host sleep $(echo &&3/50| bc -l )
insert into job_times values ( sys_context ('userenv', 'sid') ,dbms_utility.get_time ,'&&2') ;
commit ;
declare
v_id number;
v_d date;
begin
for i in 1 .. &&1 loop
--select 1 into v_id from dual ;
select sysdate into v_d from dual ;
end loop;
end ;
/
update job_times set time_ela = dbms_utility.get_time - time_ela where sid=sys_context ('userenv', 'sid') and method='&&2';
commit;
quit
$ seq 150 | xargs -I %# -P 150 bash -c "sqlplus -s -l scott/book @m1.txt 1e6 C1_150 %# >/dev/null"
$ seq 150 | xargs -I %# -P 150 bash -c "sqlplus -s -l scott/book @m2.txt 1e6 C2_150 %# >/dev/null"
SCOTT@book> select method,count(*),round(avg(TIME_ELA),0),sum(TIME_ELA) from job_times group by method order by method;
METHOD COUNT(*) ROUND(AVG(TIME_ELA),0) SUM(TIME_ELA)
-------------------- ---------- ---------------------- -------------
A1_150 150 16718 2507696
A2_150 150 18234 2735046
B1_150 150 17613 2641914
B2_150 150 21185 3177713
C1_150 150 16024 2403599
C2_150 150 21062 3159275
6 rows selected.
[20190322]测试相同语句遇到导致cursor pin S的疑问.txt的更多相关文章
- [20190320]测试相同语句遇到导致cursor pin S的情况.txt
[20190320]测试相同语句遇到导致cursor pin S的情况.txt --//前面测试链接:http://blog.itpub.net/267265/viewspace-2636342/-- ...
- oracle动态采样导致数据库出现大量cursor pin s wait on x等待
生产库中,突然出现了大量的cursor pin s wait on x等待,第一反应是数据库出现了硬解析,查看最近的DDL语句,没有发现DDL.那么有可能这个sql是第一次进入 在OLTP高并发下产生 ...
- cursor: pin S产生原理及解决方法
转自:http://www.dbafree.net/?p=778 今天晚上在一个比较重要的库上,CPU严重的冲了一下,导致DB响应变慢,大量应用连接timeout,紧接着LISTENER就挂了,连接数 ...
- library cache lock和cursor: pin S wait on X等待
1.现象: 客户10.2.0.4 RAC环境,出现大量的library cache lock和cursor: pin S wait on X等待,经分析是由于统计信息收集僵死导致的.数据库在8点到9点 ...
- cursor pin S wait on X
cursor pin S wait on X: 这是10.2版本提出的mutex(互斥)机制用来解决library cache bin latch争夺问题引入的新事件,是否使用这种机制受到隐含参数_k ...
- cursor: pin S
declare v_sql varchar2(200); begin loop v_sql :='select seq1.nextval from dual'; execute immediate v ...
- Resolving Issues of "Library Cache Pin" or "Cursor Pin S wait on X" (Doc ID 1476663.1)
Doc ID 1476663.1) To Bottom In this Document Purpose Troubleshooting Steps Brief Definition: ...
- cursor pin s和cursor pin s wait on x
1.cursor pin s是一个共享锁,一般情况下是因为发生在SQL短时间内大量执行 案例:在生产库中,突然出现大量的cursor pin s的等待,询问是否有动作后,同事说有编译存储过程(被误导了 ...
- sqlserver 测试sql语句执行时间
查看sql语句执行时间/测试sql语句性能 写程序的人,往往需要分析所写的SQL语句是否已经优化过了,服务器的响应时间有多快,这个时候就需要用到SQL的STATISTICS状态值来查看了. 通过设置S ...
随机推荐
- CentOS7.0小随笔——指令基本操作（Part.A）
与其说是CentOS7.0的小随笔,说老实话,基本指令在每个发行版本的Linux中都基本上是一致的. Part.A部分我们讲述以下四个方面:命令行界面与图形界面.Linux系统的关闭与重启.命令行帮助 ...
- MySQL批量插入数据的几种方法
最近公司要求测试数据库的性能,就上网查了一些批量插入数据的代码,发现有好几种不同的用法,插入同样数据的耗时也有区别 别的先不说,先上一段代码与君共享 方法一: package com.bigdata; ...
- Shell脚本-自动化部署WEB
#! /bin/ ] then echo "#### 参数有误,\$1:构建号必填" exit fi cd /root/workspace/xinya_erp/xinya_web ...
- thinkphp自动创建数据对象分析
thinkphp有一个自动创建数据对象的create方法,核心代码如下 public function create($data='',$type='') { // 如果没有传值默认取POST数据 i ...
- Android View 的事件分发原理解析
作为一名 Android 开发者,每天接触最多的就是 View 了.Android View 虽然不是四大组件,但其并不比四大组件的地位低.而 View 的核心知识点事件分发机制则是不少刚入门同学的拦 ...
- python安装第三方库的最简单方式
一.准备工作 (只做一次准备工作,以后都会很方便) 1. 安装pip (1)下载pip到D:\download pip下载地址:https://pypi.python.org/pypi/pip#dow ...
- React Fiber源码分析 第二篇（同步模式）
先附上两张流程图 1.scheduleRootUpdate 这个函数主要执行了两个操作 1个是创建更新createUpdate并放到更新队列enqueueUpdate, 1个是执行sheculeW ...
- 一个简单的Code First建立
1]从VS中建立一个mvc程序 记得添加NuGet包 然后在web.config中添加链接数据库的语句 <connectionStrings> <add name="Ent ...
- C#通过调用WinApi打印PDF文档类，服务器PDF打印、IIS PDF打印
其他网站下载来的类,可以用于Winform.Asp.Net,用于服务器端PDF或其他文件打印. 直接上代码: using System; using System.Collections.Generi ...
- Linux学习笔记之如何挂载数据盘
一.引入 双11在阿里云买了一台服务器(Linux操作系统,版本:CentOS7.04),配置就是20G的系统盘和40G的数据盘,可是问题来了,当系统初始化登录进去之后,输入:free -h命令并不能 ...