这期内容当中小编将会给大家带来有关Online Redo Log损坏处理的实验分析，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
Oracle核心文件包括：控制文件、数据文件和在线重做日志（Online Redo Log）。Online Redo Log和Control File分别采用数据冗余的策略进行多重路径保护。无论是Control File还是Online Redo Log Group Member，都可以指定多个完全相同的文件对象，并且将其分布在不同的存储介质上。一旦发生介质故障，如硬盘介质故障，我们可以简单的使用其他存储位置的文件进行替换。
所以，即使是在正式的生产环境下，如果设置好适当的控制文件成员组和Online Redo Log组，Control File和Online Redo Log损坏不可恢复的情况是不多见的。
但是，如果发生这样的场景，我们应该怎么进行处理呢？
1、实验环境和影响因素讨论
我们选择Oracle 10g环境进行实验。
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE 10.2.0.1.0 Production
--数据库处在归档模式下；
SQL> archive log list;
数据库日志模式 存档模式
自动存档 启用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 237
下一个存档日志序列 239
当前日志序列 239
SQL> select group#, archived, status, first_change# from v$log;
GROUP# ARCHIVED STATUS FIRST_CHANGE#
---------- -------- ---------------- -------------
1 YES INACTIVE 3567149
2 YES INACTIVE 3572305
3 NO CURRENT 3572332
在试验中，我们会在关闭数据库的时候删除Online Redo Log组成员文件。注意，在Windows环境下，由于操作系统的限制，我们是没有办法删除一个正在使用或者与实例相关的文件。
三个潜在因素可能会影响到最后结果，分别为：日志归档模式、关闭数据库方式和删除日志组状态。
日志归档模式表示Oracle是否对已经写完的online redo log member进行额外归档保存。保持一个连续的归档信息对Oracle的意义在于可以实现完全恢复complete recovery。在归档模式下，我们可以从一个过去的备份集开始，利用归档日志前推重演事务，最后应用到当前日志组，使之恢复到一个完全的恢复点上。如果日志已经归档，表示日志内容都已经写入到了数据文件中，状态必然是非Active状态。我们的实验中，数据文件并不是丢失的对象，所以已经写入数据文件的日志丢失并不会造成致命的影响。
关闭数据库方式在Oracle中有若干种，但是总的来说只有一致性关闭和非一致性关闭两个大类。一致性关闭表示Oracle在关闭数据库前，都要讲未写入的脏块写入到数据文件，控制文件和数据文件保持一致。一致性关闭条件下，Oracle在open阶段是不需要进行Instance Recovery过程的。非一致性关闭只有shutdown abort，同断电处理。非一致性关闭下Oracle在open阶段要进行instance recovery，这个过程需要redo log的配合。
删除日志状态。被删除的日志组是否是当前日志组也是一个重要因素。如果是当前日志组，就意味Oracle在启动状态需要进行读写该文件组。如果不是当前日志组被删除，也可能会有相同的问题，因为非当前日志组可能处在Active状态。
下面，我们分别进行实验。
2、完全关闭情况下非当前日志组删除
当前日志文件状态如下：
SQL> select group#, type, member from v$logfile;
GROUP# TYPE MEMBER
---------- ------- --------------------------------------------------------------------------------
3 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03A.LOG
2 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02A.LOG
1 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01A.LOG
1 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01B.LOG
3 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03B.LOG
2 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02B.LOG
6 rows selected
当前日志组号为3，关闭数据库删除日志2组文件。
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
E:\oracle\product\10.2.0\oradata\orcl>rename REDO02A.LOG REDO02A.LOG_bak
E:\oracle\product\10.2.0\oradata\orcl>rename REDO02B.LOG REDO02B.LOG_bak
E:\oracle\product\10.2.0\oradata\orcl>dir
驱动器 E 中的卷没有标签。
卷的序列号是 7CD0-C497
E:\oracle\product\10.2.0\oradata\orcl 的目录
2012-09-22 13:20 <DIR> .
2012-09-22 13:20 <DIR> ..
2012-09-22 12:04 <DIR> CHANGETRACKING
2012-09-22 13:19 7,356,416 CONTROL01.CTL
2012-09-22 13:19 7,356,416 CONTROL02.CTL
2012-09-22 13:19 7,356,416 CONTROL03.CTL
2012-09-22 13:19 104,865,792 EXAMPLE01.DBF
2012-09-22 13:19 52,429,312 REDO01A.LOG
2012-09-22 13:19 52,429,312 REDO01B.LOG
2012-09-22 13:19 52,429,312 REDO02A.LOG_bak
2012-09-22 13:19 52,429,312 REDO02B.LOG_bak
2012-09-22 13:19 52,429,312 REDO03A.LOG
2012-09-22 13:19 52,429,312 REDO03B.LOG
2012-09-22 13:19 304,095,232 SYSAUX01.DBF
（篇幅原因，省略部分内容……）
16 个文件 3,178,867,712 字节
3 个目录 204,274,311,168 可用字节
重新启动数据库，之后Oracle在mount到open阶段报错，因为不能找到控制文件中定义的日志文件。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 603979776 bytes
Fixed Size 1250380 bytes
Variable Size 155192244 bytes
Database Buffers 440401920 bytes
Redo Buffers 7135232 bytes
数据库装载完毕。
ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员
ORA-00312: 联机日志 2 线程 1:
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02A.LOG'
ORA-00312: 联机日志 2 线程 1:
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02B.LOG'
SQL> select open_mode from v$database;
OPEN_MODE
----------
MOUNTED
一般情况下，如果是完全关闭场景，我们是可以保证Oracle将online redo log中所有的内容写入到了数据文件，并且保持一致。
对非当前日志成员组，如果被误删除了，没有过多的问题，只是需要重建就好了。
SQL> alter database clear logfile group 2;
数据库已更改。
--完全开启，没有数据损失。
SQL> alter database open;
数据库已更改。
E:\oracle\product\10.2.0\oradata\orcl 的目录
2012-09-22 13:23 <DIR> .
2012-09-22 13:23 <DIR> ..
2012-09-22 12:04 <DIR> CHANGETRACKING
2012-09-22 13:20 7,356,416 CONTROL01.CTL
2012-09-22 13:20 7,356,416 CONTROL02.CTL
2012-09-22 13:20 7,356,416 CONTROL03.CTL
2012-09-22 13:19 104,865,792 EXAMPLE01.DBF
2012-09-22 13:23 <DIR> ONLINELOG
2012-09-22 13:19 52,429,312 REDO01A.LOG
2012-09-22 13:19 52,429,312 REDO01B.LOG
2012-09-22 13:23 52,429,312 REDO02A.LOG
2012-09-22 13:19 52,429,312 REDO02A.LOG_bak
2012-09-22 13:23 52,429,312 REDO02B.LOG
2012-09-22 13:19 52,429,312 REDO02B.LOG_bak
2012-09-22 13:19 52,429,312 REDO03A.LOG
2012-09-22 13:19 52,429,312 REDO03B.LOG
（篇幅原因，部分省略……）
18 个文件 3,283,726,336 字节
4 个目录 204,164,952,064 可用字节
Oracle在clear log后，重新创建了日志文件。
3、完全关闭情况下当前日志组删除
如果是完全关闭情况下当前日志组删除，我们应该怎么处理？
SQL> select group#, archived, status, first_change# from v$log;
GROUP# ARCHIVED STATUS FIRST_CHANGE#
---------- -------- ---------------- -------------
1 YES INACTIVE 3567149
2 NO CURRENT 3576416
3 YES INACTIVE 3572332
SQL> select group#, type, member from v$logfile;
GROUP# TYPE MEMBER
---------- ------- --------------------------------------------------------------------------------
3 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03A.LOG
2 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02A.LOG
1 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01A.LOG
1 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01B.LOG
3 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03B.LOG
2 ONLINE E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02B.LOG
6 rows selected
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
删除日志组成员，重新启动。
E:\oracle\product\10.2.0\oradata\orcl>rename REDO02A.LOG REDO02A.LOG_bak
E:\oracle\product\10.2.0\oradata\orcl>rename REDO02B.LOG REDO02B.LOG_bak
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 603979776 bytes
Fixed Size 1250380 bytes
Variable Size 159386548 bytes
Database Buffers 436207616 bytes
Redo Buffers 7135232 bytes
数据库装载完毕。
ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员
ORA-00312: 联机日志 2 线程 1:
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02A.LOG'
ORA-00312: 联机日志 2 线程 1:
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02B.LOG'
使用Clear方法进行恢复尝试。
SQL> alter database clear logfile group 2;
alter database clear logfile group 2
*
第 1 行出现错误:
ORA-00350: 日志 2 (实例 orcl 的日志, 线程 1) 需要归档
ORA-00312: 联机日志 2 线程 1:
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02A.LOG'
ORA-00312: 联机日志 2 线程 1:
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02B.LOG'
当前日志中内容需要归档，所以不能直接进行clear log操作。笔者猜想：如果这里是非归档模式，是否就可以成功了？事实的确如此，下面为插入的实验过程。
--当前日志组为1；
SQL> alter database clear logfile group 1;
Database altered.
SQL> alter database open;
Database altered.
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ WRITE
当前数据文件是一致性的。
SQL> select ts#, checkpoint_change#, last_change# from v$datafile;
TS# CHECKPOINT_CHANGE# LAST_CHANGE#
---------- ------------------ ------------
0 3577306 3577306
1 3577306 3577306
2 3577306 3577306
4 3577306 3577306
6 3577306 3577306
可以用recover让Oracle进行虚拟的恢复动作，恢复到最后的状态。
SQL> recover database until cancel;
完成介质恢复。
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项
SQL> alter database open resetlogs;
数据库已更改。
虽然是until cancel，但是却没有数据会损失。只是在open的时候，需要使用resetlog模式重新开启一个新的朝代。
SQL> select open_mode, current_scn from v$database;
OPEN_MODE CURRENT_SCN
---------- -----------
READ WRITE 3577513
SQL> select group#, archived, status, first_change#,sequence# from v$log;
GROUP# ARCHIVED STATUS FIRST_CHANGE# SEQUENCE#
---------- -------- ---------------- ------------- ----------
1 NO CURRENT 3577308 2
2 YES INACTIVE 3577307 1
3 YES UNUSED 0 0
结论：对于一致性关闭条件下，如果online日志组出现问题，即使发生文件丢失，也不会有数据丢失的情况，因为数据文件是一致的。
上述就是小编为大家分享的Online Redo Log损坏处理的实验分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
