1 库缓存命中率
可以通过查询动态性能视图v$librarycache（select * from v$librarycache;），该视图保存了数据库最近一次启动以来库缓存活动的统计信息，每一行记录反映了库缓存中一个条目类型的统计信息，通过namespace列值来识别每个条目类型。例如：
selectt1.NAMESPACE,t1.PINS,t1.PINHITS,t1.RELOADS,t1.INVALIDATIONS from v$librarycachet1 order by t1.NAMESPACE;
SQL> selectt1.NAMESPACE,t1.PINS,t1.PINHITS,t1.RELOADS,t1.INVALIDATIONS from v$librarycachet1 order by t1.NAMESPACE;
NAMESPACE PINS PINHITS RELOADS INVALIDATIONS
-------------------------------------------------------------------------- ---------- ---------- -------------
APP CONTEXT 2 1 0 0
BODY 28468616 28458242 1818 46
CLUSTER 114902 114198 0 0
DBINSTANCE 0 0 0 0
DBLINK 0 0 0 0
DIRECTORY 371 81 0 0
EDITION 10577860 10577856 0 0
INDEX 403451 315690 11194 0
JAVA DATA 3161 1876 0 0
JAVA RESOURCE 3413 2124 0 0
JAVA SOURCE 3413 2121 0 0
OBJECT ID 0 0 0 0
PIPE 2940 2936 0 0
QUEUE 755296 754776 218 0
RULE 732 365 82 0
RULESET 18358 17693 26 0
SCHEMA 0 0 0 0
SQL AREA 1252576540 1223849814 1430167 926624
SUBSCRIPTION 50182 49948 6 0
TABLE/PROCEDURE 162038767 161228629 429539 263
NAMESPACE PINS PINHITS RELOADS INVALIDATIONS
-------------------------------------------------------------------------- ---------- ---------- -------------
TEMPORARY INDEX 25602 0 7514 0
TEMPORARY TABLE 70046 0 55020 0
TRIGGER 12753767 12747803 1146 0
XDB CONFIG 1 0 0 0
XML SCHEMA 27 6 4 0
25 rows selected
SQL>
PINS：针对特定NAMESPACE的对象请求次数
PINHITS：针对特定NAMESPACE的对象请求次数，在库缓存中存在的次数
RELOADS：需要从磁盘中加载对象的次数
INVALIDATIONS：针对特定的namespace，由于依赖对象的改变而被标识为失败的对象的次数。
库缓存命中率的计算公式(sum(t1.PINHITS)/sum(pins)计算)，例如：
SQL> select sum(t1.PINHITS)/sum(pins)"Lib Ratio" from v$librarycache t1;
LibRatio
----------
0.97973692
SQL>
也可以查询动态性能视图v$sgastat来获取共享池空闲内存的数量。例如：
SQL> select t1.* from v$sgastat t1 wheret1.NAME='free money' and pool='shared pool';
POOL NAME BYTES
------------ ------------------------------------
SQL>
2 数据字典缓存命中率
通常，如果共享池中库缓存空间充足，那么数据字典缓存也会充足，在某些情况下，数据缓会失败，比如在数据库实例刚启动的时候，数据库字典缓存不包含任何数据，任何sql语句的执行都会导致数据字典缓存失败，而随着数据缓存字典的增多，缓存失败将较少，最后将达到一个稳定的命中率，此时数据字典缓存失败率将非常低。
可以通过查询数据库动态性能视图v$rowcache（select * from v$rowcache;）获取不同类型数据字典条目的统计信息。这里反应了从最近一次数据库启动以来数据字典的使用情况。
SQL> selectt1.PARAMETER,sum(t1.GETS),sum(t1.GETMISSES),100*sum(t1.GETS-t1.GETMISSES)/sum(t1.GETS)pct_succ_gets,sum(t1.MODIFICATIONS)updates from v$rowcache t1 where t1.GETS!=0group by t1.PARAMETER;
PARAMETER SUM(T1.GETS)SUM(T1.GETMISSES) PCT_SUCC_GETS UPDATES
-------------------------------------------- ----------------- ------------- ----------
dc_constraints 39950 16050 59.8247809762 39942
qmc_app_cache_entries 1 1 0 0
sch_lj_oids 33696 1452 95.6908831908 0
dc_tablespaces 994784326 74 99.9999925612 2
dc_awr_control 271427 3 99.9988947304 6322
dc_object_grants 41203543 6097 99.9852027288 0
dc_histogram_data 649621988 1065618 99.8359633725 1069946
dc_rollback_segments 25496538 235 99.9990783062 825
dc_sequences 156506 1536 99.0185679782 156506
sch_lj_objs 4018 796 80.1891488302 0
dc_segments 130394426 139507 99.8930115310 77938
dc_objects 225599535 310991 99.8621490952 96415
dc_histogram_defs 217299674 1852549 99.1474681181 646908
dc_table_scns 4801 4801 0 0
dc_users 1300331635 10744 99.9991737492 789
qmtmrcin_cache_entries 1 1 0 0
outstanding_alerts 413246 2893 99.2999327277 6092
dc_files 36345 49 99.8651809052 6
dc_global_oids 28777369 6959 99.9758178032 235
dc_profiles 5282207 1 99.9999810685 0
PARAMETER SUM(T1.GETS)SUM(T1.GETMISSES) PCT_SUCC_GETS UPDATES
-------------------------------------------- ----------------- ------------- ----------
global database name 12620366 16 99.9998732207 0
qmtmrctn_cache_entries 13 13 0 0
qmtmrciq_cache_entries 1 1 0 0
qmtmrctq_cache_entries 586 585 0.17064846416 0
qmrc_cache_entries 7 7 0 0
25 rows selected
SQL>
PARAMETER：标识一个特定类型的数据字典条目，以dc_为前缀。
GETS：对特性数据字典条目请求的数据总数量
GETMISSES：显示由于数据字典缓存失败，需要进行磁盘I/O操作的数据的数量
MODIFICATIONS：显示数据字典缓存中数据被更新的次数
3 共享池大小的调整
通常情况下，库缓存命中率应该高于99%，而数据字典缓存命中率应该高于90%，否则需要调整共享池大小了。因为库缓存的大小和数据字典缓存大小没有单独设置，而是oracle自动按照一定的算法在共享池中分配，按照oracle中的内存空间分配算法，如果库缓存命中率高，那么数据字典缓存命中率也会很高。
4 重做日志缓冲区调整
重做日志缓冲区用于存放数据的修改信息，重做日志首先写入重做日志缓冲区，在一定条件下由LGWR进程将重做缓冲区的信息写入重做日志文件；如果重做日志缓冲区容量较大，即可以保证有足够空间存储新产生的重做记录，又可以为LGWR进程高效写入重做日志文件提供了条件；如果重做日志缓冲区已经满了，没有空间容纳新的重做日志记录，新产生的重做日志记录处于waiting状态，称为重做日志缓冲区写入失败。过多的重做日志写入失败，说明重做日志缓冲区偏小，影响数据库性能。
可以通过如下方式检查重做日志缓冲区写入失败率。
select t1.NAME"request",t2.NAME,t1.VALUE/t2.VALUE "Fail Ratio"
from v$sysstat t1,v$sysstat t2
where t1.name='redo log space requests' andt2.NAME='redo entries';
结果如下：
SQL> select t1.NAME"request",t2.NAME,t1.VALUE/t2.VALUE "Fail Ratio"
2 from v$sysstat t1,v$sysstat t2
3 where t1.name='redo log spacerequests' and t2.NAME='redo entries';
request NAME Fail Ratio
-------------------------------------------------------------------------------------------------------------------------------- ----------
redo log space requests redoentries 0.00355035
SQL>
通常日志缓冲区的写入失败率应该接近于0，如果失败率大于1%，则说明日志缓冲区太小，应该增加LOG_BUFFER的大小。
看到写入失败率为0.003，远远小于1，证明日志缓冲区还算比较合适的。
