内容发布更新时间 : 2024/12/31 3:52:29星期一 下面是文章的全部内容请认真阅读。

数据库紧急情况检查应急预案

第一章、 公共检查部分 ................................................................................................... 2

1.1、数据库可用性检查 .................................................................................................. 2 1.2、检查OS日志 ........................................................................................................... 2 1.3、系统资源检查 .......................................................................................................... 2 1.4、数据库日志检查 ...................................................................................................... 3 1.5、检查数据库归档日志目录 ...................................................................................... 3 第二章、 数据库个别业务性能问题 ............................................................................... 3

2.1、大部分业务基本正常，个别业务长时间执行未成功 .......................................... 3 2.2、单个ORACLE连接进程持续非常繁忙 ................................................................ 4 第三章、 数据库整体性能问题 ....................................................................................... 5

3.1 等待事件 .................................................................................................................... 5 3.2 获取STATSPACK\\AWR报告 .................................................................................. 5 3.3 获取执行计划 ............................................................................................................ 5 3.4 相应的处理建议 ........................................................................................................ 6 第四章、 整个数据库hang .............................................................................................. 6

4.1不能使用sqlplus / as sysdba进入数据库时 ............................................................. 6 4.2能使用sqlplus / as sysdba进入数据库时 ................................................................. 6 4.3 执行RDA收集信息 ................................................................................................. 7 4.4 收集最近的STATSPACK/AWR报告 ...................................................................... 7 4.5 收集10G ASH报告 .................................................................................................. 7 4.6 收集10GR2的CRS信息 ......................................................................................... 8

第一章、 公共检查部分 1.1、数据库可用性检查

分别尝试从pl/sql开发工具和数据库主机登录数据库看能否登录 oracle用户登录后，执行如下操作：

select object_id from dba_objects where rownum < 5;

create table tmp0001 select object_id from dba_objects where rownum < 5; drop table tmp0001;

select * from dba_2pc_pending;

1）如果以上SQL可顺利快速执行，最后的SQL也没有返回被挂起的两阶段提交事务，说明数据库不是阻塞所有业务的原因

2）如果以上SQL执行非常缓慢或被HANG住，表明当前数据库存在问题 3）如果应用、中间件日志中有数据库方面的报错，根据错误号进行分析

1.2、检查OS日志

查看OS日志，看是否有相应的报错。 根据不同的平台选择以下命令查看 LINUX：vi /var/log/message AIX：errpt、mail

HPUX：vi /var/adm/syslog/syslog.log、dmesg 、mail

1.3、系统资源检查

LINUX下使用top/iostat/vmstat 等命令;AIX下使用TOPAS/vmstat/lsps –a/sar 等命令；HPUX下使用top /glance/vmstat/swapinfo –atm/sar等命令，查看当前CPU/mem/swap的占用情况

1）如果CPU有超过平常很高的WIO

2）如果user很高，查看top cpu占用的进程是否为oracle进程

? 如果是oracle后台进程CPU占用高，则联系ORACLE驻场工程师协助判断是否碰

到了某个已知的BUG

? 如果是oracle连接进程CPU占用高，执行$ORACLE_BASE/sql/get_by_spid.sh获得

高CPU进程正在执行的语句和相应的执行计划

3）如果MEM很低，SWAP区page out很频繁，需要联系系统管理员检查内存情况，如

是否出现异常的memory leak。同时针对ORACLE检查以下情况

? 连接数--- v$session 根据status/machine/program/username分组统计（group by）,

与应用一起分析连接数异常的原因。 ? 获得占用高MEMORY的oracle进程，执行$ORACLE_BASE/sql/pga_sid.sql获得该

进程PGA的内存使用情况，执行$ORACLE_BASE/sql/get_by_spid.sh获得高CPU

进程正在执行的语句和相应的执行计划。

1.4、数据库日志检查

执行$ORACLE_BASE/sql/oracle_health_check.sql查看数据库alert日志/UDUMP/BDUMP是否有异常信息，如ORA-报错，此前没有或很少出现的警告提示信息.如果检查到报错信息，根据报错情况进行分析和采取相应的处理办法。

1.5、检查数据库归档日志目录

1）切换频率是否正常/目录权限及使用率

2）如果数据库日志长时间没有写入信息，没有日志切换，可能数据库已经处于挂起的

状态(此时须先排除归档太大占空间100%问题)

第二章、 数据库个别业务性能问题

2.1、大部分业务基本正常，个别业务长时间执行未成功

2.1.1、 根据应用的pid、sid等信息，找到数据库中对应的session、SQL。得到该SQL的执行计划。 1）执行$ORACLE_BASE/sql/show_spid.sql即可根据SID快速获取操作系统进行号spid的信息；

2）执行$ORACLE_BASE/sql/get_by_spid.sh spid，即可根据操作系统进程号依次打印执行的SQL语句和执行计划；

3）执行$ORACLE_BASE/sql/showsql_pid.sql即可根据pid快速获取执行的SQL语句 4）执行$ORACLE_BASE/sql/showsql_sid.sql即可根据sid快速获取执行的SQL语句

? 如果执行计划不恰当，需要分析执行计划变化的原因（如索引不正确、统计信息过时、

绑定变量偷窥等）采取相应的错误如添加缺失的索引、重新收集统计信息等，评估中止该业务的影响，尝试停止该SQL的执行后，重新收集相关表的统计信息，使业务SQL能按正确的执行计划执行。

? 如果执行计划正确，SQL却长时间不能返回结果，则按照以下办法尽快收集必要信息，

再重启任务。

$ sqlplus \

oradebug setospid oradebug unlimit

oradebug dump processstate 10 oradebug tracefile_name --得到trace文件名 exit