一个高hard pase的awr

leonhat

db03-2013040910-11.html (6.49 MB, 下载次数: 966)

2013-4-10 15:36 上传

点击文件名下载附件

请各位抽空帮忙看看，谢谢

leonhat

再发一个，另一个节点的awr，这是个双节点的rac

db04-2013040910-11.rar (214.83 KB, 下载次数: 1105)

2013-4-10 16:49 上传

点击文件名下载附件

dla001

给这个问题补一下处理方法：
方法参考以下的链接，请仔细看链接中的内容并参考上面的awr。
https://blogs.oracle.com/askmaclean/entry/java_jdbc%E5%87%8F%E5%B0%91%E4%BA%A4%E4%BA%92%E6%8F%90%E5%8D%87%E6%89%B9%E9%87%8F%E5%A4%84%E7%90%86%E6%80%A7%E8%83%BD_%E5%88%B0%E5%BA%95%E8%AF%A5%E5%A6%82%E4%BD%95%E4%BC%98%E5%8C%96%E6%89%8D%E5%A5%BD

xychong123

oracle oracle

不了峰

dla001 发表于 2013-4-11 11:02
给这个问题补一下处理方法：
方法参考以下的链接，请仔细看链接中的内容并参考上面的awr。
https://blogs.o ...

一语中的呀，

真的是没有看过这种sql ，怪不得awr报告 这么大

leonhat

谢谢各位，基本定位为两个问题：
主要问题：硬解析过多
解决：从应用角度优化庞大的insert

次要问题：sql
一个统计语句占用了最多的cpu时间
解决还是优化它。

digdeep

另外，buffer cache不是不小了点，系统有90G内存