Oracle 故障恢复

Oracle 故障恢复

故障恢复策略 • 确定影响恢复的因素 • 数据库的大小 • 系统的复杂性 • 数据库结构 • 应用结构（对数据库恢复影响最大） • 缩短平均恢复时间的方法 • 缩小所需要恢复的成员的大小 • 使用ORACLE表分区和索引分区技术 • 保证最新的备份能够被尽快获得 • 经常性测试备份的拷贝以保证备份的可用性 • 保证你熟悉各种各样的恢复手段，可以将经验性的技术用脚本记录下来 • 合理地设计易于维护的数据库对象

技术用法优点缺点 Export,Import, SQL*Loader 用Export/ Import 速度快实施难度大，很难确定数据的关系硬件冗余备份使用备份节点数据丢失少昂贵备用数据库用主数据库的REDO LOG更新备用数据库快速恢复，可恢复故障数据可能丢失，设置和维护复杂数据库对称复制使用ORACLE的复制功能无数据丢失，可恢复，两个数据库可以同时使用系统开销比较大，为了保持数据的一致性所进行的恢复缓慢 OPS 使用CLUSTER技术，存活的节点接管失败节点可快速恢复，负载均衡性能调整十分困难，应用设计的好坏确定了系统性能的好坏三倍镜像采用三套硬件进行镜像快速备份快速恢复三倍读写开销 EMC SRDF 工具物理I/O备份快速同步备份，恢复迅速，无数据丢失存在数据库复制冲突的可能客户化的存储转发使用O8的功能：高级对列或基于触发器的复制无数据丢失，恢复快速复杂，开销大各种故障恢复策略的比较

故障恢复的步骤 • 发现故障 • 分析故障 • 查找需要恢复的部件 • 分析需要恢复的部件的关联性 • 确定恢复策略 • 从备份环境恢复系统 • 重演REDO LOG，使系统恢复到最新的点 • 检查

分析故障，确定恢复方法 • alert log是否有报警 • 是否生成了traces • 是否使用OPS • 是否进行了恢复尝试，如果做了，做了哪些步骤 • 确定备份策略 • 如果你做了冷备份，冷备份的时候数据库是如何关闭的 • 是否使用归档日志 • 归档日志是否完整 • 在线日志是否有镜像 • 控制文件是否有镜像 • 是否有最近的全EXPORT • 数据库故障的时候有什么非常规的工作正在做 • 能够启动INSTANCE吗 • 能不能MOUNT、OPEN数据库 • 数据库大小是多少 • 是否使用裸设备 • 有多少个回滚段

数据库文件故障的恢复（1） • 故障ORA-1157, ORA-1110，或ORA－1116，ORA－1110 • 从冷备份恢复（采用NOARCHIVELOG方式） • 关闭数据库 • 恢复冷备份的文件 • 重新启动数据库 • 执行下列脚本，确认所有的REDO LOG文件的各自的流水号和FCN（first change numbers） • SELECT X.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE# FROM V$LOG X, V$LOGILE Y WHERE X.GROUP# = Y.GROUP#; • 查找要恢复文件的CHANGE＃ • SELECT FILE#, CHANGE#FROM V$RECOVER_FILE; • 如果CHANGE#大于最小的REDO LOG FIRST_CHANGE# ，那么这个文件是可以恢复的 • 用ONLINE REDO LOG恢复数据文件 • RECOVER DATAFILE 'fullpath of the datafile' • 打开数据库 • ALTER DATABASE OPEN；

数据库文件故障的恢复（2） • 从热备份恢复（使用ARCHIVELOG模式） • 关闭数据库 • 恢复冷备份的文件 • 重新启动数据库 • 执行下列脚本，确认所有的REDO LOG文件的各自的流水号和FCN（first change numbers） • SELECT X.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE# FROM V$LOG X, V$LOGILE Y WHERE X.GROUP# = Y.GROUP#; • 确认所有的日志都完备，如果日志缺少，参见后面的处理方法 • 查找要恢复文件的CHANGE＃ • SELECT FILE#, CHANGE#FROM V$RECOVER_FILE; • 如果CHANGE#大于最小的REDO LOG FIRST_CHANGE# ，那么这个文件是可以恢复的 • 用ONLINE REDO LOG恢复数据文件 • RECOVER DATAFILE 'fullpath of the datafile' • 打开数据库 • ALTER DATABASE OPEN；

数据库文件故障的恢复（3） • 有REDO LOG文件丢失或毁坏的情况下恢复（此时数据已经丢失，需要通过移动的方法进行重建） • 关闭数据库 • MOUNT数据库Svrmgrl> Startup mount • Offline drop 数据文件: • Svrmgrl> ALTER DATABASE DATAFILE 'fullpath of datafile' OFFLINE DROP; • 打开数据库 • Svrmgrl> ALTER DATABASE OPEN; • 删除用户表空间 • Svrmgrl> DROP TABLESPACE tablespace_name INCLUDING CONTENTS; • 重新创建表空间等

