硬解析和软解析

  
1.硬解析和软解析（如果硬分析率每秒大于100，则认为硬分析过多）p932
 分析软硬解析的方法有几种？
1. sql trace, tkprof查看分析信息
alter session set SQL_TRACE=TRUE;
为保证以前没有任何的查询被分析，刷新共享池（思考一下我们都在什么情况下刷新共享池）
alter system flush share_pool;
在trace 文件中mis=1指出这是一个硬分析，因为这条语句未在库高速缓存中给出
在tkprof中查看某条语句分析时，如何未命中会得到：
Misses in library cache during parse:1
2. 度量库高速缓存的效率
利用简单的比例来判断库高速缓存的尺寸设置是否正确:
V$LIBRARYCACHE
select sum(pinhits)/sum(pin) library_cache_hit_ratio from v$librarycache;
如何命中率在99%，说明我们的命中率很好。但我们不能过分看重库高速缓存和缓冲区高速缓存的命中率。
因为即使命中率高达99.9%，但如果由诸如过度分析这样的事件导致大量等待， 数据库的速度也会很慢。
应该密切关注系统的等待事件，不要盲目的依赖命中率。
3. 确定库高速缓存的效率
select namespace,pins,pinhits,reloads from v$LIBRARYCACHE ORDER by namespace;
如果reload列显示较大的值，则表示许多SQL语句在老化退出后有被重新载入。这时我们可能想增大共享池，
但如果应用很大，执行的数目很大，或应用不使用绑定变量，则这样也解决不了问题。
oracle提供的DBMS_SHARED_POOL程序强迫可执行的SQL语句保留在共享池的库高速缓存中，这个程序包包括有KEEP和UNKEEP过程。
using DBMS_SHARED_POOL
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_shpool.htm#i996754
V$LIBRARY_CACHE_MEMORY来确定共享池中当前正在使用的库高速缓存内存对象的数目，以及空闲的库高速缓存内存对象的数目。
V$SHARE_POOL_ADVICE提供各种尺寸的共享池预期可节省的分析时间信息。
4. 优化库高速缓存
CURSOR_SHARING 参数
优化库高速缓存的目的是重用以前分析过的或执行过的代码。最简单的方法就是使用绑定变量。
CURSOR_SHARING=FORCE强制在所有情况下使用绑定变量，而CURSOR_SHARING=SIMILAR只在认为绑定变量不会对优化产生负面影响时才使用它。
ORACLE建议使用CURSOR_SHARING=SIMILAR，因为使用CURSOR_SHARING=FORCE有可能使执行计划变坏。但实际上CURSOR_SHARING=FORCE
对执行计划的好处要远远大于坏处。在观察到由于不使用绑定变量而导致大量硬分析时，通过把默认的CURSOR_SHARING=EXACT改成CURSOR_SHARING=FORCE
可极大的改善性能。可在init.ora或spfile中更改这个参数，也可使用alter system 或alter session 动态的执行更改。
5. 硬分析较大的会话
select s.sid,s.value "hard parse",t.value "executions count"
from v$sesstat s, v$sesstat t where s.sid=t.sid
and s.statistic#=(select statistic#
from v$statname where name='parse count (hard)')
and t.statistic#=(select statistic#
from v$statname where name='execute count')
and s.value>0
order by 2 desc;

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26229047/viewspace-755192/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26229047/viewspace-755192/