Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2669313
  • 博文数量: 570
  • 博客积分: 1860
  • 博客等级: 上尉
  • 技术积分: 6259
  • 用 户 组: 普通用户
  • 注册时间: 2008-04-07 08:51
个人简介

偶尔有空上来看看

文章分类

全部博文(570)

文章存档

2022年(63)

2021年(238)

2020年(115)

2019年(11)

2018年(9)

2017年(9)

2016年(17)

2015年(7)

2014年(4)

2013年(1)

2012年(11)

2011年(27)

2010年(35)

2009年(11)

2008年(11)

分类: Oracle

2021-12-27 16:57:12


缺少 cursor: pin S wait on X 等待事件的诊断,说明优化生涯是不完整的。

原理:
游标等待与某种形式的解析相关联。当一个会话试图在共享模式下获取互斥锁时,但另一个会话在同一个光标对象上独占持有互斥锁,它可能会等待此事件。通常,这个等待事件是一种症状,而不是原因。

首先检查共享池大小是否正确
其次看是否频繁的硬解析
然后看高版本计数是否高
最后排除掉BUG外,要看是否有解析错误情况,即ORA-923

  1. 共享池大小
  2. col name for a40
  3. set pages 100
  4. select name,round(bytes/1024/1024)size_mb from v$sgainfo;

  5. 内存抖动

  6.  SELECT COMPONENT,
  7.        OPER_TYPE,
  8.        round(a.INITIAL_SIZE/1024/1024) initial_size_mb,
  9.        round(FINAL_SIZE/1024/1024) FINAL_SIZE_mb,
  10.        round((FINAL_SIZE-INITIAL_SIZE)/1024/1024) resize_mb,
  11.        to_char(start_time, 'yyyy-mm-dd hh24:mi:ss') Started_time,
  12.        to_char(end_time, 'yyyy-mm-dd hh24:mi:ss') end_time
  13.   FROM V$SGA_RESIZE_OPS a
  14.  where start_time >= to_date('2021-12-20 00:00', 'yyyy-mm-dd hh24:mi')
  15.  and start_time <= to_date('2021-12-23 23:59', 'yyyy-mm-dd hh24:mi')
  16.   order by Started_time;

  17. 查找引起此事件的会话
  18. select sid,serial#,SQL_ID,BLOCKING_SESSION,BLOCKING_SESSION_STATUS,EVENT
  19.      from v$session where event ='cursor: pin S wait on X';

  20. 相关sql
  21. SELECT s.sid, t.sql_text
  22. FROM v$session s, v$sql t
  23. WHERE s.event LIKE '%cursor: pin S wait on X%'
  24. AND t.sql_id = s.sql_id

  25. How to Determine the Blocking Session for Event: 'cursor: pin S wait on X' (Doc ID 786507.1)
awr中看这里



如果硬解析高,这可能表明文字使用率高或引入了许多新的SQL。在这种情况下,
请考虑使用绑定变量代替文字。 
如果软解析的百分比很高,则检查应用程序以查看它是否正在使用可共享的 SQL。 
理想情况下,Execute to Parese 应该接近 100%

还有





高版本诊断请看 blog.chinaunix.net/uid-20687159-id-5853384.html

进一步深入诊断

  1. 单机
  2. $ sqlplus "/ as sysdba"

  3. oradebug setmypid
  4. oradebug unlimit
  5. oradebug dump systemstate 258
  6. wait 90 seconds
  7. oradebug dump systemstate 258
  8. wait 90 seconds
  9. oradebug dump systemstate 258
  10. quit

  11. RAC
  12. $ sqlplus "/ as sysdba"

  13. oradebug setmypid
  14. oradebug unlimit
  15. oradebug setinst all
  16. oradebug -g all hanganalyze 4
  17. oradebug -g all dump systemstate 258
  18. quit

  19. 获取error stack
  20. $ sqlplus "/ as sysdba"
  21.  
  22. SQL> oradebug setospid <p.spid from above>
  23. oradebug dump errorstack 3
  24. << wait 1min>>
  25. oradebug dump errorstack 3
  26. << wait 1min>>
  27. oradebug dump errorstack 3
  28. exit

如果遇到解析错误,即大量ORA-923,可以诊断一下

  1. ALTER SYSTEM SET EVENTS '10035 trace name context forever, level 1';
  2. 等应用重复
  3. ALTER SYSTEM SET EVENTS '10035 trace name context off';
好像19c数据库的告警日志中不设置此事件就有错误的sql。

剑走偏锋,获取大量硬解析的方法:


  1. select INSTANCE_NUMBER,TOP_LEVEL_SQL_ID,SQL_ID,count(*) from dba_hist_active_sess_history
  2. where IN_HARD_PARSE='Y' group by INSTANCE_NUMBER,TOP_LEVEL_SQL_ID,SQL_ID
  3. having count(*)>100 order by count(*) desc;


应该找到原因了吧?
阅读(194) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~