[20190320]测试相同语句遇到导致cursor pin S的情况.txt

--//前面测试链接:http://blog.itpub.net/267265/viewspace-2636342/
--//各个会话执行语句相同的,很容易出现cursor: pin S等待事件.看看如果各个会话执行的语句不同.
--//测试结果如何呢?

-//后记:补充说明测试不严谨,请参考链接:http://blog.itpub.net/267265/viewspace-2639097/

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 mutex.sql
set verify off
insert into job_times values ( sys_context ('userenv', 'sid') ,dbms_utility.get_time ,'&&2') ;
declare
v_id number;
v_d date;
begin
    for i in 1 .. &&1 loop
        select /*+ &&3 */ sysdate from into v_date dual;
        --select  sysdate from into v_date 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 mutex1.sql
set verify off
insert into job_times values ( sys_context ('userenv', 'sid') ,dbms_utility.get_time ,'&&2') ;
declare
v_id number;
v_d date;
begin
    for i in 1 .. &&1 loop
        --select /*+ &&3 */ sysdate from into v_date dual;
        select  sysdate from into v_date 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,产生每个会话执行语句不同,对比看看.

3.测试:
exec dbms_workload_repository.create_snapshot();
host seq 150 | xargs -I{} -P 150 bash -c  "sqlplus -s -l scott/book @mutex.sql  1e6 test1 {} >/dev/null"
exec dbms_workload_repository.create_snapshot();
host seq 150 | xargs -I{} -P 150 bash -c  "sqlplus -s -l scott/book @mutex1.sql 1e6 test2 {} >/dev/null"
exec dbms_workload_repository.create_snapshot();

--//测试1,执行时等待事件集中在latch: shared pool.
--//测试2,执行时等待事件集中在cursor: pin S.

SCOTT@book> select method,count(*),round(avg(TIME_ELA),0),sum(TIME_ELA) from job_times group by method order by 3 ;
METHOD                 COUNT(*) ROUND(AVG(TIME_ELA),0) SUM(TIME_ELA)
-------------------- ---------- ---------------------- -------------
test1                       150                  19897       2984502
test2                       150                  19380       2907006

--//奇怪的是,测试实际上测试1反而慢一点.从这个测试可以看出,如果如果应用真有大量语句出现cursor争用,通过打散语句的执行,
--//可能未必能提高执行效率.

--//test1的awr报表:
              Snap Id      Snap Time      Sessions Curs/Sess
            --------- ------------------- -------- ---------
Begin Snap:      1681 20-Mar-19 09:53:01        27       1.2
  End Snap:      1682 20-Mar-19 09:56:23        28       1.2
   Elapsed:                3.37 (mins)
   DB Time:              497.85 (mins)

...
Top 10 Foreground Events by Total Wait Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                            Tota    Wait   % DB           
Event                                 Waits Time Avg(ms)   time Wait Class
------------------------------ ------------ ---- ------- ------ ----------
latch: shared pool                  233,755 18.6      79   62.2 Concurrenc
DB CPU                                      4751           15.9           
library cache: mutex X                  828 13.7      17     .0 Concurrenc
cursor: pin S wait on X                  68  1.4      20     .0 Concurrenc
library cache load lock                  94  1.1      12     .0 Concurrenc
log file sync                           141   .5       4     .0 Commit    
wait list latch free                     50   .3       6     .0 Other     
enq: SQ - contention                      2    0      10     .0 Configurat
library cache lock                        2    0       8     .0 Concurrenc
SQL*Net message to client             2,560    0       0     .0 Network

--//出现了latch: shared pool大量争用.反而测试2使用mutex的效率更高.

--//test2的awr报表:
             Snap Id      Snap Time      Sessions Curs/Sess
            --------- ------------------- -------- ---------
Begin Snap:      1682 20-Mar-19 09:56:23        28       1.2
  End Snap:      1683 20-Mar-19 09:59:40        28       1.2
   Elapsed:                3.28 (mins)
   DB Time:              484.76 (mins)

