数据库恢复教程.

《数据库恢复教程.》由会员分享，可在线阅读，更多相关《数据库恢复教程.（17页珍藏版）》请在金锄头文库上搜索。

1、Oracle 故障恢复 故障恢复策略 确定影响恢复的因素 数据库的大小 系统的复杂性 数据库结构 应用结构（对数据库恢复影响最大） 缩短平均恢复时间的方法 缩小所需要恢复的成员的大小 使用ORACLE表分区和索引分区技术 保证最新的备份能够被尽快获得 经常性测试备份的拷贝以保证备份的可用性 保证你熟悉各种各样的恢复手段，可以将经验性的技术用脚本记录下来 合理地设计易于维护的数据库对象 各种故障恢复策略的比较 技术用法优点缺点 Export,Import, SQL*Loader 用Export/ Import速度快实施难度大，很难确 定数据的关系 硬件冗余备份使用备份节点数据丢失少昂贵 备用数据

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

3、基于触发器 的复制 无数据丢失，恢复快 速 复杂，开销大 故障恢复的步骤 发现故障 分析故障 查找需要恢复的部件 分析需要恢复的部件的关联性 确定恢复策略 从备份环境恢复系统 重演REDO LOG，使系统恢复到最新的点 检查 分析故障，确定恢复方法 alert log是否有报警 是否生成了traces 是否使用OPS 是否进行了恢复尝试，如果做了，做了哪些步骤 确定备份策略 如果你做了冷备份，冷备份的时候数据库是如何关闭的 是否使用归档日志 归档日志是否完整 在线日志是否有镜像 控制文件是否有镜像 是否有最近的全EXPORT 数据库故障的时候有什么非常规的工作正在做 能够启动INSTANCE吗

4、 能不能MOUNT、OPEN数据库 数据库大小是多少 是否使用裸设备 有多少个回滚段 数据库文件故障的恢复（1） 故障ORA-1157, ORA-1110 ，或ORA1116，ORA1110 从冷备份恢复（采用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.GROU

5、P#; 1.查找要恢复文件的CHANGE SELECT FILE#, CHANGE#FROM V$RECOVER_FILE; 如果CHANGE#大于最小的REDO LOG FIRST_CHANGE# ，那么这个文件是可 以恢复的 1.用ONLINE REDO LOG恢复数据文件 RECOVER DATAFILE fullpath of the datafile 1.打开数据库 ALTER DATABASE OPEN ； 数据库文件故障的恢复（2） 从热备份恢复（使用ARCHIVELOG 模式） 关闭数据库 恢复冷备份的文件 重新启动数据库 执行下列脚本，确认所有的REDO LOG文件的各自的流

6、水号和FCN （first change numbers） SELECT X.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE# FROM V$LOG X, V$LOGILE Y WHERE X.GROUP# = Y.GROUP#; 1.确认所有的日志都完备，如果日志缺少，参见后面的处理方法 2.查找要恢复文件的CHANGE SELECT FILE#, CHANGE#FROM V$RECOVER_FILE; 如果CHANGE#大于最小的REDO LOG FIRST_CHANGE# ，那么这个文件是可 以恢复的 1.用ONLINE REDO LOG恢复数据文件 RE

7、COVER DATAFILE fullpath of the datafile 1.打开数据库 ALTER DATABASE OPEN ； 数据库文件故障的恢复（3） 有REDO LOG文件丢失或毁坏的情况下恢复（此时数据已经丢失 ，需要通过移动的方法进行重建） 关闭数据库 MOUNT数据库Svrmgrl Startup mount Offline drop 数据文件: Svrmgrl ALTER DATABASE DATAFILE fullpath of datafile OFFLINE DROP; 4.打开数据库 1. Svrmgrl ALTER DATABASE OPEN; 5.删除用户

8、表空间 1. Svrmgrl DROP TABLESPACE tablespace_name INCLUDING CONTENTS; 2.重新创建表空间等 数据库文件故障的恢复（4） RBS文件故障（1）数据库正常关闭情况下的恢复 1.在 INITSID.ORA文件中，封掉和故障文件相关的 ROLLBACK_SEGMENTS ROLLBACK_SEGMENTS 2.在限制方式下启动数据库 Svrmgrl STARTUP RESTRICT MOUNT 3.删除故障文件 Svrmgrl ALTER DATABASE DATAFILE fullpath of datafile FFLINE DROP

