ORACLE紧急情况检查应急预案

来源：工作范文网时间：2020-11-26 11:09:16

ORACLE紧急情况检查应急预案

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

第一章、公共检查部分 ................................................................................................... 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 oradebug unlimit

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

得到该进程的stack信息： $ sqlplus \

oradebug setospid oradebug unlimit

oradebug dump errorstack 3 oradebug tracefile_name --得到trace文件名 Exit

2.1.2、如果PID、SID定位不到，则查询STATSPACK、AWR报告、v$session_wait和v$lock视图。

1）9i下，执行$ORACLE_HOME/rdbms/admin/spreport.sql获得STATSPACK报告 10g下，执行$ORACLE_HOME/rdbms/admin/awrrpt.sql获取最近时间的AWR报告

2）执行$ORACLE_BASE/sql/show_wait.sql和show_wait_global.sql快速获得v$session_wait视图的详细信息

3）执行$ORACLE_BASE/sql/session_enqueue.sql获得v$lock视图中中锁持有者和锁等待者的详细信息

2.2、单个ORACLE连接进程持续非常繁忙

通过top\\topas\\glance命令在OS上获得持续繁忙的操作系统进程号spid

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

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

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

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

再重启任务。

$ sqlplus \

oradebug setospid oradebug unlimit

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

得到该进程的stack信息： $ sqlplus \

oradebug setospid oradebug unlimit

oradebug dump errorstack 3 oradebug tracefile_name --得到trace文件名 Exit

第三章、数据库整体性能问题

现象：

业务处理总体非常缓慢，但也有部分业务能够处理完成或者

数据库主机CPU持续异常很高，而且都是ORACLE连接进程造成的时候请用以下方法检查

3.1 等待事件

找到当前数据库等待最多的事件：

1）9i下通过查询v$session_wait视图获取当前等待最多的事件。

执行$ORACLE_BASE/sql/show_session_wait.sql可快速查询按event分组的统计情况 2）10g下使用ash工具来看最近15分钟等待事件及造成等待事件的SQL和session ASH的收集办法：执行$ORACLE_HOME/rdbms/admin/ashrpt.sql

3.2 获取STATSPACK\\AWR报告

1)9i下，执行$ORACLE_HOME/rdbms/admin/spreport.sql获得STATSPACK报告也可以下办法手工获取最近几分钟的statspack报告 Sqlplus perfstat/PASSWORD

Exec statspack.snap(i_snap_level => 7); ……等待几分钟

Exec statspack.snap(i_snap_level => 7);

$ORACLE_HOME/rdbms/admin/spreport.sql

2)10g下，执行$ORACLE_HOME/rdbms/admin/awrrpt.sql获取最近时间的AWR报告

3.3 获取执行计划

1）9i下可用$ORACLE_HOME/rdbms/admin/sprepsql.sql获取问题SQL的执行计划 2）10g下可用以下办法获取执行计划

$ORACLE_HOME/rdbms/admin/awrsqrpt.sql或者

select * from table(dbms_xplan.display_cursor(‘SQL_ID’)); 得到以上SQL的执行计划后

? 如保存有该SQL正常时期的执行计划，则判断和正常的执行计划是否有不同 ? 如果没有该SQL正常时期的执行计划，则需要判断执行计划是否是否恰当。

3.4 相应的处理建议

对比历史情况分析确认这些等待是否正常,SQL执行计划是否正常，确认问题SQL

对于已确认的问题SQL，评估中止该session对业务的影响：该session是否可被中止；中止后需要进行的进行的处理：是否要重新收集表的统计信息，是否要新建索引；中止该session，完成事务回滚预计需要的时间

根据评估结果选择需要执行的操作：中止session、停库重启、切应急库

第四章、整个数据库hang

现象：整个数据库hang住，无法进行任何操作。短时间内问题无法定位和解决，需要先收集信息后重新启动数据库以保证生产系统的正常使用（须先排除空间使用、权限引起的问题）

以下是收集信息的具体步骤

4.1不能使用sqlplus / as sysdba进入数据库时

确保ORACLE_SID指向问题实例后 sqlplus -prelim / as sysdba oradebug setmypid oradebug unlimit;

oradebug dump systemstate 266

注意：9206以下版本oradebug dump systemstate 266行用oradebug dump systemstate 10代替

