1、文档名称 文档密级2020-1-9 华为机密，未经许可不得扩散 第 1 页, 共 5 页Current Redo log 损坏后恢复数据库禤梓桥 00109548关键字： 10513 事件，_allow_resetlogs_corruption，_corrupted_rollback_segments，dba_rollback_segs，ORA-6002662，ORA-6002663 ， ORA-6004136。适用场景：1. 当前 redo log 文件发生物理或逻辑损坏；且没有可用的 redo log 备份；2. 没有可用于恢复的备份；3. rman 恢复时间过长或备份太旧，不满足业务快速
2、恢复的要求。如何判定损坏日志状态为 CURRENT：1. 以 startup 启动后，检查 alert 日志，从”Started redo scan”日志信息开始如下类似的错误信息：Started redo scanORA-00313: 无法打开日志组 3 (用于线程 1) 的成员ORA-00312: 联机日志 3 线程 1: F:APPX00109548ORADATAORCLREDO03.LOGORA-27041: 无法打开文件OSD-04002: 无法打开文件O/S-Error: (OS 2) 系统找不到指定的文件。Aborting crash recovery due to error
3、313或者Started redo scanORA-368 signalled during: ALTER DATABASE OPEN.注意：如果alert只有ORA-368错误，没有报告具体的redo log文件时，需要先按照损坏redo log文件状态为非current的办法处理，当无法恢复数据库时，才按以下恢复步骤尝试恢复。2. 在 startup 启动报错后，此时数据库处于 MOUNT 状态，查看损坏的文件状态是否为 CURRENT：SQLselect member, l.status, l.group# from v$log l, v$logfile f where l.group#
4、=f.group#;MEMBER STATUS GROUP#文档名称 文档密级2020-1-9 华为机密，未经许可不得扩散 第 2 页, 共 5 页- - -F:APPX00109548ORADATAORCLREDO01.LOG INACTIVE 1F:APPX00109548ORADATAORCLREDO02.LOG INACTIVE 2F:APPX00109548ORADATAORCLREDO03.LOG CURRENT 3恢复步骤：确认损坏 redo log 文件为 current 时，执行以下操作：步骤 1：将 spfile 转存为 pfile.ora，并在 pfile.ora 文件中
5、添加_allow_resetlogs_corruption=true。1.1转存spfileSQLcreate pfile=d:pfile.ora from spfile;编辑d:pfile.ora文件，添加如下参数：*._allow_resetlogs_corruption=true1.2正常关闭数据库SQLshutdown immediate;步骤 2：以 pfile 文件启动实例并将数据库挂载SQLstartup pfile=d:pfile.ora mount;步骤 3：执行 recover database until cancel，并输入 cancelSQLrecover datab
6、ase until cancel;ORA-00279: 更改 1546960 (在 10/17/2012 09:26:37 生成) 对于线程 1 是必需的ORA-00289: 建议:F:APPX00109548PRODUCT11.1.0DB_1RDBMSARC00048_0796850999.001ORA-00280: 更改 1546960 (用于线程 1) 在序列 #48 中指定日志: =suggested | filename | AUTO | CANCELcancel alter database open resetlogs;注意：1. 此时可能打不开数据库，或者打开数据库后alert
7、日志有ORA-6002662、ORA-6002663、ORA-6004136、ORA-6004194、ORA-6004197等错误。ORA-6002662、ORA-6002663等错误通常是因为在实例崩溃时事务已经将数据块写入到数据文件中。ORA-6002023、ORA-6004136、ORA-6004194、ORA-6004197等错误是因为undo 表空间中的数据需要恢复。2. 如果SYSTEM表空间的数据损坏，将无法恢复数据库， 如果是业务用的数据文件， 考虑删除这些损坏的文件后，接着按以下操作执行。 步骤 5：在 pfile.ora 文件中增加如下参数并 MOUNT 数据库编辑d:pf
8、ile.ora文件，添加和修改如下参数：*.event=10513 trace name context forever,level 2undo_management=manual startup pfile=d:pfile.ora mount注意：startup restrict模式无法打开数据库。步骤 6：执行 recover database 操作，并打开数据库(recover database 验证数据库文件是否有问题，可不做)SQLrecover database;完成介质恢复。SQLalter database open; select segment_name, tablespa
9、ce_name, status from dba_rollback_segs;SEGMENT_NAME TABLESPACE_NAME STATUS - - - SYSTEM SYSTEM ONLINE _SYSSMU22_1350439519$ UNDOTBS1 OFFLINE _SYSSMU21_1350439519$ UNDOTBS1 OFFLINE _SYSSMU20_1350439519$ UNDOTBS1 NEEDS RECOVERY _SYSSMU19_1350439519$ UNDOTBS1 OFFLINE _SYSSMU18_1350439519$ UNDOTBS1 OFFL
10、INE _SYSSMU17_1350439519$ UNDOTBS1 OFFLINE _SYSSMU16_1350439519$ UNDOTBS1 OFFLINE _SYSSMU15_1350439519$ UNDOTBS1 OFFLINE _SYSSMU14_1350439519$ UNDOTBS1 OFFLINE _SYSSMU13_1350439519$ UNDOTBS1 OFFLINE _SYSSMU12_1350439519$ UNDOTBS1 OFFLINE 文档名称 文档密级2020-1-9 华为机密，未经许可不得扩散 第 4 页, 共 5 页注意：1. 当exp 命令在执行过程
11、中报 ORA-01555错误时，此时不要试着将UNDOTBS1空间扩大，这是因为实例崩溃时数据库中未提交事务占用了大量的回滚段，在打开数据库后undo表空间仍然有数据需要恢复，即使UNDOTBS1表空间增大，这些可用空间依然不能使用。2.UNDOTBS1表空间中存在NEEDS RECOVERY的回滚段需要记录到pfile中，并要重建该undo表空间。步骤 8：设置参数记录损坏的回滚段，重启后删除并重建 UNDOTBS1 表空间8.1 编辑d:pfile.ora 文件，添加如下参数：*._corrupted_rollback_segments=_SYSSMU20_1350439519$ #上述查
12、询中NEEDS RECOVERY状态的回滚段，如果有多个需要记录的回滚端，设置形式为：*._corrupted_rollback_segments=SEGMENT_NAME1, SEGMENT_NAME2,8.2 正常关闭数据库SQLshutdown immediate;8.3 重启数据库SQLstartup pfile=d:pfile.ora;8.4 删除UNDOTBS1表空间SQLdrop tablespace undotbs1 including contents and datafiles;8.5 重建UNDOTBS1表空间( 以下仅是样例)SQLcreate undo tablesp
13、ace undotbs1 datafile F:appx00109548oradataorclundotbs1.dbf size 8192m;步骤 9：关闭数据库，以原来的 spfile 参数文件正常启动数据库SQLshutdown immediate;SQLstartup;小结：1. 在步骤 4 打开数据库时，如果没有 ORA-6002662，ORA-6002663，ORA-6004136等错误，那么不需要执行步骤 56 的操作。这通常是事务中 DML 操作的数据块没有写到数据文件，而是在 buffer cache 中，因此不需要设置 10513 事件和_corrupted_rollback
14、_segments，这时按照步骤 9 操作，观察是否能正常打开、是否有相应的ORA-600 错误，如果没有即可正常使用。2. 在步骤 5 必须将 undo_management 修改为 manual，否则在 dba_rollback_segs 表中可能无法展现有问题的回滚段，从而在数据库正常运行中报 ORA-6002023和 ORA-6004136错误。文档名称 文档密级2020-1-9 华为机密，未经许可不得扩散 第 5 页, 共 5 页3. 当在恢复过程中发生 ORA-6002662、ORA-6002663错误，不论回滚段是否有损坏的情况，建议都重建undo 表空间，避免在业务正常运行时发
15、生 ORA-01555 错误。Redo log 损坏验证：1. 在正常的数据库中创建一张小数据表t_smalltable，模拟DML操作时，数据块完全在buffer cache的情况1.1建立t_smalltable表和索引SQLcreate table t_smalltable as select * from all_objects;SQLcreate index ix_smalltable_objectid on t_smalltable(object_id);1.2 模拟未提交事务SQLupdate t_smalltable set owner=lower(owner);1.3 在另一
16、个窗口, 以sys 用户登录将数据库强行关闭SQLconn / as sysdbaSQLshutdown abort;1.4将操作系统上的所有重做日志删除2. 在正常的数据库中创建一张大数据表t_bigtable，模拟DML操作时，有部分数据块写到磁盘的情况2.1建立t_bigtable 表SQLcreate table t_bigtable as select * from all_objects;SQLbeginfor i in 110 loopinsert into t_bigtable select * from t_bigtable;end loop;commit;end;/2.2 模拟未提交事务SQLupdate t_bigtable set owner=lower(owner);2.3 在另一个窗口, 以sys 用户登录将数据库强行关闭SQLconn / as sysdbaSQLshutdown abort;2.4将操作系统上的所有重做日志删除注意：将undotbs1表空间的总大小设置为100M左右，这时可以模拟在恢复过程中遇到的ORA-1555错误。
