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损坏处理的实验分析了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。