请砖家讨论下这个AWR报告

luchen1106

1.初步我看应该是硬解析太高了
2.failed parse elapsed time这个指标异常的高，为什么会出现失败解析，数据库日志里面没有任何ORA-4030 4031错误

flg_inwind

关注下人工操作失败的情况或者应用报错的情况

lfree

你有sql语句写错了.

lfree

自己定位library cache lock:
http://blog.itpub.net/267265/viewspace-2058652/

luchen1106

lfree 发表于 2016-6-23 09:21
你有sql语句写错了.

这个能通过awr，或者什么oracle脚本监控到吗？
通过v$active_session_history,找到一个可疑的sql_id,但是这个sql_id在内存里面找不到，怀疑就是失败的解析sql语句是不会保存的

luchen1106

lfree 发表于 2016-6-23 09:24
自己定位library cache lock:
http://blog.itpub.net/267265/viewspace-2058652/

本案的lock，应该和硬解析  和  失败解析 关系很大，其中硬解析部分好分析，对应的硬解析sql也好找出来
只是这个failed parse不知如何分析啊。
Time Mode Statistics中faided parse time占了80%

lfree

luchen1106 发表于 2016-6-23 09:32
这个能通过awr，或者什么oracle脚本监控到吗？
通过v$active_session_history,找到一个可疑的sql_id,但是 ...

这个是看不到的,相当于你写错,或者即使没有错误.但是表不存在一样有问题.

例如select * from scott.xxxxxxxxxxx;


http://blog.itpub.net/267265/viewspace-1760158/

lfree

SELECT distinct kglnaobj c100 from x$kglob where  kglobt03 = 'c21vhszr9gbdq';
基本可以查询到.

lfree

另外sql语法错误,大量执行也会导致library cache lock/library cache:mutex X
http://www.htz.pw/2014/09/07/sql ... y-cachemutex-x.html

lfree

        python@s1jibvorcl013 (TNS V1-V3)

运行的检测脚本视乎是你们自己写的检测脚本吗?

SELECT df.tablespace_name TABLESPACE, ROUND((df.bytes - SUM(fs.bytes)) * 100 / df.bytes, 2) USED
  FROM (
                SELECT TABLESPACE_NAME, BYTES
                  FROM sys.sm$ts_free fs
                 UNION ALL
                SELECT TABLESPACE_NAME, FREE_SPACE
  FROM DBA_TEMP_FREE_SPACE) FS, (
                SELECT tablespace_name, SUM(bytes) bytes
                  FROM sys.sm$ts_avail
                 GROUP BY tablespace_name
                 UNION ALL
                SELECT TABLESPACE_NAME, SUM(bytes)
                  FROM SYS.DBA_TEMP_FILES
GROUP BY tablespace_name) df
WHERE fs.tablespace_name(+) = df.tablespace_name
   AND df.tablespace_name    = 'UNDOTBS1'
GROUP BY df.tablespace_name, df.bytes
ORDER BY 1

--好像这个是某个厂家开发的监控数据库的脚本..