ORACLE数据库应急预案

中关村软件园数据中心数据库系统应急预案一、总则为了有效应对ORACLE数据库各类突发事故（事件），力争实现早发现、早报告、早控制、早解决，保护系统数据的安全，将突发公共事件造成的损失降到最低程度，制定本预案。应急处置的原则是以人为本，统一指挥，各负其责、反应迅速，处理果断、防患未然，消灭初险、及时上报，如实准确。本预案适用于ORACLE数据库可能发生突发事故（事件）的应急处置。二、基本概况ORACLE数据库当前共有*个服务器，*个实例。数据库详情列表序号应用操作系统用途关联Ip设备型号位置管理员软件体系三、应急管理机构、联系方式及职责24小时的应急联系人和电话：应急工作人员安排表中心部门成员应急电话职责全程组织与实施协助组织、故障判断排除故障、录井数据处理维护人员：四、数据库系统发生紧急状况时的处置措施数据库个别业务性能问题1、大部分业务基本正常，个别业务长时间执行未成功根据应用的pid、sid等信息，找到数据库中对应的session、SQL。得到该SQL的执行计划。1）执行$ORACLE_BASE/sql/show_spid.sql即可根据SID快速获取操作系统进行号spid的信息；2）执行$ORACLE_BASE/sql/get_by_spid.shspid，即可根据操作系统进程号依次打印执行的SQL语句和执行计划；3）执行$ORACLE_BASE/sql/showsql_pid.sql即可根据pid快速获取执行的SQL语句4）执行$ORACLE_BASE/sql/showsql_sid.sql即可根据sid快速获取执行的SQL语句如果执行计划不恰当，需要分析执行计划变化的原因（如索引不正确、统计信息过时、绑定变量偷窥等）采取相应的错误如添加缺失的索引、重新收集统计信息等，评估中止该业务的影响，尝试停止该SQL的执行后，重新收集相关表的统计信息，使业务SQL能按正确的执行计划执行。如果执行计划正确，SQL却长时间不能返回结果，则按照以下办法尽快收集必要信息，再重启任务。$sqlplus/assysdbaoradebugsetospidprocessIDoradebugunlimitoradebugdumpprocessstate10oradebugtracefile_name--得到trace文件名exit得到该进程的stack信息：$sqlplus/assysdbaoradebugsetospidprocessIDoradebugunlimitoradebugdumperrorstack3oradebugtracefile_name--得到trace文件名Exit如果PID、SID定位不到，则查询STATSPACK、AWR报告、v$session_wait和v$lock视图。1）执行$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、单个ORACLE连接进程持续非常繁忙通过top\topas\glance命令在OS上获得持续繁忙的操作系统进程号spid然后执行$ORACLE_BASE/sql/get_by_spid.shspid，即可根据操作系统进程号依次打印执行的SQL语句和执行计划；如果执行计划不恰当，需要分析执行计划变化的原因（如索引不正确、统计信息过时、绑定变量偷窥等）采取相应的错误如添加缺失的索引、重新收集统计信息等，评估中止该业务的影响，尝试停止该SQL的执行后，重新收集相关表的统计信息，使业务SQL能按正确的执行计划执行。如果执行计划正确，SQL却长时间不能返回结果，则按照以下办法尽快收集必要信息，再重启任务。$sqlplus/assysdbaoradebugsetospidprocessIDoradebugunlimitoradebugdumpprocessstate10oradebugtracefile_name--得到trace文件名exit得到该进程的stack信息：$sqlplus/assysdbaoradebugsetospidprocessIDoradebugunlimitoradebugdumperrorstack3oradebugtracefile_name--得到trace文件名Exit数据库整体性能问题现象：业务处理总体非常缓慢，但也有部分业务能够处理完成或者数据库主机CPU持续异常很高，而且都是ORACLE连接进程造成的时候请用以下方法检查1等待事件找到当前数据库等待最多的事件：使用ash工具来看最近15分钟等待事件及造成等待事件的SQL和sessionASH的收集办法：执行$ORACLE_HOME/rdbms/admin/ashrpt.sql2获取AWR报告执行$ORACLE_HOME/rdbms/admin/awrrpt.sql获取最近时间的AWR报告3获取执行计划用以下办法获取执行计划$ORACLE_HOME/rdbms/admin/awrsqrpt.sql或者select*fromtable(dbms_xplan.display_cursor('SQL_ID'));得到以上SQL的执行计划后如保存有该SQL正常时期的执行计划，则判断和正常的执行计划是否有不同如果没有该SQL正常时期的执行计划，则需要判断执行计划是否是否恰当。4相应的处理建议对比历史情况分析确认这些等待是否正常,SQL执行计划是否正常，确认问题SQL对于已确认的问题SQL，评估中止该session对业务的影响：该session是否可被中止；中止后需要进行的进行的处理：是否要重新收集表的统计信息，是否要新建索引；中止该session，完成事务回滚预计需要的时间根据评估结果选择需要执行的操作：中止session、停库重启、切应急库5不能使用sqlplus/assysdba进入数据库时确保ORACLE_SID指向问题实例后sqlplus-prelim/assysdbaoradebugsetmypidoradebugunlimit;oradebugdumpsystemstate266注意：9206以下版本oradebugdumpsystemstate266行用oradebugdumpsystemstate10代替6能使用sqlplus/assysdba进入数据库时1)登录窗口1:$sqlplus/nologconnect/assysdbaoradebugsetmypidoradebugunlimitoradebughanganalyze3execdbms_lock.sleep(90);oradebughanganalyze3oradebugtracefile_name--得到trace文件名exitRAC环境，hanganalyze行为：oradebug-gdefhanganalyze3生成的文件在数据库连接较多时可能有几百M2)登录窗口2:$sqlplus/nologconnect/assysdbaoradebugsetmypidoradebugunlimitoradebugdumpsystemstate266execdbms_lock.sleep(90);oradebugdumpsystemstate266execdbms_lock.sleep(90);oradebugdumpsystemstate266oradebugtracefile_name--得到trace文件名exit注意：9206以下版本oradebugdumpsystemstate266行用oradebugdumpsystemstate10代替以上命令为单实例下收集的办法，在RAC环境中，systemstate对应的行需改为：oradebug-galldumpsystemstate2667执行RDA收集信息cd$ORACLE_HOME/rdakshrda.sh-fv8收集最近的AWR报告执行$ORACLE_HOME/rdbms/admin/awrrpt.sql获取最近时间的AWR报告9收集ASH报告对10g以上版本，收集最近15分钟的ash报告$ORACLE_HOME/rdbms/admin/ashrpt.sql10收集的CRS信息如果是10gR2上的RAC系统，以root运行如下命令来收集CRS信息：$env$id$cd$ORA_CRS_HOME/bin确认环境变量ORA_CRS_HOME/ORACLE_BASE指向正确;HOSTNAME设为本机名后，运行：$./diagcollection.pl-collect数据库损坏及误操作1数据库文件损坏--SPFILE文件恢复RMANstartupnomount;--通过nomount启动数据库，则会提示SPFILE问题。RMANsetdbid2090167736;--生产库的DBID为2090167736；RMANrestorespfilefromautobackup;--系统自动搜索备份中的SPFILE，若无文件，则通过直接赋予它的文件RMANrestorespfilefrom'F:\ORA\BK_29_1_743788984';--生产库中的SPFILE对应的文件是在/backup目录下以C开头的文件RMANshutdownimmediate;RMANstartup;--重启数据库即可。--控制文件恢复数据库控制文件丢失，导致数据库无法启动。RMANstartupnomount;RMANsetdbid2090167736;--生产库的DBID为2090167736；RMANrestorecontrolfilefromautobackup;--系统自动搜索备份中的SPFILE，若无文件，则通过直接赋予它的文件RMANrestorecontrolfilefrom'F:\ORA\BK_28_1_743788942';--生产库中的SPFILE对应的文件是在/backup目录下以C开头的文件RMANalterdatabasemount;RMANrecoverdatabase;RMANalterdatabaseopenresetlogs;--数据文件恢复数据库数据文件丢失，导致数据启动报错。RMANstartupnomount;RMANalterdatabasemount;RMANsqlalterdatabasedatafile4offline;RMANrestoredatafile4;--若提示没有找到数据文件4的副本来恢复，可以用CATLOG语句注册下备份集RMANCATALOGBACKUPPIECE'F:\ORA\BK_26_1_743788765';RMANrestoredatafile4;RMANrecoverdatafile4;RMANsqlalterdatabasedatafile4online;RMANalterdatabaseopen;2数据库表误操作1）对误操作表对应的表空间马上进行离线操作2)在有限时间内尽可能通过闪回恢复被误操作的表3）通过异机RMAN不完全恢复得到被误操作的表（步骤相对复杂）4）通过DUL/ODU/AUL等第三方数据库恢复工具恢复被误操作的表五、30分钟内恢复业务的处置方法1、数据库系统进程故障故障现象：查看日志有报警信息事故应对：判断为数据库系统进程类故障，数据库管理员检查警告日志，根据日志错误信息判断问题所在，进行排除，如果在30分钟内还不能排除，重新启动数据库，让系统自动修复，修复不能成功，重新启动操作系统修复，还不成功，启动数据库备用恢复流程进行数据库的本机恢复；2、数据库文件丢失或损坏故障现象：数据库异常，检查警告日志中的告警信息。事故应