Oracle数据库巡检报告.doc

XXX数据库【XXX】巡检报告1 第一部分操作系统参数检查21.1 检查数据库cpu、I/O、内存性能21.2 检查Oracle服务进程22 第二部分Oracle数据库检查22.1 数据库状态22.1.1 检查oracle环境变量22.1.2 检查监听状态32.1.3 查看Oracle初始化参数32.1.4 检查Oracle的实例状态32.1.5 检查数据库读写状态32.1.6 查看oracle数据库的版本32.1.7 查看sga、pga详细信息32.1.8 检查控制文件状态42.1.9 检查日志文件状态42.1.10 检查alter日志42.1.11 检查当前crontab任务42.2 数据库空间监控42.2.1 检查数据库的大小，和空间使用情况42.2.2 查看数据库是否处于归档模式62.2.3 检查表空间物理文件的名称及大小62.2.4 数据库数据文件等所在目录使用情况62.3 数据库性能、资源、对象检查62.3.1 负载情况（Load Profile）62.3.2数据库内存命中率（Instance Efficiency Percentages (Target 100%)）62.3.3监控等待事件（Top 5 Timed Events ）62.3.4检查无效的数据对象72.3.5检查碎片程度高的表72.3.6 检查排序区72.3.7 检查日志缓冲区72.3.8 检查Oracle初始化文件中相关参数值72.3.9 检查数据库连接情况72.3.10 检查system表空间内的内容82.3.11 检查表空间碎片率82.3.12 检查死锁82.4 数据库备份检查82.4.1 检查数据库备份日志信息82.4.2 检查backup卷中文件产生的时间92.4.3检查oracle用户的email93 第三部分总结91 第一部分操作系统参数检查1.1 检查数据库cpu、I/O、内存性能# top检查结果: 正常1.2 检查Oracle服务进程（1）检查所有oracle相关进程# ps -ef|grep ora_（2）查看是否有僵死进程SQL> select spid from v$process where addr not in (select paddr from v$session); 检查结果: 正常在检查 Oracle 的进程命令输出后，输出显示至少应包括以下一些进程：Oracle 写数据文件的进程，输出显示为：“ora_dbw0_CKDB”Oracle 写日志文件的进程，输出显示为：“ora_lgwr_ CKDB”Oracle 监听实例状态的进程，输出显示为：“ora_smon_ CKDB”Oracle 监听客户端连接进程状态的进程，输出显示为：“ora_pmon_CKDB”Oracle 进行归档的进程，输出显示为：“ora_arc0_ CKDB”Oracle 进行检查点的进程，输出显示为：“ora_ckpt_ CKDB”Oracle 进行恢复的进程，输出显示为：“ora_reco_ CKDB”2 第二部分Oracle数据库检查2.1 数据库状态2.1.1 检查oracle环境变量# cat /home/oracle/.profile检查结果: 正常2.1.2 检查监听状态$ lsnrctl status检查结果: 正常2.1.3 查看Oracle初始化参数SQL> show parameter检查结果: 正常2.1.4 检查Oracle的实例状态SQL> select status from v$instance;检查结果: 正常其中"STATUS"表示Oracle当前的实例状态，必须为"OPEN"；"DATABASE_STATUS"表示Oracle当前数据库的状态，必须为"ACTIVE"。2.1.5 检查数据库读写状态SQL> select open_mode from v$database;检查结果: 正常2.1.6 查看oracle数据库的版本SQL> select * from v$version; 检查结果：正常2.1.7 查看sga、pga详细信息SQL> select * from v$sgainfo;SQL> select * from v$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检查结果:正常查看有无“ORA-”，Error”，“Failed”等出错信息。根据错误信息进行分析并解决2.1.11 检查当前crontab任务（1）任务清单$ crontab -l（2）Oracle Job是否有失败SQL> select job,what,last_date,next_date,failures,broken from dba_jobs Where schema_user=CAIKE;检查结果：正常2.2 数据库空间监控2.2.1 检查数据库的大小，和空间使用情况（1）查所有表空间总量：SQL> select sum(tablespace_size * 8192 / 1024 / 1024 /1024) "totalmsize(G)" from dba_tablespace_usage_metrics;（2）datafile占文件系统的空间SQL> select sum(bytes)/1024/1024/1024 GB from dba_data_files;（3）查所有表空间使用量（11g） SQL> SELECT /* + RULE */ df.tablespace_name "Tablespace", df.bytes / (1024 * 1024) "Size (MB)", SUM(fs.bytes) / (1024 * 1024) "Free (MB)", Nvl(Round(SUM(fs.bytes) * 100 / df.bytes),1) "% Free", Round(df.bytes - SUM(fs.bytes) * 100 / df.bytes) "% Used" FROM dba_free_space fs, (SELECT tablespace_name,SUM(bytes) bytes FROM dba_data_files GROUP BY tablespace_name) df WHERE fs.tablespace_name (+) = df.tablespace_name GROUP BY df.tablespace_name,df.bytes UNION ALL SELECT /* + RULE */ df.tablespace_name tspace, fs.bytes / (1024 * 1024), SUM(df.bytes_free) / (1024 * 1024), Nvl(Round(SUM(fs.bytes) - df.bytes_used) * 100 / fs.bytes), 1), Round(SUM(fs.bytes) - df.bytes_free) * 100 / fs.bytes) FROM dba_temp_files fs, (SELECT tablespace_name,bytes_free,bytes_used FROM v$temp_space_header GROUP BY tablespace_name,bytes_free,bytes_used) df WHERE fs.tablespace_name (+) = df.tablespace_name GROUP BY df.tablespace_name,fs.bytes,df.bytes_free,df.bytes_used ORDER BY 4 DESC; （4）检查一些扩展异常的对象SQL> select Segment_Name,Segment_Type,TableSpace_Name, (Extents / Max_extents) * 100 Percent From sys.DBA_SegmentsWhere Max_Extents != 0 and (Extents / Max_extents) * 100 >= 95order By Percent;检查结果：正常2.2.2 查看数据库是否处于归档模式SQL> archive log list;检查结果：正常2.2.3 检查表空间物理文件的名称及大小SQL> col name for a55SQL> select file#,ts#,status,name from v$datafile;检查结果：正常2.2.4 数据库数据文件等所在目录使用情况# df -h检查结果：正常2.3 数据库性能、资源、对象检查2.3.1 负载情况（Load Profile）生成awr报告SQL> ?/rdbms/admin/awrrpt 检查结果：正常如果DBtime远小于elapse说明数据库比较空闲如果Logons大于每秒12个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题2.3.2数据库内存命中率（Instance Efficiency Percentages (Target 100%)）检查结果：正常Buffer Nowait表示在内存获得数据的未等待比例。Buffer Nowait的这个值一般需要大于99%。否则可能存在争用，可以在后面的等待事件中进一步确认。Redo NoWait表示在LOG缓冲区获得BUFFER的未等待比例。如果太低（可参考90%阀值），考虑增加LOG BUFFERbuffer hit表示进程从内存中找到数据块的比率。常应在95%以上。否则，小于95%，需要调整重要的参数，小于90%可能是要加db_cache_size。In-memory Sort：在内存中排序的比率。如果低于95%，可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决library hit表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率。如果library hit ratio低于90%，可能需要调大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实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多2.3.3监控等待事件（Top 5 Timed Events ）检查结果:正常一个性能良好的系统，cpu time应该在top 5的前面，否则说明你的系统大部分时间都用在等待上。2.3.4检查无效的数据对象SQL> col OBJECT_NAME for a35SQL> SELECT owner, object_name, object_type,status FROM dba_objects WHERE status = INVALID; 检查结果: 正常如存在状态为N/A的表示分区对象，不用理会2.3.5检查碎片程度高的表SQL> SELECT segment_name table_name,COUNT(*) extents FROM dba_segments WHERE ownerNOT IN (SYS, SYSTEM) GROUP BY segment_name HAVING COUNT(*)=(SELECT MAX(COUNT(*) FROM dba_segments GROUP BY segment_name);检查结果:正常2.3.6 检查排序区SQL> select name,value from v$sysstat where name like %sort%;检查结果:正常如果disk/(memoty+row) 的比例过高，则需要调整2.3.7 检查日志缓冲区SQL> select name,value from v$sysstat where name in (redo entries,redo buffer allocation retries);检查结果:正常如果 redo buffer allocation retries/redo entries 超过 1% ，则需要增大 log_buffer。2.3.8 检查Oracle初始化文件中相关参数值SQL> select resource_name,max_utilization,initial_allocation, limit_value from v$resource_limit;检查结果:正常若 LIMIT_VALU-MAX_UTILIZATION<=5，则表明与 RESOURCE_NAME 相关的Oracle 初始化参数需要调整。2.3.9 检查数据库连接情况SQL> select sid,serial#,username,program,machine,status from v$session;检查结果:正常建议通过 sid 查到操作系统的 spid,使用 ps ef|grep spidno 的方式确认 spid 不是ORACLE 的后台进程。使用操作系统的 kill -9 命令杀掉连接），SID 为 1 到10(USERNAME 列为空)的会话，是 Oracle 的后台进程，不要对这些会话进行任何操作。2.3.10 检查system表空间内的内容SQL> select distinct(owner) from dba_tables where tablespace_name=SYSTEM and owner!=SYS and owner!=SYSTEM Union select distinct(owner) from dba_indexes where tablespace_name=SYSTEM and owner!=SYS and owner!=SYSTEM;检查结果:正常如果记录返回，则表明 system 表空间内存在一些非 system 和 sys 用户的对象。应该进一步检查这些对象是否与我们应用相关。如果相关则把这些对象移到非 System 表空间，同时应该检查这些对象属主的缺省表空间值。2.3.11 检查表空间碎片率（1）查看fsfi值，如果碎片率小于30则说明碎片过多SQL> select a.tablespace_name,trunc(sqrt(max(blocks)/sum(blocks)* (100/sqrt(sqrt(count(blocks),2) fsfi from dba_free_space a,dba_tablespaces bwhere a.tablespace_name=b.tablespace_nameand b.contents not in(TEMPORARY,UNDO,SYSAUX)group by A.tablespace_name order by fsfi;（2）查看dba_free_space 采用字典管理的表空间碎片超过500就需要对表空间进行碎片整理SQL> select a.tablespace_name ,count(1) 碎片量 fromdba_free_space a, dba_tablespaces bwhere a.tablespace_name =b.tablespace_nameand b.contents not in(TEMPORARY,UNDO,SYSAUX)group by a.tablespace_namehaving count(1) >20order by 2;检查结果：正常2.3.12 检查死锁SQL> select sid,serial#,username,SCHEMANAME,osuser,MACHINE,terminal,PROGRAM,owner,object_name,object_type,o.object_idfrom dba_objects o, v$locked_object l, v$session s where o.object_id = l.object_id and s.sid = l.session_id; 检查结果：正常2.4 数据库备份检查2.4.1 检查数据库备份日志信息# cat XX.log|grep i error检查结果：正常2.4.2 检查backup卷中文件产生的时间# ls lt /XXX/XXX检查结果：正常2.4.3检查oracle用户的email# tail -n 300 /var/mail/oracle检查结果：正常3 第三部分总结