数据库文件故障的恢复（4） • RBS文件故障（1）数据库正常关闭情况下的恢复 • 在 INITSID.ORA文件中，封掉和故障文件相关的 ROLLBACK_SEGMENTSROLLBACK_SEGMENTS • 在限制方式下启动数据库 • Svrmgrl> STARTUP RESTRICT MOUNT • 删除故障文件 • Svrmgrl> ALTER DATABASE DATAFILE 'fullpath of datafile' FFLINE DROP; • 打开数据库: • Svrmgrl> ALTER DATABASE OPEN • 如果正确执行上述语句，跳到第七步，否则继续 • 如果第四步出错，执行下面的操作 • 在配置文件中添加: • _Corrupted_rollback_segments = (rollback1,rollback2,...,rollbackN)，重新执行 • Svrmgrl> startup restrict mount • 删除故障文件所包含的TABLESPACE: • Svrmgrl> drop tablespace tablespace_name including contents; • 重新创建TABLESPACE • 改变数据库状态 • Svrmgrl> alter system disable restricted session; • 恢复配置文件 • 重新启动数据库

数据库文件故障的恢复（5） • RBS文件故障（2）数据库非关闭情况下的恢复：由于在RBS中有一些未完成的交易，因此无法删除表空间和数据文件 • 恢复数据文件（从备份系统中） • Mount 数据库 • 查看文件是否OFFLINE • Svrmgrl> SELECT FILE#, NAME, STATUS FROM V$DATAFILE; • 如果OFFLINE，使之在线 • Svrmgrl> ALTER DATABASE DATAFILE 'full path of datafile' ONLINE; • 确认能否从日志中恢复 • SELECT X.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE#FROM V$LOG X, V$LOGILE YWHERE X.GROUP# = Y.GROUP#; • 如果无法恢复，有两个选择 • 从一个全备份恢复（这样会丢失数据） • 启动这个不一致的数据库，然后REBUILD（方法如下）

关闭数据库 • 备份数据库（以防万一） • 修改参数文件 • 添加: • _allow_resetlogs_corruption = true • _corrupted_rollback_segments = list of all rollback segments • 封掉原有的ROLLBACK_SEGMENT • Startup Mount • 进行一次不完整的数据库恢复 • Svrmgrl> RECOVER DATABASE UNTIL CANCEL; • 取消恢复 • 重置日志文件 • Svrmgrl> ALTER DATABASE OPEN RESETLOGS; • 进行一次EXPORT／IMPORT操作

数据库文件故障的恢复（6） • RBS文件故障（3）数据库还在运行 • Offline 相关的ROLLBACK_SEGMENT • ALTER ROLLBACK SEGMENT rollback_segment OFFLINE; • 确认所有的相关ROLLBACK_SEGMENT已经离线: • SELECT SEGMENT_NAME, STATUSFROM DBA_ROLLBACK_SEGSWHERE TABLESPACE_NAME = 'tablespace_name'; • 删除所有的OFFLINE后的 rollback segments • DROP ROLLBACK SEGMENT rollback_segment; • 如果有些ROLLBACK_SEGMENT无法删除，说明还有交易没有完成: • SELECT SEGMENT_NAME, XACTS ACTIVE_TX, V.STATUS • FROM V$ROLLSTAT V, DBA_ROLLBACK_SEGS • WHERE TABLESPACE_NAME = 'I' ANDSEGMENT_ID = USN; • 如果没有记录,所有的RBS已经offline.如果有PENDING OFFLINE的记录, 查找ACTIVE_TX列. 值为0 说明即将OFFLINE; 非0表示有没有提交或回退的交易，找出没有退出的SESSION，杀死这个SESSION： • ALTER SYSTEM KILL SESSION ‘XXX’;

数据库文件故障的恢复（7） • SYSTEM 表空间故障 • 如果有冷备份可以恢复系统，恢复冷备份 • 如果日志完整，可以恢复（参见前面恢复数据文件） • 如果日志不完整，无法恢复，只能重建数据库

数据库文件故障的恢复（8） • CONTROL文件故障（1）从MIRROR文件恢复 • 关闭数据库 • 查找故障原因 • 非硬件故障，从MIRROR拷贝一个文件过来，然后跳到6 • 如果硬件故障，重新选择一个安全的卷，拷贝一个MIRROR文件 • 修改参数文件的CONTROL文件部分，修改文件的路径 • 启动数据库

数据库文件故障的恢复（9） • CONTROL文件故障（1）无镜像文件 • 如果没有镜像文件，恢复将十分复杂，是否有一个能够反映目前数据库结构的TRC文件，也可以恢复；如果没有TRC文件，但数据库还可以MOUNT，可以按照下列步骤恢复： • 关闭数据库 • Startup Mount • alter database backup controlfile to trace; • 修改生成的TRC文件（删除头上的1－21行），另存为CreCtr.sql • 关闭数据库（NORMAL) • 进行一个完整的冷备份（防止意外发生） • START MOUNT • @CreCtr.sql生成CONTROL FILE • 在极端的情况下，有一个可能可以成功的方法（取决于归档日志是否完整），创建一个CONTROL文件，使用系统缺省的参数，然后进行数据库恢复

数据库文件故障的恢复（10） • ONLINE Redo Log故障（1）有MIRROR文件 • 关闭数据库 • 查找故障原因 • 从MIRROR中修复毁坏的文件

数据库文件故障的恢复（11） • ONLINE Redo Log故障（1）无MIRROR文件 • 关闭数据库 • 进行备份 • 修改参数文件 • 添加下面的行 • _allow_resetlogs_corruption = true _corrupted_rollback_segments = list of all rollback segments • 将ROLLBACK_SEGMENT行注释掉 • Startup Mount • RECOVER DATABASE UNTIL CANCEL; • 如果提示需要文件，取消 • ALTER DATABASE OPEN RESETLOGS; • 进行EXPORT／IMPORT重新BUILD数据库

Oracle 故障恢复