Transcript 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文件丢失或毁坏的情况下恢复（此时数据已经丢失，
需要通过移动的方法进行重建）
•
•
•
4.
5.
•
关闭数据库
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_SEGMENTS ROLLBACK_SEGMENTS
2. 在限制方式下启动数据库
Svrmgrl> STARTUP RESTRICT MOUNT
3. 删除故障文件
Svrmgrl> ALTER DATABASE DATAFILE 'fullpath of datafile' FFLINE DROP;
4. 打开数据库:
Svrmgrl> ALTER DATABASE OPEN
如果正确执行上述语句，跳到第七步，否则继续
5. 如果第四步出错，执行下面的操作
o
在配置文件中添加:
_Corrupted_rollback_segments = (rollback1,rollback2,...,rollbackN) ，重新执行
Svrmgrl> startup restrict mount
6. 删除故障文件所包含的TABLESPACE:
Svrmgrl> drop tablespace tablespace_name including contents;
7. 重新创建TABLESPACE
8. 改变数据库状态
Svrmgrl> alter system disable restricted session;
9. 恢复配置文件
10. 重新启动数据库
1.
数据库文件故障的恢复（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 of datafile' ONLINE;
5. 确认能否从日志中恢复
• SELECT X.GROUP#, MEMBER, SEQUENCE#,
FIRST_CHANGE#FROM V$LOG X, V$LOGILE YWHERE
X.GROUP# = Y.GROUP#;
6. 如果无法恢复，有两个选择
• 从一个全备份恢复（这样会丢失数据）
• 启动这个不一致的数据库，然后REBUILD（方法如下）
1.
2.
3.
关闭数据库
备份数据库（以防万一）
修改参数文件
o 添加:
_allow_resetlogs_corruption = true
_corrupted_rollback_segments = list of all rollback segments
封掉原有的ROLLBACK_SEGMENT
4.
5.
Startup Mount
进行一次不完整的数据库恢复
6.
7.
取消恢复
重置日志文件
8.
进行一次EXPORT／IMPORT操作
Svrmgrl> RECOVER DATABASE UNTIL CANCEL;
Svrmgrl> ALTER DATABASE OPEN RESETLOGS;
数据库文件故障的恢复（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';
3. 删除所有的OFFLINE后的 rollback segments
DROP ROLLBACK SEGMENT rollback_segment;
4. 如果有些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文件恢复
1.
2.
3.
4.
5.
6.
关闭数据库
查找故障原因
非硬件故障，从MIRROR拷贝一个文件过来，然后跳到6
如果硬件故障，重新选择一个安全的卷，拷贝一个MIRROR文件
修改参数文件的CONTROL文件部分，修改文件的路径
启动数据库
数据库文件故障的恢复（9）
CONTROL文件故障（1）无镜像文件
1.
2.
3.
4.
5.
6.
7.
8.
如果没有镜像文件，恢复将十分复杂，是否有一个能够反映目前数据库
结构的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文件
1.
2.
3.
关闭数据库
查找故障原因
从MIRROR中修复毁坏的文件
数据库文件故障的恢复（11）
ONLINE Redo Log故障（1） 无MIRROR文件
1.
2.
3.
o
o
4.
5.
6.
7.
8.
关闭数据库
进行备份
修改参数文件
添加下面的行
_allow_resetlogs_corruption = true _corrupted_rollback_segments =
of all rollback segments
将ROLLBACK_SEGMENT行注释掉
Startup Mount
RECOVER DATABASE UNTIL CANCEL;
如果提示需要文件，取消
ALTER DATABASE OPEN RESETLOGS;
进行EXPORT／IMPORT重新BUILD数据库
list