Library Hit & Parse CPU to Parse

Tim

最近每天上午都会出现服务器CPU和硬盘 100%的情况，非RAC，IBM Power 小型机，AWR如下：
zjdbawr.rar (37.25 KB, 下载次数: 841)

2013-6-13 11:23 上传

点击文件名下载附件

请高人指点有啥优化建议。

psufnxk2000

硬解析 。  tx行锁。。。

lunar

几个问题：
1，Hard parses:         108.51  硬分析很高……使用绑定变量（过渡方案，cursor_sharing=force，测试后使用）
2，enq: TX - row lock contention，tuning top sql，语句中的where。。。1=1，貌似工具生成的这类sql效率很差，需要tuning（或者调整索引，分区等等，具体要看执行计划）
3，这个RAC的sequence需要增加cache
4，INDEX_ONLYCODE_319 需要增加inittrans 比如 30
5，整体感觉系统的索引和语句需要调整，另外考虑optimizer_index_cost_adj和optimizer_index_caching，修改并测试

anbob

1.         Per Second        Per Transaction
   
2. Redo size:         153,028.97         18,820.51
   
3. Logical reads:         305,717.73         37,599.17
   
4. Block changes:         1,044.30         128.43
   
5. Physical reads:         1,918.40         235.94

复制代码

Block changes 挺多的，update 语句注意一下绑定变量。

digdeep

1)硬解析太多 Hard parses:        108.51 ，进行绑定变量。导致shared pool使用率很低：
Memory Usage %:        34.32        34.85
SQL AREA         20,863,687         63.39         39,068,923         43.81         417,868         22,281
2）执行解析比几乎为1:1，提供session_cached_cursors的值试试。
3）enq: TX - row lock contention 主要是RM_USER_ONLINE_RECORD 和 RM_USER       
4）enq: TM - contention
5）
Owner        Tablespace Name        Object Name        Subobject Name        Obj. Type        Buffer Busy Waits        % of Capture
SYS         SYSTEM         SEQ$                   TABLE         736         33.72

harryzhang

07:00-22:00 时间跨度貌似有点长，既然你说“最近每天上午都会出现服务器CPU和硬盘 100%的情况”，那就抓上午的吧。