9、; 4.打开数据库: Svrmgrl ALTER DATABASE OPEN 如果正确执行上述语句，跳到第七步，否则继续 5.如果第四步出错，执行下面的操作 1. 在配置文件中添加: _Corrupted_rollback_segments = (rollback1,rollback2,.,rollbackN) ，重新执行 Svrmgrl startup restrict mount 6.删除故障文件所包含的TABLESPACE: Svrmgrl drop tablespace tablespace_name including contents; 7.重新创建TABLESPACE 8.改变数

10、据库状态 Svrmgrl alter system disable restricted session; 9.恢复配置文件 10. 重新启动数据库 数据库文件故障的恢复（5） RBS文件故障（2）数据库非关闭情况下的恢复：由于在RBS中有一些 未完成的交易，因此无法删除表空间和数据文件 1.恢复数据文件（从备份系统中） 2.Mount 数据库 3.查看文件是否OFFLINE Svrmgrl SELECT FILE#, NAME, STATUS FROM V$DATAFILE; 4.如果OFFLINE，使之在线 Svrmgrl ALTER DATABASE DATAFILE full path

11、 of datafile ONLINE; 5.确认能否从日志中恢复 SELECT X.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE#FROM V$LOG X, V$LOGILE YWHERE X.GROUP# = Y.GROUP#; 6.如果无法恢复，有两个选择 1.从一个全备份恢复（这样会丢失数据） 启动这个不一致的数据库，然后REBUILD（方法如下） 1.关闭数据库 2.备份数据库（以防万一） 3.修改参数文件 o添加: _allow_resetlogs_corruption = true _corrupted_rollback_segments = l

12、ist of all rollback segments 封掉原有的ROLLBACK_SEGMENT 1.Startup Mount 2.进行一次不完整的数据库恢复 1.Svrmgrl RECOVER DATABASE UNTIL CANCEL; 3.取消恢复 4.重置日志文件 Svrmgrl ALTER DATABASE OPEN RESETLOGS; 1.进行一次EXPORTIMPORT操作 数据库文件故障的恢复（6） RBS文件故障（3）数据库还在运行 Offline 相关的ROLLBACK_SEGMENT ALTER ROLLBACK SEGMENT rollback_segment

13、OFFLINE; 确认所有的相关ROLLBACK_SEGMENT已经离线: SELECT SEGMENT_NAME, STATUSFROM DBA_ROLLBACK_SEGSWHERE TABLESPACE_NAME = tablespace_name; 3.删除所有的OFFLINE后的 rollback segments 1. DROP ROLLBACK SEGMENT rollback_segment; 4.如果有些ROLLBACK_SEGMENT无法删除，说明还有交易没有完成: SELECT SEGMENT_NAME, XACTS ACTIVE_TX, V.STATUS FROM V$R

14、OLLSTAT 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 表空间故障 如果有冷备份可以恢复系统，恢复冷备份 如果日志完整，可以恢复（参见前面恢复数据

15、文件） 如果日志不完整，无法恢复，只能重建数据库 数据库文件故障的恢复（8） CONTROL文件故障（1）从MIRROR文件恢复 1.关闭数据库 2.查找故障原因 3.非硬件故障，从MIRROR拷贝一个文件过来，然后跳到6 4.如果硬件故障，重新选择一个安全的卷，拷贝一个MIRROR文件 5.修改参数文件的CONTROL文件部分，修改文件的路径 6.启动数据库 数据库文件故障的恢复（9） CONTROL文件故障（1）无镜像文件 如果没有镜像文件，恢复将十分复杂，是否有一个能够反映目前数据库 结构的TRC文件，也可以恢复；如果没有TRC文件，但数据库还可以 MOUNT，可以按照下列步骤恢复： 1.关闭数据库 2.Startup Mount 3.alter database backup controlfile to trace; 4.修改生成的TRC文件（删除头上的121行），另存为CreCtr.sql 5.关闭数据库（NORMAL) 6.进行一个完整的冷备份（防止意外发生） 7.START MOUNT 8.CreCtr.sql生成CONTROL FILE 在极端的情况下，有一个可能可以成功的方法（取决于归档日志是否完整 ），创建一个CONTROL文件，使用系统缺省的参数，然后进行数据库 恢复 数据库文件故障的恢复（10