latch: library cache 和latch: shared pool争用

asasjun

系统环境：Linux
数据库环境：Oracle 10.2.0.4 64 bit

不了峰

第一次 看到 表和字段名都是中文的数据库 ：）

感觉这个数据库有进行一定的优化过 ：）

压缩一下，还盼刘大给个回复  

不了峰

感觉这是一个已经被调优过的数据库，
楼主能否补充一下一些信息，比如这个是系统是什么样类型的，主要这个时段会做些什么业务，是否会用到临时表等。

个人分析如下：

1. 众所周知这个系统问题出在latch: library cache和latch: shared pool 争用上，占系统总体等待时间的比例30%。
   每次等待时长 高达577ms。平均每个实务等待这些闩锁的次数有0.23个。换句话说 ，在一个实务中，仅仅等待library cache和shared pool闩锁就超过了577毫秒。

2. 系统有一定量的硬解析，每秒12.41个，从Parse CPU to Parse Elapsd %:=21.37％来看，解析时大量时间花费在等待上，也就是可能在等待上面提到的两个等待事件。

3.从Dictionary Cache Stats 可以看到 有一定的直方图字典缓存的争用 dc_histogram_data,dc_histogram_defs

处理建议：
1. 找出硬解析的sql ,处理硬解析，处理直方图的争用的情况
  2. 发现optimizer_mode=choose ，不知道为何进行修改。--当然是否要修改为别的，我没有什么建议。

3.个人认为最主要的问题出在 shared_pool_SIZE 不足，或者说不够大引起的。
   
  一方面：由于这个系统没有配置了sga的自动管理，而是手动管理，将shared_pool设为6G,db_cache设为18G，而sga_max_size=36G. 所以我们看不到oracle中的shared_pool_size扩缩的现象。

    评估Operating System Statistics中NUM_CPUS，load ,idle time，发现该系统的cpu还是有足够的空闲。

所以个人建议，加大shared_pool到12G，来看看。-->也许不用加这么大，那就少加一点先试试看

评估一下，每秒的事务是否会有一个上升。

              

miloluo

建议调查sql fph0g42bf3ax4。

wengtf

医院的his系统，中文看得出来

card_2005

1.从AWR上看解析问题比较严重，软解析比例高，硬解析也高，软解析高可能跟使用中文的表和列有关
2.从整个系统信息命名、参数调整上看感觉部署时规划的比较好。
  optimizer_index_cost_adj optimizer_index_caching optimizer_mode都是重新定义过的
  同意不了峰增加SHARED_POOL大小，另外open_cursor、 session_chache_cursor应该加大
3.还有就是硬解析的问题，我感觉这个库可能是一套混合类型的库，OLTP和OLAP都有
这样的库让复杂的查询少的大SQL不使用绑定变量，执行次数多的使用绑定变量
没有正确使用绑定变量的SQL应该还有找出来处理掉，改不了代码就只能调cursor_sharing了

digdeep

cpu_count多大？

harryzhang

session_chache_cursor 是50么？