...
Top 10 Foreground Events by Total Wait Time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                            Tota    Wait   % DB           
Event                                 Waits Time Avg(ms)   time Wait Class
------------------------------ ------------ ---- ------- ------ ----------
cursor: pin S                       585,684 12.1      21   41.6 Concurrenc
DB CPU                                      4611           15.9           
library cache: mutex X                  525  8.6      16     .0 Concurrenc
latch: shared pool                      117  1.5      13     .0 Concurrenc
latch free                               45  1.3      28     .0 Other     
log file sync                           129   .5       4     .0 Commit    
cursor: pin S wait on X                  44   .4       9     .0 Concurrenc
library cache load lock                  57   .3       6     .0 Concurrenc
row cache lock                           18   .2      10     .0 Concurrenc
enq: SQ - contention                      3    0      11     .0 Configurat

--//对比测试2的cursor: pin S使用12.1秒.而测试1的latch: shared pool使用18.6秒,差距并不大.
--//可以看出使用oracle使用mutex效率更高.

--//另外从一个侧面说明,如果应用大量重复语句执行出现cursor: pin S争用,通过分散的方式也许更加并不是最佳的.
--//减少语句的执行次数才是比较正确的处理问题方式,或者找到为什么执行次数这么高的原因.

--//我又重复测试1次.test1修改testa,test2修改testb.

SCOTT@book> select method,count(*),round(avg(TIME_ELA),0),sum(TIME_ELA) from job_times group by method order by 3 ;
METHOD                 COUNT(*) ROUND(AVG(TIME_ELA),0) SUM(TIME_ELA)
-------------------- ---------- ---------------------- -------------
test2                       150                  19380       2907006
testb                       150                  19648       2947223
testa                       150                  19884       2982666
test1                       150                  19897       2984502

--//结论依旧.
--//如果减少测试用户连接数量呢?测试并发用户50的情况:
$ cat aa3.txt
exec dbms_workload_repository.create_snapshot();
host seq 50 | xargs -I{} -P 50 bash -c  "sqlplus -s -l scott/book @mutex.sql  1e6 test50a {} >/dev/null"
exec dbms_workload_repository.create_snapshot();
host seq 50 | xargs -I{} -P 50 bash -c  "sqlplus -s -l scott/book @mutex1.sql 1e6 test50b {} >/dev/null"
exec dbms_workload_repository.create_snapshot();

SCOTT@book> select method,count(*),round(avg(TIME_ELA),0),sum(TIME_ELA) from job_times group by method order by 3 ;
METHOD                 COUNT(*) ROUND(AVG(TIME_ELA),0) SUM(TIME_ELA)
-------------------- ---------- ---------------------- -------------
test50b                      50                   6437        321825
test50a                      50                   6791        339554
test2                       150                  19380       2907006
testb                       150                  19648       2947223
testa                       150                  19884       2982666
test1                       150                  19897       2984502
6 rows selected.

--//你可以发现在并发用户50的情况下,情况不变,结论依旧.改成并发用户10的情况呢?
--//还可以发现现在同样的工作量,50个并发的情况下,6X秒就可以完成.

SCOTT@book> select method,count(*),round(avg(TIME_ELA),0),sum(TIME_ELA) from job_times group by method order by 3 ;
METHOD                 COUNT(*) ROUND(AVG(TIME_ELA),0) SUM(TIME_ELA)
-------------------- ---------- ---------------------- -------------
testi10b                     10                   1872         18724
testi10a                     10                   2003         20028
test50b                      50                   6437        321825
test50a                      50                   6791        339554
test2                       150                  19380       2907006
testb                       150                  19648       2947223
testa                       150                  19884       2982666
test1                       150                  19897       2984502
8 rows selected.

--//有点奇怪为什么测试1会出现大量的latch: shared pool.
--//这个测试有点像按下葫芦起了瓢,也说明任何问题都给辩证的看.

总结:
--//在测试前我一直以为测试1会块一些,实际情况正好相反.
--//不过为什么这样,我还不是很清楚....

