一次等待事件和绑定变量的解决和软软解析

上传人:漫步人****me 文档编号:61661881 上传时间:2018-12-09 格式:DOCX 页数:16 大小:130.46KB
返回 下载 相关 举报
一次等待事件和绑定变量的解决和软软解析_第1页
第1页 / 共16页
一次等待事件和绑定变量的解决和软软解析_第2页
第2页 / 共16页
一次等待事件和绑定变量的解决和软软解析_第3页
第3页 / 共16页
一次等待事件和绑定变量的解决和软软解析_第4页
第4页 / 共16页
一次等待事件和绑定变量的解决和软软解析_第5页
第5页 / 共16页
点击查看更多>>
资源描述

《一次等待事件和绑定变量的解决和软软解析》由会员分享,可在线阅读,更多相关《一次等待事件和绑定变量的解决和软软解析(16页珍藏版)》请在金锄头文库上搜索。

1、等待事件和绑定变量的解决怎么才知道以及绑定了变量:查看v$sql或者v$sqlarea找出连续执行的sql,看看变量前面是否都有:variable_name,有的话代表sql语句一样是绑定了变量的。1:现象一个procedure运行很久,数据库繁忙的时候一直运行超过一个小时都不完成。查看视图有一个latch的等待事件很长,很多次。2:发现和解决步骤:select sid,P1TEXT,P1,P2,P3 ,STATE,SECONDS_IN_WAIT ,MACHINE from v$session t1 where t1.MACHINE = WORKGROUPALUN-PC;-王友伦的机器查看有多

2、少个session在运行。一共:32,236,759三个SQL select sid,event,p1,p1raw from v$session_wait t1 where t1.sid in(32,236,759) and wait_time=0;-看正在等待或者上一次等待的时间。wait_time=0表示正在等待。 SID EVENT P1 P1RAW- - - - 32 SQL*Net message from client 1413697536 0000000054435000 236 SQL*Net message from client 1413697536 00000000544

3、35000 759 latch: shared pool 1611696112 00000000601087F0 .这个视图解释:V$SESSION_WAIT中的常用列l SID: session标识l EVENT: session当前等待的事件,或者最后一次等待事件。l WAIT_TIME: session等待事件的时间(单位,百分之一秒)如果本列为0,说明session当前session还未有任何等待。l SEQ#: session等待事件将触发其值自增长l P1, P2, P3: 等待事件中等待的详细资料l P1TEXT, P2TEXT, P3TEXT: 解释说明p1,p2,p3事件 附

4、注:1.State字段有四种含义(1)Waiting:SESSION正等待这个事件。 (2)Waited unknown time:由于设置了timed_statistics值为false,导致不能得到时间信息。表示发生了等待,但时间很短。 (3)Wait short time:表示发生了等待,但由于时间非常短不超过一个时间单位,所以没有记录。 (4)Waited knnow time:如果session等待然后得到了所需资源,那么将从waiting进入本状态。2.Wait_time值也有四种含义: (1)值0:最后一次等待时间(单位:10ms),当前未在等待状态。 (2)值=0:sessio

5、n正在等待当前的事件。 (3)值=-1:最后一次等待时间小于1个统计单位,当前未在等待状态。 (4)值=-2:时间统计状态未置为可用,当前未在等待状态。3.Wait_time和Second_in_wait字段值与state相关: (1)如果state值为Waiting,那么wait_time值无用。Second_in_wait值是实际的等待时间(单位:秒)。 (2)如果state值为Wait unknow time,那么wait_time值和Second_in_wait值都无用。 (3)如果state值为Wait short time,那么wait_time值和Second_in_wait值都

6、无用。 (4)如果state值为Waiting known time,那么wait_time值就是实际等待时间(单位:秒),Second_in_wait值无用。.这个等待latch解释:shared pool latch相关描述The shared pool latch is used to protect critical operations when allocating and freeing memory in the shared pool. If an application makes use of literal (unshared) SQL then this can se

7、verely limit scalability and throughput. The cost of parsing a new SQL statement is expensive both in terms of CPU requirements and the number of times the library cache and shared pool latches may need to be acquired and released. Before Oracle9, there was just one such latch for the entire databas

8、e to protect the allocation of memory in the library cache. In Oracle9, multiple children were introduced to relievecontention on this resource. 减少shared pool latch方法Avoid hard parses when possible, parse once, execute many. Eliminate literal SQL so that same sql is shared by many sessions.Size the

9、shared_pool adequately to avoid reloadsUse of MTS (shared server option) also greatly influences the shared pool latch. .SQL select * from v$session_event t1 where t1.sid in(32,236,759) order by TOTAL_WAITS desc;-看总共等待次数和等待时间。 SID EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED AVERAGE_WAIT MAX_WAIT TI

10、ME_WAITED_MICRO EVENT_ID WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS- - - - - - - - - - - - 759 latch: shared pool 520 0 370 0.71 32 3702606 2696347763 3875070507 4 Concurrency 236 SQL*Net message to client 94 0 0 0 0 85 2067390145 2000153315 7 NetworkSQL select addr,latch#,name,gets,spin_gets from v$latch order by wait_time desc ;-查看latch等待的排名顺序,等待次数或者等待时间来排序。 ADDR LATCH# NAME GETS SPIN_GETS- - - - -0000000060036A08 307 shared pool 238934711 7599700000000600331E8 280 row cache objects

展开阅读全文
相关资源
相关搜索

当前位置:首页 > IT计算机/网络 > 数据库

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号