ORACLE数据库健康检查详细列表.doc

Database 2004-7 health check By Zero整理 基本信息 DB Name DB Id Instance Snap Time Host GDDB1 2936663066 gddb1 2004-07 gddbsvr1 Buffer Cache Std Block Size Shared Pool Size Log Buffer 976M 8K 352M 1,024K 负载间档（(Load profile) 序号 项目 实测值 说明 1 Redo size 18,884.99B/s 、4,350.20/t 数据库任务的繁重 2 Logical reads 1,949.33/s 、449.03/t 产生的逻辑读（单位块） 3 Block changes 78.63/s 、18.11/t 每秒block变化数量 4 Physical reads 11.13/s 、2.56/t 数据库从磁盘读取block数 5 Physical writes 3.39/s 、0.78/t 数据库写磁盘的block数 6 User calls 148.06/s 、34.11/t 用户call次数 7 Parses 27.68/s 、 6.38/t 解析次数，近似反应每秒语句的执行次数 8 Hard parses 3.02/s 、0.70/t 硬解析次数 9 Sorts 1.94/s 、0.45/t 排序次数 10 Executes 33.53/s 、 7.72/t 执行次数 11 Transactions 4.34/s 每秒产生的事务数，数据库繁重与否 说明： s 表示每秒 t 表示每个事务 B 表示字节 实例命中率(Instance efficiency hit ratios) 序号 项目 实测值 说明 1 Buffer Nowait 100.00 缓冲区获取buffer的未等待率 2 Redo NoWait 100.00 Redo缓冲区获取buffer的未等待率 3 Buffer Hit 99.56 数据块在数据缓冲区中得命中率，通常应在90%以上 4 In-memory Sort 100.00 在内存中的排序率 5 Library Hit 97.84 主要代表sql在共享区的命中率，通常在95%以上，否，需要要考虑加大共享池，绑定变量，修改cursor_sharing等参数 6 Soft Parse 89.09 近似看作sql在共享区的命中率，小于95%,需要考虑到绑定，如果低于80%，那么就可能sql基本没有被重用 7 Execute to Parse 17.46 sql语句解析后被重复执行的次数，如果过低，可以考虑设置session_cached_cursors参数 8 Latch Hit 100.00 锁存器命中率 9 Parse CPU to Parse Elapsd 99.52 解析实际运行事件/（解析实际运行时间+解析中等待资源时间） 10 Non-Parse CPU 93.09 查询时间/（查询实际运行时间+sql解析时间），太低表示解析消耗时间过多 说明： Shared Pool Statistics 序号 项目 实测值 说明 1 Memory Usage 52.32 74.03 共享池内存使用率，应该稳定在75%-90%间，太小浪费内存，太大则内存不足 2 SQL with executions1 80.38 83.22 执行次数大于1的sql比率，若太小可能是没有使用bind variables 3 Memory for SQL w/exec1 99.72 98.72 也即是memory for sql with execution 1:执行次数大于1的sql消耗内存/所有sql消耗的内存 说明： 首要的5个等待事件(Top 5 Wait event) 序号 项目 实测值 说明 1 CPU time 2 log file sync 8,029 34 45 6 0.6 服务器进程执行Commit或者Rollback时,等待LGWR将重做日志信息写到日志文件的完成。如果平均等待时间不高，但等待次数多，说明应用程序每个插入后就立即Commit,没有进行批量Commit，如果平均等待时间高，要具体下钻，一般为slow I/O，不要使用RAID5,因为应用程序写操作太多时，他的速度太慢将日志文件放在更快的磁盘上，或者放在不同的物理磁盘上。 3 db f