[20190320]测试相同语句遇到导致cursor pin S的情况.txt的更多相关文章

  1. [20190322]测试相同语句遇到导致cursor pin S的疑问.txt

    [20190322]测试相同语句遇到导致cursor pin S的疑问.txt--//昨天测试遇到的情况,链接:http://blog.itpub.net/267265/viewspace-26388 ...

  2. oracle动态采样导致数据库出现大量cursor pin s wait on x等待

    生产库中,突然出现了大量的cursor pin s wait on x等待,第一反应是数据库出现了硬解析,查看最近的DDL语句,没有发现DDL.那么有可能这个sql是第一次进入 在OLTP高并发下产生 ...

  3. cursor: pin S产生原理及解决方法

    转自:http://www.dbafree.net/?p=778 今天晚上在一个比较重要的库上,CPU严重的冲了一下,导致DB响应变慢,大量应用连接timeout,紧接着LISTENER就挂了,连接数 ...

  4. 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点 ...

  5. cursor pin S wait on X

    cursor pin S wait on X: 这是10.2版本提出的mutex(互斥)机制用来解决library cache bin latch争夺问题引入的新事件,是否使用这种机制受到隐含参数_k ...

  6. cursor: pin S

    declare v_sql varchar2(200); begin loop v_sql :='select seq1.nextval from dual'; execute immediate v ...

  7. 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:   ...

  8. cursor pin s和cursor pin s wait on x

    1.cursor pin s是一个共享锁,一般情况下是因为发生在SQL短时间内大量执行 案例:在生产库中,突然出现大量的cursor pin s的等待,询问是否有动作后,同事说有编译存储过程(被误导了 ...

  9. sqlserver 测试sql语句执行时间

    查看sql语句执行时间/测试sql语句性能 写程序的人,往往需要分析所写的SQL语句是否已经优化过了,服务器的响应时间有多快,这个时候就需要用到SQL的STATISTICS状态值来查看了. 通过设置S ...

随机推荐

  1. [android学习]__使用百度地图开放api编写地图定位app

    前言 在前面我已经记录关于如何使用百度地图api,以及如何配置相关的androidstudio配置了,接下来将记录如何使用百度地图api开发简单的地图定位apk,我将决定不定期持续更新本篇笔记,在每个 ...

  2. 增加Myecllipse内存

    1.打开MyEclipse后,进入Windows/Preferences/Java/Installed JREs 点击后,在右边窗口选择JREs,双击后进入 2.在Default VM Argumen ...

  3. 【转载】uCOS系统的思考

    一:  世界潮流,浩浩汤汤,顺之者昌,逆之者亡---孙中山 从80X86到ARM9,再从ARM9到ARM7,平台是越做越简单,但是简单并不是意味着退步,反而是种潮流趋势... 在CISC道路上渐行渐远 ...

  4. JVM中垃圾收集算法总结

      通过前面的介绍我们了解了对象创建和销毁的过程.那么JVM中垃圾收集器具体对对象回收采用的是什么算法呢?本文主要记录下JVM中垃圾收集的几种算法. JVM的垃圾回收的算法 标记-清除算法(Mark- ...

  5. Raft 基础

    目录 三个状态 什么是任期 节点之间的通信 1. 三个状态 Raft 设计了 3 个状态,用于表示节点的状态,分别是跟随者,候选者,领导者. 领导者:通常只有一个领导人,并且其他节点都是跟随者. 跟随 ...

  6. Linux命令-用户及权限管理

    一.权限管理linux系统中对文件权限的描述机制: u g od r w x r w x r - x (r读,w写,x执行)文件 所有者 所属组 其他人可以表示为二进制: 111 111 101也可以 ...

  7. 18.Class 的基本语法

    Class 的基本语法 Class 的基本语法 简介 JavaScript 语言中,生成实例对象的传统方法是通过构造函数.下面是一个例子. function Point(x, y) { this.x ...

  8. [转]docker之Dockerfile实践

    本文转自:https://www.cnblogs.com/jsonhc/p/7767669.html 上一篇介绍了Dockerfile中使用的指令,现在开始进行指令实践 先查看下本地的镜像,选一个作为 ...

  9. 第一册:lesson seventy five。

    原文: Uncomfortable Shoes. Do you have any shoes like this? What size? Size five. What color? Black. I ...

  10. 结构型---享元模式(Flyweight Pattern)

    引言 在软件开发过程,如果我们需要重复使用某个对象的时候,如果我们重复地使用new创建这个对象的话,这样我们在内存就需要多次地去申请内存空间了,这样可能会出现内存使用越来越多的情况,这样的问题是非常严 ...