控制文件resetlogs方式创建，有活动在线日志，当前在线日志损坏，并异常关闭(实验系列)
2011-11-25 15:30
411 查看
实验步骤：
1. SQL> truncate table t1;
Table truncated.
2. SQL> select group#,sequence#,bytes,archived,status,first_change# from v$log;
GROUP# SEQUENCE# BYTES ARC STATUS FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
1 0 10485760 YES UNUSED 0
2 0 10485760 YES UNUSED 0
3 1 10485760 NO CURRENT 3300998
3. insert into t1
select dbms_flashback.get_system_change_number
from (select rownum from dba_objects where rownum <= 1000) a,
(select rownum from dba_objects where rownum <= 1000) b;
commit;
4. SQL> select group#,sequence#,bytes,archived,status,first_change# from v$log;
GROUP# SEQUENCE# BYTES ARC STATUS FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
1 2 10485760 NO CURRENT 3303611
2 0 10485760 YES UNUSED 0
3 1 10485760 YES ACTIVE 3300998
5. SQL> select min(scn) ,max(scn) from t1;
MIN(SCN) MAX(SCN)
---------- ----------
3303561 3303632
6. T1的redo，落在1,2日志上。
7. SQL> alter system switch logfile;
System altered.
8. SQL> select group#,sequence#,bytes,archived,status,first_change# from v$log;
GROUP# SEQUENCE# BYTES ARC STATUS FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
1 2 10485760 YES ACTIVE 3303611
2 3 10485760 NO CURRENT 3303663
3 1 10485760 YES ACTIVE 3300998
9. SQL> alter database backup controlfile to trace as '/tmp/ctl.sql' reuse;
Database altered.
10. SQL> shutdown abort
ORACLE instance shut down.
11. 我们模拟active的和current的日志文件都损坏，所以这里我把日志都移走了
12. SQL> ! mv $ORACLE_BASE/oradata/$ORACLE_SID/redo0* /tmp
13. SQL> ! ls -l /tmp/redo*
-rw-r----- 1 oracle10g oinstall 10486272 Mar 26 08:21 /tmp/redo01.log
-rw-r----- 1 oracle10g oinstall 10486272 Mar 26 08:21 /tmp/redo02.log
-rw-r----- 1 oracle10g oinstall 10486272 Mar 26 08:25 /tmp/redo03.log
14. 这个时候startup肯定报错
15. 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 3 of thread 1
ORA-00312: online log 3 thread 1: '/u02/oradata/orac10g/redo03.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
16. 备份一下控制文件看一下数据文件信息
17. SQL> select file#,name,checkpoint_change#,recover,fuzzy,checkpoint_count from v$datafile_header;
FILE# NAME CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUN
-------- ---------------------------------------- ------------------ --- --- ----------------
1 /u02/oradata/orac10g/system01.dbf 3300999 NO YES 497
2 /u02/oradata/orac10g/undotbs01.dbf 3300999 NO YES 261
3 /u02/oradata/orac10g/sysaux01.dbf 3300999 NO YES 501
4 /u02/oradata/orac10g/users01.dbf 3300999 NO YES 515
5 /u02/oradata/orac10g/example01.dbf 3300999 NO YES 464
18. （数据库需要崩溃恢复）
19. SQL> ! cp $ORACLE_BASE/oradata/$ORACLE_SID/*.dbf /tmp
SQL> ! cp $ORACLE_BASE/oradata/$ORACLE_SID/*.ctl /tmp
20. SQL> ! ls -l /tmp/*.ctl
-rw-r----- 1 oracle10g oinstall 7454720 Mar 26 06:42 /tmp/control01.ctl
-rw-r----- 1 oracle10g oinstall 7454720 Mar 26 06:42 /tmp/control02.ctl
-rw-r----- 1 oracle10g oinstall 7454720 Mar 26 06:42 /tmp/control03.ctl
SQL> ! ls -l /tmp/*.dbf
-rw-r----- 1 oracle10g oinstall 222830592 Mar 26 06:41 /tmp/example01.dbf
-rw-r----- 1 oracle10g oinstall 293609472 Mar 26 06:41 /tmp/sysaux01.dbf
-rw-r----- 1 oracle10g oinstall 534781952 Mar 26 06:41 /tmp/system01.dbf
-rw-r----- 1 oracle10g oinstall 209723392 Mar 26 06:41 /tmp/temp01.dbf
-rw-r----- 1 oracle10g oinstall 104865792 Mar 26 06:42 /tmp/undotbs01.dbf
-rw-r----- 1 oracle10g oinstall 18358272 Mar 26 06:42 /tmp/users01.dbf
这里我们并没有还原数据文件，刚才的备份只是保留故障现场做的备份
21. 另开一个session2：
col name for a40
set linesize 130
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 3300999 NO YES 497
2 /u02/oradata/orac10g/undotbs01.dbf 3300999 NO YES 261
3 /u02/oradata/orac10g/sysaux01.dbf 3300999 NO YES 501
4 /u02/oradata/orac10g/users01.dbf 3300999 NO YES 515
5 /u02/oradata/orac10g/example01.dbf 3300999 NO YES 464
22. session1：
SQL> recover database until cancel;
ORA-00279: change 3300999 generated at 03/26/2011 09:45:15 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_1_746790312.dbf
ORA-00280: change 3300999 for thread 1 is in sequence #1
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
按回车
23. session2：
SQL> /
FILE# NAME CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ---------------------------------------- ------------------ --- --- ----------------
1 /u02/oradata/orac10g/system01.dbf 3303611 NO YES 497
2 /u02/oradata/orac10g/undotbs01.dbf 3303611 NO YES 261
3 /u02/oradata/orac10g/sysaux01.dbf 3303611 NO YES 501
4 /u02/oradata/orac10g/users01.dbf 3303611 NO YES 515
5 /u02/oradata/orac10g/example01.dbf 3303611 NO YES 464
我们发现这里虽然前滚了日志1，但是fuzzy并没有变成no，数据文件还是不一致的。
数据文件并没有还原 实际上oracle认为是崩溃恢复
要把active和current的在线日志全部应用才能恢复到数据文件一致
24. SQL> select group#,sequence#,bytes,archived,status,first_change# from v$log;
GROUP# SEQUENCE# BYTES ARC STATUS FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
1 2 10485760 YES ACTIVE 3303611
2 3 10485760 NO CURRENT 3303663
3 1 10485760 YES ACTIVE 3300998
25. SQL> select min(scn) ,max(scn) from t1;
MIN(SCN) MAX(SCN)
---------- ----------
3303561 3303632
26. session1：
ORA-00279: change 3303611 generated at 03/26/2011 10:40:04 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_2_746790312.dbf
ORA-00280: change 3303611 for thread 1 is in sequence #2
ORA-00278: log file '/u02/oradata/1_1_746790312.dbf' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
按回车，前滚日志2
27. session2：
SQL> /
FILE# NAME CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ---------------------------------------- ------------------ --- --- ----------------
1 /u02/oradata/orac10g/system01.dbf 3303663 NO YES 497
2 /u02/oradata/orac10g/undotbs01.dbf 3303663 NO YES 261
3 /u02/oradata/orac10g/sysaux01.dbf 3303663 NO YES 501
4 /u02/oradata/orac10g/users01.dbf 3303663 NO YES 515
5 /u02/oradata/orac10g/example01.dbf 3303663 NO YES 464
我们发现还是不行
28. session1：
ORA-00279: change 3303663 generated at 03/26/2011 10:41:14 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_3_746790312.dbf
ORA-00280: change 3303663 for thread 1 is in sequence #3
ORA-00278: log file '/u02/oradata/1_2_746790312.dbf' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
29. 提示要3，但是3号日志是当前的，不可能有归档日志文件，而且我们的当前在线日志又移走了。
所以这里就无法恢复了
30. 按回车后报错
ORA-00308: cannot open archived log '/u02/oradata/1_3_746790312.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'
31. 我们为了实验连贯性，就把移走的当前日志应用到前滚中
32. SQL> recover database until cancel;
ORA-00279: change 3303663 generated at 03/26/2011 10:41:14 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_3_746790312.dbf
ORA-00280: change 3303663 for thread 1 is in sequence #3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/tmp/redo02.log
Log applied.
Media recovery complete.
输入当前在线日志redo02.log的路径，完成恢复了，数据没丢
33. session2：
SQL> /
FILE# NAME CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ---------------------------------------- ------------------ --- --- ----------------
1 /u02/oradata/orac10g/system01.dbf 3303678 NO NO 498
2 /u02/oradata/orac10g/undotbs01.dbf 3303678 NO NO 262
3 /u02/oradata/orac10g/sysaux01.dbf 3303678 NO NO 502
4 /u02/oradata/orac10g/users01.dbf 3303678 NO NO 516
5 /u02/oradata/orac10g/example01.dbf 3303678 NO NO 465
这里fuzzy也变成no了，说明数据文件一致了。
34. SQL> alter database open resetlogs;
Database altered.
35. SQL> select MIN(SCN),MAX(SCN) from t1;
MIN(SCN) MAX(SCN)
---------- ----------
3303561 3303632（前滚所有日志，数据没有丢失）
总结：不关控制文件是当前的还是重建的或者备份的，只要当前在线日志坏了，或者非当前的当没有生成归档的在线日志坏了，那么在没有备份的情况下，是无法恢复的，只能隐含参数打开数据库。在有备份的情况下可以不完全恢复的。
1. SQL> truncate table t1;
Table truncated.
2. SQL> select group#,sequence#,bytes,archived,status,first_change# from v$log;
GROUP# SEQUENCE# BYTES ARC STATUS FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
1 0 10485760 YES UNUSED 0
2 0 10485760 YES UNUSED 0
3 1 10485760 NO CURRENT 3300998
3. insert into t1
select dbms_flashback.get_system_change_number
from (select rownum from dba_objects where rownum <= 1000) a,
(select rownum from dba_objects where rownum <= 1000) b;
commit;
4. SQL> select group#,sequence#,bytes,archived,status,first_change# from v$log;
GROUP# SEQUENCE# BYTES ARC STATUS FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
1 2 10485760 NO CURRENT 3303611
2 0 10485760 YES UNUSED 0
3 1 10485760 YES ACTIVE 3300998
5. SQL> select min(scn) ,max(scn) from t1;
MIN(SCN) MAX(SCN)
---------- ----------
3303561 3303632
6. T1的redo，落在1,2日志上。
7. SQL> alter system switch logfile;
System altered.
8. SQL> select group#,sequence#,bytes,archived,status,first_change# from v$log;
GROUP# SEQUENCE# BYTES ARC STATUS FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
1 2 10485760 YES ACTIVE 3303611
2 3 10485760 NO CURRENT 3303663
3 1 10485760 YES ACTIVE 3300998
9. SQL> alter database backup controlfile to trace as '/tmp/ctl.sql' reuse;
Database altered.
10. SQL> shutdown abort
ORACLE instance shut down.
11. 我们模拟active的和current的日志文件都损坏，所以这里我把日志都移走了
12. SQL> ! mv $ORACLE_BASE/oradata/$ORACLE_SID/redo0* /tmp
13. SQL> ! ls -l /tmp/redo*
-rw-r----- 1 oracle10g oinstall 10486272 Mar 26 08:21 /tmp/redo01.log
-rw-r----- 1 oracle10g oinstall 10486272 Mar 26 08:21 /tmp/redo02.log
-rw-r----- 1 oracle10g oinstall 10486272 Mar 26 08:25 /tmp/redo03.log
14. 这个时候startup肯定报错
15. 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 3 of thread 1
ORA-00312: online log 3 thread 1: '/u02/oradata/orac10g/redo03.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
16. 备份一下控制文件看一下数据文件信息
17. SQL> select file#,name,checkpoint_change#,recover,fuzzy,checkpoint_count from v$datafile_header;
FILE# NAME CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUN
-------- ---------------------------------------- ------------------ --- --- ----------------
1 /u02/oradata/orac10g/system01.dbf 3300999 NO YES 497
2 /u02/oradata/orac10g/undotbs01.dbf 3300999 NO YES 261
3 /u02/oradata/orac10g/sysaux01.dbf 3300999 NO YES 501
4 /u02/oradata/orac10g/users01.dbf 3300999 NO YES 515
5 /u02/oradata/orac10g/example01.dbf 3300999 NO YES 464
18. （数据库需要崩溃恢复）
19. SQL> ! cp $ORACLE_BASE/oradata/$ORACLE_SID/*.dbf /tmp
SQL> ! cp $ORACLE_BASE/oradata/$ORACLE_SID/*.ctl /tmp
20. SQL> ! ls -l /tmp/*.ctl
-rw-r----- 1 oracle10g oinstall 7454720 Mar 26 06:42 /tmp/control01.ctl
-rw-r----- 1 oracle10g oinstall 7454720 Mar 26 06:42 /tmp/control02.ctl
-rw-r----- 1 oracle10g oinstall 7454720 Mar 26 06:42 /tmp/control03.ctl
SQL> ! ls -l /tmp/*.dbf
-rw-r----- 1 oracle10g oinstall 222830592 Mar 26 06:41 /tmp/example01.dbf
-rw-r----- 1 oracle10g oinstall 293609472 Mar 26 06:41 /tmp/sysaux01.dbf
-rw-r----- 1 oracle10g oinstall 534781952 Mar 26 06:41 /tmp/system01.dbf
-rw-r----- 1 oracle10g oinstall 209723392 Mar 26 06:41 /tmp/temp01.dbf
-rw-r----- 1 oracle10g oinstall 104865792 Mar 26 06:42 /tmp/undotbs01.dbf
-rw-r----- 1 oracle10g oinstall 18358272 Mar 26 06:42 /tmp/users01.dbf
这里我们并没有还原数据文件，刚才的备份只是保留故障现场做的备份
21. 另开一个session2：
col name for a40
set linesize 130
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 3300999 NO YES 497
2 /u02/oradata/orac10g/undotbs01.dbf 3300999 NO YES 261
3 /u02/oradata/orac10g/sysaux01.dbf 3300999 NO YES 501
4 /u02/oradata/orac10g/users01.dbf 3300999 NO YES 515
5 /u02/oradata/orac10g/example01.dbf 3300999 NO YES 464
22. session1：
SQL> recover database until cancel;
ORA-00279: change 3300999 generated at 03/26/2011 09:45:15 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_1_746790312.dbf
ORA-00280: change 3300999 for thread 1 is in sequence #1
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
按回车
23. session2：
SQL> /
FILE# NAME CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ---------------------------------------- ------------------ --- --- ----------------
1 /u02/oradata/orac10g/system01.dbf 3303611 NO YES 497
2 /u02/oradata/orac10g/undotbs01.dbf 3303611 NO YES 261
3 /u02/oradata/orac10g/sysaux01.dbf 3303611 NO YES 501
4 /u02/oradata/orac10g/users01.dbf 3303611 NO YES 515
5 /u02/oradata/orac10g/example01.dbf 3303611 NO YES 464
我们发现这里虽然前滚了日志1，但是fuzzy并没有变成no，数据文件还是不一致的。
数据文件并没有还原 实际上oracle认为是崩溃恢复
要把active和current的在线日志全部应用才能恢复到数据文件一致
24. SQL> select group#,sequence#,bytes,archived,status,first_change# from v$log;
GROUP# SEQUENCE# BYTES ARC STATUS FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
1 2 10485760 YES ACTIVE 3303611
2 3 10485760 NO CURRENT 3303663
3 1 10485760 YES ACTIVE 3300998
25. SQL> select min(scn) ,max(scn) from t1;
MIN(SCN) MAX(SCN)
---------- ----------
3303561 3303632
26. session1：
ORA-00279: change 3303611 generated at 03/26/2011 10:40:04 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_2_746790312.dbf
ORA-00280: change 3303611 for thread 1 is in sequence #2
ORA-00278: log file '/u02/oradata/1_1_746790312.dbf' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
按回车，前滚日志2
27. session2：
SQL> /
FILE# NAME CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ---------------------------------------- ------------------ --- --- ----------------
1 /u02/oradata/orac10g/system01.dbf 3303663 NO YES 497
2 /u02/oradata/orac10g/undotbs01.dbf 3303663 NO YES 261
3 /u02/oradata/orac10g/sysaux01.dbf 3303663 NO YES 501
4 /u02/oradata/orac10g/users01.dbf 3303663 NO YES 515
5 /u02/oradata/orac10g/example01.dbf 3303663 NO YES 464
我们发现还是不行
28. session1：
ORA-00279: change 3303663 generated at 03/26/2011 10:41:14 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_3_746790312.dbf
ORA-00280: change 3303663 for thread 1 is in sequence #3
ORA-00278: log file '/u02/oradata/1_2_746790312.dbf' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
29. 提示要3，但是3号日志是当前的，不可能有归档日志文件，而且我们的当前在线日志又移走了。
所以这里就无法恢复了
30. 按回车后报错
ORA-00308: cannot open archived log '/u02/oradata/1_3_746790312.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'
31. 我们为了实验连贯性，就把移走的当前日志应用到前滚中
32. SQL> recover database until cancel;
ORA-00279: change 3303663 generated at 03/26/2011 10:41:14 needed for thread 1
ORA-00289: suggestion : /u02/oradata/1_3_746790312.dbf
ORA-00280: change 3303663 for thread 1 is in sequence #3
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/tmp/redo02.log
Log applied.
Media recovery complete.
输入当前在线日志redo02.log的路径，完成恢复了，数据没丢
33. session2：
SQL> /
FILE# NAME CHECKPOINT_CHANGE# REC FUZ CHECKPOINT_COUNT
---------- ---------------------------------------- ------------------ --- --- ----------------
1 /u02/oradata/orac10g/system01.dbf 3303678 NO NO 498
2 /u02/oradata/orac10g/undotbs01.dbf 3303678 NO NO 262
3 /u02/oradata/orac10g/sysaux01.dbf 3303678 NO NO 502
4 /u02/oradata/orac10g/users01.dbf 3303678 NO NO 516
5 /u02/oradata/orac10g/example01.dbf 3303678 NO NO 465
这里fuzzy也变成no了，说明数据文件一致了。
34. SQL> alter database open resetlogs;
Database altered.
35. SQL> select MIN(SCN),MAX(SCN) from t1;
MIN(SCN) MAX(SCN)
---------- ----------
3303561 3303632（前滚所有日志，数据没有丢失）
总结：不关控制文件是当前的还是重建的或者备份的，只要当前在线日志坏了，或者非当前的当没有生成归档的在线日志坏了，那么在没有备份的情况下，是无法恢复的，只能隐含参数打开数据库。在有备份的情况下可以不完全恢复的。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 当前在线日志损坏，无所有数据文件备份。异常关闭(实验系列)
- 已归档的活动在线日志损坏，异常关闭(实验系列)
- 数据文件offline，未归档的非活动在线日志或当前在线日志损坏，在线修复(实验系列)
- ARCHIVELOG模式下用户管理恢复联机重做日志文件（2）——当前活动组所有成员全部损坏！
- ARCHIVELOG模式下用户管理恢复联机重做日志文件—当前活动组所有成员全部损坏
- 控制PHP的错误输出方式:直接输出至荧幕或将错误信息记录到错误日志文件内
- 控制PHP的错误输出方式:直接输出至荧幕或将错误信息记录到错误日志文件内
- ★实验 8-2 1. 创建两个守候进程。每个守候进程各自创建独立的日志文件。 2. 每隔 1s 向日志文件中写入如下信息: a) 守候进程 1：未使用的内存大小(MemFree) b) 守
- VMware workstation -- 实验环境搭建系列(二) 使用 Custom 方式创建一个新虚拟机
- 异常处理&创建日志文件
- rman实验之归档模式，正常关机丢失非当前的联机重做日志文件
- 控制文件丢失，但有二进制备份，数据文件丢失，没有备份(实验系列)
- 子进程会继承父进程用户id，用户组id，用户信息，文件描述符，数据段，堆栈，当前工作目录，创建文件权限，信号处理方式，进程组号，会话期号。
- 安卓系列一（创建文件权限的四种常用方式）
- 日志文件损坏恢复（实验）
- 小实验：用创建进程（）打开计算器，然后关闭进程句柄。再用打开进程（进程ID），使用两次，得到两个进程句柄。实验目的：这两个进程句柄都能控制这个进程吗？通过该试验加深对句柄的理解！！
- 当前控制文件损坏_不完全恢复_用控制文件二进制备份_数据不丢_不需备份
- 控制文件恢复实验系列（1）
- 数据库open时，回滚数据文件丢失，无备份，有活动事务(实验系列)
- rman实验之归档模式无备份，正常关机丢失当前联机重做日志文件的恢复