Oracle数据库巡检报告

1、v1.0可编辑可修改XXX数据库XXX 巡检报告1 第一部分操作系统参数检查21.1 检查数据库cpu、I/O、内存性能 21.2 检查 Oracle服务进程22 第二部分Oracle数据库检查32.1 数据库状态32.1.1 检查 oracle 环境变量 32.1.2 检查监听状态 32.1.3 查看Oracle初始化参数 32.1.4 检查Oracle的实例状态32.1.5 检查数据库读写状态 32.1.6 查看oracle 数据库的版本 42.1.7 查看 sga、pga 详细信息 42.1.8 检查控制文件状态 42.1.9 检查日志文件状态 42.1.10 检查 alter 日志42

2、.1.11 crontab 任务52.2 数据库空间监控52.2.1检查数据库的大小，和空间使用情况 5查看数据库是否处于归档模式 7检查表空间物理文彳的名称及大小 7数据库数据文件等所在目录使用情况 72.3 数据库性能、资源、对象检查 7负载情况(Load Profile ) 7数据库内存命中率(Instance Efficiency Percentages (Target 100%) 8监控等待事件(Top 5 Timed Events ) 8检查无效的数据对象 9检查碎片程度高的表 9检查排序区9检查日志缓冲区9检查Oracle初始化文件中相关参数值 9检查数据库连接情况 10检查 s

3、ystem 表空间内的内容 10检查表空间碎片率10检查死锁112.4 数据库备份检查11检查数据库备份日志信息 11检查backup卷中文件产生的时间 12检查 oracle 用户的 email 123 第三部分总结121第一部分操作系统参数检查1.1 检查数据库cpu、I/O、内存性能# top检查Z果：正常1.2 检查Oracle服务进程(1)检查所有oracle相关进程# ps -ef|grep ora_(2)查看是否有僵死进程SQL> select spid from v$process where addr not in (select paddr from v$sessio

4、n);检查Z果：正常在检查Oracle 的进程命令输出后，输出显示至少应包括以下一些进程：Oracle写数据文件的进程，输出显示为：“ ora_dbw0_CKDBOracle写日志文件的进程，输出显示为：" ora_lgwr_ CKDB "Oracle监听实例状态的进程，输出显示为：" ora_smon_ CKDB"Oracle监听客户端连接进程状态的进程，输出显示为：“ ora_pmon_CKDBOracle 进行归档的进程，出显示为：" ora_arc0_ CKDB"Oracle 进行检查点的进程，输出显示为：" ora

5、_ckpt_ CKDB "Oracle进行恢复的进程，出显示为："ora_reco_ CKDB"2第二部分 Oracle数据库检查2.1 数据库状态2.1.1 检查oracle环境变量# cat /home/oracle/.profile检查Z果：正常2.1.2 检查监听状态$ Isnrctl status检查Z果：正常2.1.3 查看Oracle初始化参数SQL> show parameter检查Z果：正常2.1.4 检查Oracle的实例状态SQL> select status from v$instance;检查Z果：正常其中"STAT

6、US展示Oracle当前的实例状态，必须为"OPEN" "DATABASE_STATUS"示Oracle当前数据库的状态，必须为 "ACTIVE"。2.1.5 检查数据库读写状态SQL> select open_mode from v$database;检查Z果：正常2.1.6 查看oracle数据库的版本SQL> select * from v$version;检查结果：正常2.1.7 查看sga、pga详细信息SQL> select * from v$sgainfo;SQL> select * from v

7、$pgastat;检查结果：正常2.1.8 检查控制文件状态SQL> select name,status from v$controlfile;检查结果：正常2.1.9 检查日志文件状态SQL> select group#,status,type,member from v$logfile;检查结果：正常2.1.10 检查alter日志SQL> show parameter background_dump_dest$ tail -1000 alert_ 实例名.log检查Z果：正常查看有无" ORA-' , Error "，“Failed ”等出

8、错信息。根据错误信息进行分析并解决检查当前crontab任务(1)任务清单$ crontab -lfrom dba_jobs Where(2) Oracle Job是否有失败SQL> select job,what,last_date,next_date,failures,broken schema_user='CAIKE'检查结果：正常1 .2数据库空间监控1.2.1 检查数据库的大小，和空间使用情况(1)查所有表空间总量：SQL> select sum(tablespace_size * 8192 / 1024 / 1024 /1024) "total

9、msize(G)" from dba_tablespace_usage_metrics;2 2) datafile占文件系统的空间SQL> select sum(bytes)/1024/1024/1024 GB from dba_data_files;(3)查所有表空间使用量(11g)SQL> SELECT /* + RULE */ "Tablespace",/ (1024 * 1024) "Size (MB)",SUM / (1024 * 1024) "Free (MB)",Nvl(Round(SUM * 10

