当前在线日志损坏，无所有数据文件备份。异常关闭(实验系列)

1)        startup mount
启动数据库到mount状态

SQL> select group#,sequence#,bytes,archived,status,first_change# from v$log;
    GROUP#  SEQUENCE#      BYTES ARC STATUS           FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
         1         59   10485760 YES ACTIVE                 3299018
         3         60   10485760 YES ACTIVE                 3299986
         2         61   10485760 NO  CURRENT                3300010

2)        SQL> select file#,name,checkpoint_change#,recover,fuzzy,checkpoint_count from v$datafile_header;
     FILE# NAME                                     CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
      ---------- ---------------------------------------- ------------------ --- --- ----------------
         1 /u02/oradata/orac10g/system01.dbf                   3299433 NO  YES              485
         2 /u02/oradata/orac10g/undotbs01.dbf                  3299433 NO  YES              249
         3 /u02/oradata/orac10g/sysaux01.dbf                   3299433 NO  YES              489
         4 /u02/oradata/orac10g/users01.dbf                    3299433 NO  YES              503
         5 /u02/oradata/orac10g/example01.dbf                  3299433 NO  YES              452

3)        SQL> select hxfil FILENUMBER,fhsta STATUS,fhscn SCN,fhrba_Seq SEQUENCE from x$kcvfh;
FILENUMBER     STATUS SCN                SEQUENCE
---------- ---------- ---------------- ----------
         1       8196 3299433                  59
         2          4 3299433                  59
         3          4 3299433                  59
         4          4 3299433                  59
         5          4 3299433                  59

我们发现要从59号日志开始前滚，还好59号日志不是当前的，而且arc=yes，说明已经归档了。那么这里至少可以前滚一个日志，说明可以不完全恢复。

在执行recover database until cancel;之前先另开一个session2

4)        session2：
set linesize 130
col name for a40
select file#,name,checkpoint_change#,recover,fuzzy,checkpoint_count from v$datafile_header;
     FILE# NAME                                CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ----------------------------------- ------------------ --- --- ----------------
         1 /u02/oradata/orac10g/system01.dbf              3299433 NO YES              483
         2 /u02/oradata/orac10g/undotbs01.dbf             3299433 NO YES              247
         3 /u02/oradata/orac10g/sysaux01.dbf              3299433 NO YES              487
         4 /u02/oradata/orac10g/users01.dbf               3299433 NO YES              501
         5 /u02/oradata/orac10g/example01.dbf             3299433 NO YES              450

5)        session1：
SQL> recover database until cancel;
ORA-00279: change 3299433 generated at 03/26/2011 06:38:30 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_59_745446891.dbf
ORA-00280: change 3299433 for thread 1 is in sequence #59

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
的确第一个是提示需要59号日志，它提示要找归档
因为我们59号在线日志已经产生了归档 arc=yes 所以我们按回车，它可以找的到,按回车之前先看一下session2

6)        session2：
SQL> /
     FILE# NAME                                CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ----------------------------------- ------------------ --- --- ----------------
         1 /u02/oradata/orac10g/system01.dbf              3299433 YES YES              483
         2 /u02/oradata/orac10g/undotbs01.dbf             3299433 YES YES              247
         3 /u02/oradata/orac10g/sysaux01.dbf              3299433 YES YES              487
         4 /u02/oradata/orac10g/users01.dbf               3299433 YES YES              501
         5 /u02/oradata/orac10g/example01.dbf             3299433 YES YES              450

发现recover变yes了
＝＝数据库文件头比较控制文件数据文件信息，发现需要RECOVER，RECOVER=YES,而且因为shutdown abort关闭的，所以FUZZY=yes

这个时候我session1还没有按回车 没用应用一个日志

大家发现什么区别没

7)        session1：
按回车
ORA-00279: change 3299986 generated at 03/26/2011 06:48:18 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_60_745446891.dbf
ORA-00280: change 3299986 for thread 1 is in sequence #60
ORA-00278: log file '/u02/oradata/1_59_745446891.dbf' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
提示要60的归档日志，因为60号在线的 arc也是等于yes 所以也没问题，按回车之前看一下session2

