Oracle常用SQL脚本

测定数据的命中率
select 1 - (sum(decode(name, 'physical reads', value, 0)) /
       (sum(decode(name, 'db block gets', value, 0)) +
       (sum(decode(name, 'consistent gets', value, 0))))) "Read Hit Ratio"
  from v$sysstat;

上面程序清单中的命中率很高，但这并不意味着系统已经调整至最佳状态。很高的命中率也可能意味着查询使用了过度的索引。如果这个命中率低于 95%，您可能需要增加 init.ora 参数 DB_CACHE_SIZE，或者调整一些引起磁盘读取操作的查询(仅当这样做是可行的并且确实有效的情况下)。一种例外情况就是分布在不同块中的数据分布的极不平衡。如果不考虑这种可能性，那么命中率低于 90%几乎总意味着系统调整得很糟糕，要么就是某些人不切实际地设计，使每个数据块的数据都极不平衡。


测定数据字典的命中率
select sum(gets),
       sum(getmisses),
       (1 - (sum(getmisses) / (sum(gets) + sum(getmisses)))) * 100 HitRate
  from v$rowcache;
推荐的命中率是 95%或者更高。如果命中率低于这个百分比，说明可能需要增加 init.ora 参数SHARED_POOL_SIZE。但要记住，在 V$SGASTAT 视图中看到的共享池包括多个部分，而这里仅仅就是其中之一。注意：在大幅度使用公共同名的环境中，字典命中率可能难以超过 75%，即使共享池的尺寸很大。这是因为 Oracle 必须经常检查不存在的对象是否依旧存在。 


测定共享SQL和 PL/SQL的命中率
访问 V$LIBRARYCACHE 视图可以显示实际使用的语句(SQL 和 PL/SQL)访问内存的情况。如果 init.ora的参数 SHARED_POOL_SIZE 设置得太小，内存中就没有足够的空间来存储所有的语句。如果共享池的碎片化现象很严重，较大的 PL/SQL 程序就无法加载到共享池中。如果不能有效地重用语句，则扩大共享池可能事与愿违，反而带来更多不利
这里包括执行率(固定命中率)和重载命中率。推荐的固定对象的命中率是 95%以上，重载命中率应为99%以上(低于 1%的重载次数)。如果语句先前已经经过分析，但共享池通常不够大，在分析其他的语句时无法在内存中保存这个语句，则在此时会出现重载。语句的主体被挤出内存(语句头仍然保存下来)；当需要再次使用该语句时，就将重载记录下来，并将语句主体再次加载到内存中。这种情况也会出现在语句的执行计划发生变动时。如果有任何一个命中率低于这些百分比，就说明应该更仔细地分析共享池的分布情况。下面的程序清单显示了如何查询上面讨论的所有信息
select sum(pins) "Executions",
       sum(pinhits) "Hits",
       ((sum(pinhits) / sum(pins)) * 100) "PinHitRatio",
       sum(reloads) "Misses",
       ((sum(pins) / (sum(pins) + sum(reloads))) * 100) "RelHitRatio"
  from v$librarycache;