1)Library Cache的命中率: .计算公式:Library Cache Hit Ratio = sum(pinhits) / sum(pins) SQL>SELECT SUM(pinhits)/sum(pins) FROM V$LIBRARYCACHE; 通常在98%以上,否则,需要要考虑加大共享池,绑定变量,修改cursor_sharing等参数。 2)计算共享池内存使用率: SQL>SELECT (1 - ROUND(BYTES / (&TSP_IN_...
一般来讲, production服务器运行的时间越长,命中率越稳定, 正常来讲这两个命中率一般都在99% 以上, 如果98% 就有问题了... 可以用如下语句来查看软解析命中率: select sum(pinhits)/sum(pins)*100 fromv$librarycache; 如下图, 因为我的是私人小数据库, 运行时间短, 这个命中率就很低了.. 可以用如下语...
SQL>selectnamespace,pins pinhits ,pinhitratiofromv$librarycache; NAMESPACE PINHITS--- ---PINHITRATIO---SQL AREA316416.969154531TABLE/PROCEDURE81435.94126604BODY48572.998332373NAMESPACE PINHITS--- ---PINHITRATIO---TRIGGER228.903508772INDEX2622.768878719CLUSTER668.986526946NAMESPACE PINHITS---...
select1-sum(gethits)/sum(gets)from v$librarycache; 这个比率应该在90%以上。还有一个比率也很重要,就是Reload和Pin的比值,这个比值应该小于1%。 如果没有达到这些比例,解决方法很简单,问题或者是SQL语句没有共享,或者是共享池太小。 有关库缓存命中率,也可以查看STATSPACK报告中的Library Hit %项。这个我们上面...
以各种命中率为主要的优化入口依据,常见的有”library cache hit radio“等。但这种方式弊端很大,一个命中率为99%的系统,不一定就比95%的系统优化的更好。在老的Oracle版本中,往往采用这种方式,如8i、9i等。 以等待事件为主要参考指标 以各种等待事件为优化入口依据,常见的有"db file sequential read"等。可以较...
v 库缓存命中率(Library Hit%):表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率,当应用程序调用SQL或存储过程时,Oracle检查Library Cache确定是否存在解析过的版本,如果存在,那么Oracle立即执行语句;如果不存在,那么Oracle解析此语句,并在Library Cache中为它分配共享SQL区。该值过低说明有过多的...
Library Cache结构示意图如下: 在访问库缓存对象时,比如软解析时,要从库缓存中读取执行计划。Oracle首先找到句柄,读取句柄中的信息,这就叫做一次库缓存Get。如果库缓存中不包括对象的句柄信息,Oracle就要重新在库缓存中分配内存、构造句柄,这就是库缓存句柄未命中(Get Miss)。相反,如果在库缓存中找到了对象句柄,就是...
在分析完这个SQL,Oracle会把他的分析结果给保存在Shared pool的Library Cache中,当数据库第二次执行该SQL时,Oracle自动跳过这个分析过程,从而减少了系统运行的时间。这也是为什么第一次运行的SQL 比第二次运行的SQL要慢一点的原因。 下面举例说明parse的时间 SQL> select count(*) fromscpass ; COUNT(*) --- ...
oracle性能监控一,缓冲区的命中率.pdf,Oracle 性能 2 一, 缓冲区 中率2 1.1 oracle 的内存结构2 1.2 oracle 数据库缓冲区的内部机制3 1.3 数据库缓冲区 4 1.4 改进数据库缓冲区的性能5 二, sql 语句的重载率6 2.1 oracle 库缓存6 2.2 library cache 的内存结构8 2.3 Library