10、0 / ,1) "% Free",Round( - SUM) * 100 / "% Used"FROM dba_free_space fs,(SELECT tablespace_name,SUM(bytes) bytesFROM dba_data_filesGROUP BY tablespace_name) dfWHERE (+)=GROUP BY,UNION ALLSELECT /* + RULE */ tspace,/ (1024 * 1024),SUM / (1024 * 1024),Nvl(Round(SUM - * 100 /, 1),Roun

11、d(SUM - * 100 /FROM dba_temp_files fs,(SELECT tablespace_name,bytes_free,bytes_usedFROM v$temp_space_headerGROUP BY tablespace_name,bytes_free,bytes_used) dfWHERE (+)=GROUP BY ,ORDER BY 4 DESC;(4)检查一些扩展异常的对象SQL> select Segment_Name,Segment_Type,TableSpace_Name, (Extents / Max_extents) * 100 Perce

12、nt FromWhere Max_Extents != 0 and (Extents / Max_extents) * 100 >= 95 order By Percent;检查结果：正常查看数据库是否处于归档模式SQL> archive log list;检查结果：正常检查表空间物理文件的名称及大小SQL> col name for a55SQL> select file#,ts#,status,name from v$datafile;检查结果：正常数据库数据文件等所在目录使用情况# df -h检查结果：正常2.3 数据库性能、资源、对象检查负载情况(Load Pr

13、ofile )生成awr报告SQL> /rdbms/admin/awrrpt检查结果：正常如果DBtime远小于elapse说明数据库比较空闲如果Logons大于每秒12个、Hard parses 大于每秒100、全部parses超过每秒300表明可能有争用问题数据库内存命中率(Instance Efficiency Percentages (Target 100%)检查结果：正常Buffer Nowait表示在内存获得数据的未等待比例。Buffer Nowait的这个值一般需要大于99%否则可能存在争用，可以在后面的等待事件中进一步确认。Redo NoWait表示在LO©冲区

14、获得BUFFER勺未等待比例。如果太低(可参考90%W直)，考虑增加LOG BUFFERbuffer hit表示进程从内存中找到数据块的比率。常应在95%A上。否则，小于 95%需要调整重要的参数，小于90%能是要加db_cache_size 。In-memory Sort :在内存中排序的比率。如果低于95%可以通过适当调大初始化参数PGA_AGGREGATE_TARGET SORT_AREA_SIZ来解决library hit表示Oracle从Library Cache 中检索到一个解析过的 SQL或PL/SQL语句的比 率。如果library hit ratio低于90% 可能需要调大

15、shared pool区。Soft Parse :软解析的百分比(softs/softs+hards )小于<95%需要考虑绑定，如果低于80%那么就可以认为 sql基本没有被重用Execute to Parse :是语句执行与分析的比例。该值<0通常说明shared pool设置或者语句效率存在问题，造成反复解析Latch Hit : Latch是一种保护内存结构的锁。要确保 >99%否则存在严重的性能问题。Parse CPU to Parse Elapsd :解析实际运行时间/(解析实际运行时间+解析中等待资源时 间)越高越好。Non-Parse CPU : SQL实际运

16、行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消 耗时间过多监控等待事件(Top 5 Timed Events )检查Z果：正常一个性能良好的系统，cpu time应该在top 5的前面，否则说明你的系统大部分时间都用在等待上。检查无效的数据对象SQL> col OBJECT_NAME for a35SQL> SELECT owner, object_name, object_type,status FROMdba_objects WHERE status = 'INVALID'检查Z果：正常如存在状态为N/A的表示分区对象，不用理会检查碎片程度高的表

17、SQL> SELECT segment_name table_name,COUNT(*) extents FROM dba_segments WHERE ownerNOTIN ('SYS', 'SYSTEM') GROUBYsegment_name HAVINGCOUNT(*)=(SELECTMAX(COUNT(*) FROM dba_segments GROUP BY segment_name);检查Z果：正常检查排序区SQL> select name,value from v$sysstat where name like '%sort%

18、'检查Z果：正常如果disk/(memoty+row) 的比例过高，则需要调整检查日志缓冲区SQL> select name,value from v$sysstat where namein ('redo entries','redo buffer allocation retries');检查Z果：正常如果 redo buffer allocation retries/redo entries 超过 1% ,则需要增大 log_buffer 。检查Oracle初始化文件中相关参数值SQL> select resource_name,max

19、_utilization,initial_allocation,limit_value from v$resource_limit;检查Z果：正常若 LIMIT_VALU-MAX_UTILIZATION<=5,贝U表明与 RESOURCE_NAME 关的 Oracle 初始化参数 需要调整。检查数据库连接情况SQL> select sid,serial#,username,program,machine,status from v$session;检查Z果：正常建议通过sid 查到操作系统的 spid,使用ps - ef|grep spidno 的方式确认spid 不是 ORACL

20、E勺后台进程。使用操作系统的 kill -9命令杀掉连接)，SID为1到10(USERNAME 列为空)的会话，是 Oracle的后台进程，不要对这些会话进行任何操作。检查system表空间内的内容SQL> select distinct(owner) from dba_tables where tablespace_name='SYSTEM' andowner!='SYS' and owner!='SYSTEM' Union select distinct(owner) from dba_indexeswhere tablespace_n

21、ame='SYSTEM' and owner!='SYS' and owner!='SYSTEM'检查Z果：正常如果记录返回，则表明 system表空间内存在一些非 system和sys用户的对象。应该进 一步检查这些对象是否与我们应用相关。如果相关则把这些对象移到非System表空间，同时应该检查这些对象属主的缺省表空间值。检查表空间碎片率(1)查看fsfi值，如果碎片率小于30则说明碎片过多SQL> select ,trunc(sqrt(max(blocks)/sum(blocks)* (100/sqrt(sqrt(count(blocks),2) f