4.2能使用sqlplus / as sysdba进入数据库时

1)登录窗口 1: $ sqlplus /nolog connect / as sysdba oradebug setmypid oradebug unlimit

oradebug hanganalyze 3 exec dbms_lock.sleep(90); oradebug hanganalyze 3 oradebug tracefile_name --得到trace文件名 exit

RAC环境，hanganalyze行为： oradebug -g def hanganalyze 3

生成的文件在数据库连接较多时可能有几百M

2) 登录窗口 2: $ sqlplus /nolog connect / as sysdba oradebug setmypid oradebug unlimit

oradebug dump systemstate 266 exec dbms_lock.sleep(90);

oradebug dump systemstate 266 oradebug tracefile_name --得到trace文件名 exit

注意：9206以下版本oradebug dump systemstate 266行用oradebug dump systemstate 10代替以上命令为单实例下收集的办法，在RAC环境中，systemstate对应的行需改为： oradebug -g all dump systemstate 266

4.3 执行RDA收集信息

cd $ORACLE_HOME/rda ksh rda.sh -fv

4.4 收集最近的STATSPACK/AWR报告

1)9i下，执行$ORACLE_HOME/rdbms/admin/spreport.sql获得STATSPACK报告也可以下办法手工获取最近几分钟的statspack报告 Sqlplus perfstat/PASSWORD

Exec statspack.snap(i_snap_level => 7); ……等待几分钟

Exec statspack.snap(i_snap_level => 7);

$ORACLE_HOME/rdbms/admin/spreport.sql

2)10g下，执行$ORACLE_HOME/rdbms/admin/awrrpt.sql获取最近时间的AWR报告

4.5 收集10G ASH报告

对10g以上版本，收集最近15分钟的ash报告

$ORACLE_HOME/rdbms/admin/ashrpt.sql\

4.6 收集10GR2的CRS信息

如果是10gR2上的RAC系统，以root运行如下命令来收集CRS信息： $env $id

$cd $ORA_CRS_HOME/bin

确认环境变量ORA_CRS_HOME/ ORACLE_BASE指向正确;HOSTNAME设为本机名后，运行：

$./diagcollection.pl -collect

第五章、数据库损坏及误操作 5.1数据库文件损坏

--SPFILE文件恢复

RMAN> startup nomount;

--通过nomount启动数据库，则会提示SPFILE问题。

　RMAN> set dbid 2090167736; --生产库的DBID为2090167736； RMAN> restore spfile from autobackup;

--系统自动搜索备份中的SPFILE，若无文件，则通过直接赋予它的文件 RMAN> restore spfile from ‘F:\\ORA\\BK_29_1_743788984’;

--生产库中的SPFILE对应的文件是在/backup目录下以C开头的文件 RMAN> shutdown immediate; RMAN> startup; --重启数据库即可。

--控制文件恢复

数据库控制文件丢失，导致数据库无法启动。

　RMAN> startup nomount; RMAN> set dbid 2090167736; --生产库的DBID为2090167736；

RMAN> restore controlfile from autobackup;

--系统自动搜索备份中的SPFILE，若无文件，则通过直接赋予它的文件 RMAN> restore controlfile from ‘F:\\ORA\\BK_28_1_743788942’; --生产库中的SPFILE对应的文件是在/backup目录下以C开头的文件 RMAN> alter database mount; RMAN> recover database;

RMAN> alter database open resetlogs;

--数据文件恢复

数据库数据文件丢失，导致数据启动报错。

　RMAN> startup nomount; RMAN> alter database mount;

RMAN> sql \ RMAN> restore datafile 4;

--若提示没有找到数据文件4的副本来恢复，可以用CATLOG语句注册下备份集 RMAN> CATALOG BACKUPPIECE ‘F:\\ORA\\BK_26_1_743788765’; RMAN> restore datafile 4; RMAN> recover datafile 4;

RMAN> sql \RMAN> alter database open;

5.2数据库表误操作

1）对误操作表对应的表空间马上进行离线操作

2) 在有限时间内尽可能通过闪回恢复被误操作的表

3）通过异机RMAN不完全恢复得到被误操作的表（步骤相对复杂） 4）通过DUL/ODU/AUL等第三方数据库恢复工具恢复被误操作的表

下载文档
收藏

分享赏