实验1
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1         35   52428800          1 YES INACTIVE                872466 03-JUN-12
         2          1         37   52428800          1 NO  CURRENT                 872476 03-JUN-12
         3          1         34   52428800          1 YES INACTIVE                872459 03-JUN-12
         4          1         36   52428800          1 YES ACTIVE                  872472 03-JUN-12

SQL> shutdown abort;
ORACLE instance shut down.

先shutdown abort,再删除redo04.log

SQL> startup
ORACLE instance started.

Total System Global Area  285212672 bytes
Fixed Size                  1218992 bytes
Variable Size             104859216 bytes
Database Buffers          176160768 bytes
Redo Buffers                2973696 bytes
Database mounted.
ORA-00313: open failed for members of log group 4 of thread 1
ORA-00312: online log 4 thread 1: '/u01/app/oracle/oradata/ora10g/redo04.log'


SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1         35   52428800          1 YES INACTIVE                872466 03-JUN-12
         4          1         36   52428800          1 YES INACTIVE                872472 03-JUN-12
         3          1         34   52428800          1 YES INACTIVE                872459 03-JUN-12
         2          1         37   52428800          1 NO  CURRENT                 872476 03-JUN-12

shutdown abort不是一个类似于断电的操作吗，为什么redo04的状态由active变成了inactive了呢?

SQL> alter database clear logfile group 4;

Database altered.

SQL> alter database open;

Database altered.



实验2
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1         35   52428800          1 YES INACTIVE                872466 03-JUN-12
         2          1         37   52428800          1 YES INACTIVE                872476 03-JUN-12
         3          1         39   52428800          1 NO  CURRENT                 892634 03-JUN-12
         4          1         38   52428800          1 YES ACTIVE                  892483 03-JUN-12


先删除redo04.log,然后再shutdown abort

SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area  285212672 bytes
Fixed Size                  1218992 bytes
Variable Size             104859216 bytes
Database Buffers          176160768 bytes
Redo Buffers                2973696 bytes
Database mounted.
ORA-00313: open failed for members of log group 4 of thread 1
ORA-00312: online log 4 thread 1: '/u01/app/oracle/oradata/ora10g/redo04.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3

和实验1的错误不同了

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1         35   52428800          1 YES INACTIVE                872466 03-JUN-12
         4          1         38   52428800          1 YES ACTIVE                  892483 03-JUN-12
         3          1         39   52428800          1 NO  CURRENT                 892634 03-JUN-12
         2          1         37   52428800          1 YES INACTIVE                872476 03-JUN-12


SQL> alter database clear logfile group 4;
alter database clear logfile group 4
*
ERROR at line 1:
ORA-01624: log 4 needed for crash recovery of instance ora10g (thread 1)
ORA-00312: online log 4 thread 1: '/u01/app/oracle/oradata/ora10g/redo04.log'

如果真是这个情况，是不是只能做不完全恢复了呢？

是否是inactive，主要看的是控制文件的ckpt scn是否落在日志文件的first scn和last scn之间，第一个实验应该是redo4对应的脏数据块已经写入到了数据文件中，但是v$log还没有反映出来。
启动以后，这个很容易判断出来，因为你的控制文件没有问题。
第二个实验是一个正常的实验，数据库只能做不完全恢复了。
第一个实验是一个偶然因素，但是你要知道原因。

你主要记住第二个实验就行了，第一个实验没有具体的实战意义。

谢谢老师指点！我已经明白了。