8)        session2：
SQL> /
     FILE# NAME                                CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ----------------------------------- ------------------ --- --- ----------------
         1 /u02/oradata/orac10g/system01.dbf              3299986 YES NO               483
         2 /u02/oradata/orac10g/undotbs01.dbf             3299986 YES NO               247
         3 /u02/oradata/orac10g/sysaux01.dbf              3299986 YES NO               487
         4 /u02/oradata/orac10g/users01.dbf               3299986 YES NO               501
         5 /u02/oradata/orac10g/example01.dbf             3299986 YES NO               450

前滚一个日志之后fuzzy变成no了，此时我们是可以打开数据库的，但我们要竟可能恢复的多的数据

＝＝应用完日志每一个日志后，我们发现FUZZY总是NO，说明介质恢复时，为确保下一个日志没有的情况下仍然能打开，

＝＝他只是先应用到该日志最后一个一致性的状态，会将该日志里没有提交的先回滚。而当仍需要下一个日志时，需要重新前滚这部分日志

9)        session1：
按回车
ORA-00279: change 3300010 generated at 03/26/2011 06:48:28 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_61_745446891.dbf
ORA-00280: change 3300010 for thread 1 is in sequence #61
ORA-00278: log file '/u02/oradata/1_60_745446891.dbf' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

提示要61号归档日志，因为61号是当前在线日志，而且已经丢失了，所以无法应用。按回车会报错，看一下session2

10)    SQL> /
     FILE# NAME                                     CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ---------------------------------------- ------------------ --- --- ----------------
         1 /u02/oradata/orac10g/system01.dbf                   3300010 YES NO               483
         2 /u02/oradata/orac10g/undotbs01.dbf                  3300010 YES NO               247
         3 /u02/oradata/orac10g/sysaux01.dbf                   3300010 YES NO               487
         4 /u02/oradata/orac10g/users01.dbf                    3300010 YES NO               501
         5 /u02/oradata/orac10g/example01.dbf                  3300010 YES NO               450

数据文件还是一致的，目前为止前滚了59，60两个归档日志

如果这个时候还想应用多一点（心比较贪），按回车之后会怎么样

11)    session1：
还是按回车
ORA-00308: cannot open archived log '/u02/oradata/1_61_745446891.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/u02/oradata/orac10g/system01.dbf'
发现报错了

12)    sesson2：
SQL> /
     FILE# NAME                                     CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ---------------------------------------- ------------------ --- --- ----------------
         1 /u02/oradata/orac10g/system01.dbf                   3300010 YES YES               483
         2 /u02/oradata/orac10g/undotbs01.dbf                  3300010 YES YES               247
         3 /u02/oradata/orac10g/sysaux01.dbf                   3300010 YES YES               487
         4 /u02/oradata/orac10g/users01.dbf                    3300010 YES YES               501
         5 /u02/oradata/orac10g/example01.dbf                  3300010 YES YES               450

我们看到数据文件现在是fuzzy=yes不一致的,
那再recover database until cancel还有用吗

13)    session1：
SQL> recover database until cancel;
ORA-00279: change 3300010 generated at 03/26/2011 06:48:28 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_61_745446891.dbf
ORA-00280: change 3300010 for thread 1 is in sequence #61
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
它直接提示要61，你再输入cancel就报1194错误，提示一个日志都无法前滚。

所以我们只能shutdown abort重新还原数据文件

当提示要61号日志文件的时候输入cancel，就完成了不完全恢复
ORA-00279: change 3300010 generated at 03/26/2011 06:48:28 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_61_745446891.dbf
ORA-00280: change 3300010 for thread 1 is in sequence #61
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recovery cancelled.

14)    session2：
SQL> select file#,name,checkpoint_change#,recover,fuzzy,checkpoint_count from v$datafile_header;
     FILE# NAME                                     CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ---------------------------------------- ------------------ --- --- ----------------
         1 /u02/oradata/orac10g/system01.dbf                   3300010 YES NO               483
         2 /u02/oradata/orac10g/undotbs01.dbf                  3300010 YES NO               247
         3 /u02/oradata/orac10g/sysaux01.dbf                   3300010 YES NO               487
         4 /u02/oradata/orac10g/users01.dbf                    3300010 YES NO               501
         5 /u02/oradata/orac10g/example01.dbf                  3300010 YES NO               450

发现fuzzy=no一致了，虽然recover=yes，但是我们没有更多的日志应用到前滚，恢复到此结束。

15)    SQL> alter database open resetlogs;
Database altered.

（手工恢复的时候至少开两个sqlplus会话，当一个个日志在应用的时候 能看见细节变化）