Oracle 备份恢复 31个实验 7-12
2012-10-07 12:47
267 查看
备份恢复实验之七
基于时间的不完全恢复（举个例子，你10：00删除了一张表，可事后你发现误删了，那你就要将数据库的时间回退到9：59，也就是回退到这张表还在的时刻，这里当然不是说表被误删就一定要采用传统的备份恢复的方法来恢复，你完全可以通过闪回FLASHBACK来恢复，前提是还在回收站中，这里不讨论闪回恢复，这里只是做实验，OK？）
SQL> conn hr/hr
Connected.
SQL> drop tabletest;
drop table test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('empoli');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
empoli
SQL> selectsysdate from dual;
SYSDATE
------------
11-JAN-11
SQL> altersession set nls_date_format='yyyy-mm-dd:hh24:mi:ss';
Session altered.
SQL> selectsysdate from dual;
SYSDATE
-------------------
2011-01-11:11:36:24
SQL> altersystem switch logfile;（模拟一下生产环境的切换日志，因为你最后是要OPEN
RESETLOGS的，粒度是一个日志，你不切的话，按照我的理解，整个日志上的数据你都找不到了，看不懂的先往下）
System altered.
SQL> altersystem switch logfile;
System altered.
Droptable test;
（有些人就想了，我只恢复TEST这张表的表空间就行了嘛。告诉你，不行？因为日志已经走到“现在”，要想回退到之前的时间点，就要所有表空间（或者说所有数据文件）一齐回到之前的时间点，很正常啊。你想想，你腿是昨天的，胳膊是现在的，可能吗？）
SQL> conn / assysdba
Connected.
SQL> shutdownabort
ORACLE instanceshut down.（生产环境禁止！我们现在只是做实验）
SQL> conn / assysdba
Connected to anidle instance.
SQL> startupmount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 121635472 bytes
DatabaseBuffers 327155712 bytes
Redo Buffers 2973696 bytes
Database mounted.
在使用RMAN恢复之前，请先将RMAN的时间格式变量先设好，不然到时恢复的时候时间格式认不到，明白？看下面：
[root@ocpdb ~]# su - oracle
[oracle@ocpdb ~]$ echo $NLS_DATE_FORMAT
[oracle@ocpdb ~]$ export NLS_DATE_FORMAT='yyyy-mm-dd:hh24:mi:ss'
[oracle@ocpdb ~]$ echo $NLS_DATE_FORMAT
yyyy-mm-dd:hh24:mi:ss
[oracle@ocpdbbackup]$ rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Tue Jan 11 11:42:47 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: ORCL (DBID=1266235128, not open)
RMAN> listbackup;（截取一段）
BS Key Type LV Size
Device Type Elapsed Time CompletionTime
------- ---- ------------ ----------- ------------ -------------------
13 Full 6.83M
DISK 00:00:01 2011-01-11:11:23:14
BP Key: 13
Status: AVAILABLE Compressed: NO Tag: TAG20110111T112313
Piece Name:/home/oracle/app/oracle/flash_recovery_area/ORCL/autobackup/2011_01_11/o1_mf_s_740143393_6lqm927v_.bkp
Control File Included: Ckp SCN: 975815
Ckp time: 2011-01-11:11:23:13
SPFILE Included: Modification time:
2011-01-11:11:19:35
RMAN> restoredatabase;（敲下去，要将旧的数据拷回来，走日志，明白？）
Starting restoreat 2011-01-11:11:43:22
using targetdatabase control file instead of recovery catalog
allocated channel:ORA_DISK_1
channelORA_DISK_1: sid=155 devtype=DISK
channelORA_DISK_1: starting datafile backupset restore
channelORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile00001 to/home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_system_6k5t18qg_.dbf
restoring datafile00002 to /home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_6k5t18td_.dbf
restoring datafile00003 to/home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_6k5t18qx_.dbf
restoring datafile00004 to/home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_users_6k5t18v3_.dbf
restoring datafile00005 to/home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_example_6k5t4xxc_.dbf
restoring datafile00006 to /home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_test_6kjb532l_.dbf
restoring datafile00007 to /home/oracle/app/oracle/oradata/ORCL/datafile/tets02.dbf
channelORA_DISK_1: reading from backup piece/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_11/o1_mf_nnndf_TAG20110111T112055_6lqm4qnd_.bkp
之前表还在的时间还记得住吗？这句是为什么我SELECT SYSDATE FROM DUAL;
2011-01-11:11:36:24
RMAN> recoverdatabase until time '2011-01-11:11:36:24';
Starting recoverat 2011-01-11:11:56:01
using channelORA_DISK_1
starting mediarecovery
archive log thread1 sequence 47 is already on disk as file/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_11/o1_mf_1_47_6lqn42s6_.arc
channelORA_DISK_1: starting archive log restore to default destination
channelORA_DISK_1: restoring archive log
archive logthread=1 sequence=46
channelORA_DISK_1: reading from backup piece/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_11/o1_mf_annnn_TAG20110111T112311_6lqm90jq_.bkp
channelORA_DISK_1: restored backup piece 1
piecehandle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_11/o1_mf_annnn_TAG20110111T112311_6lqm90jq_.bkptag=TAG20110111T112311
channelORA_DISK_1: restore complete, elapsed time: 00:00:01
archive logfilename=/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_11/o1_mf_1_46_6lqo6lw9_.arcthread=1 sequence=46
channel default:deleting archive log(s)
archive logfilename=/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_11/o1_mf_1_46_6lqo6lw9_.arcrecid=48 stamp=740145362
media recoverycomplete, elapsed time: 00:00:07
Finished recoverat 2011-01-11:11:56:10
RMAN> alterdatabase open resetlogs;
database opened
RMAN> listincarnation of database;
List of DatabaseIncarnations
DB Key Inc Key DB Name
DB ID STATUS Reset SCN Reset Time
------- --------------- ---------------- --- ---------- ----------
1 1 ORCL
1266235128 PARENT 1 2005-06-30:19:09:40
2 2 ORCL
1266235128 PARENT 446075 2010-12-22:22:13:17
3 3 ORCL
1266235128 CURRENT 976306
2011-01-11:11:56:42
(看到没，RESETLOGS后时代换了，所以INCARNATION就换了，多了一个时代了，不知道INCARNATION就没法去ORACLE论坛跟人讨论问题了)
SQL> conn hr/hr
Connected.
SQL> select *from test;
A
----------
empoli
（看到没，数据恢复了）
备份恢复实验之八
基于log序列号的不完全恢复（额，怎么讲，举个例子，在当前日志组是2号时，你删除了一张后来发现还需要的表，那你可以回退到1号日志组（这时表还在），你可以理解为它的粒度更粗一些，还有这个一般指的是用RMAN恢复）
SQL> conn hr/hr
Connected.
SQL> drop tabletest;
drop table test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('liujie');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
liujie
SQL> select *from v$log;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
-------------------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
-------------------------
1
1 47 52428800 2 NO
CURRENT
975809 11-JAN-11
2 1 45
52428800 2 YES INACTIVE
975352 09-JAN-11
3
1 46 52428800 2 YES INACTIVE
975770 11-JAN-11
（可以看出，当前日志序列号是47）
SQL> altersystem switch logfile;
System altered.
SQL> altersystem switch logfile;
System altered.
SQL> select *from v$log;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
-------------------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
------------- ------------
1
1 47 52428800 2 YES ACTIVE
975809 11-JAN-11
2
1 48 52428800 2 YES ACTIVE
976512 12-JAN-11
3
1 49 52428800 2 NO
CURRENT
976514 12-JAN-11
（现在的当前日志是序列号49）
SQL> drop tabletest;
Table dropped.
SQL> select *from test;
select * from test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
SQL> conn / assysdba
Connected.
SQL> shutdownabort
ORACLE instanceshut down.
SQL> startupmount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 130024080 bytes
DatabaseBuffers 318767104 bytes
Redo Buffers 2973696 bytes
Database mounted.
[oracle@ocpdbbackup]$ echo $NLS_LANG
american_america.ZHS16GBK
[oracle@ocpdbbackup]$ rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Wed Jan 12 14:46:30 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: ORCL (DBID=1266235128, not open)
（友情提示，刚刚前面查出来的表还未删除的时候的序列号是47，不会忘了吧，忘了再回到前面看一下）
RMAN> run {
2> set untilsequence 48;（在RMAN中UNTIL到SEQUENCE
48意味着日志走到47，额，这个没有为什么，他就是这么设计的，貌似开发SQLPLUS的与开发RMAN的不是一伙人，PS:开发RMAN的是印度人）
3> restoredatabase;
4> recoverdatabase;
5> }
（点点点，一长串东西，这里不贴出来了）
RMAN> alterdatabase open resetlogs;
database opened（如果这里等待的时间久，恭喜你，他正在打开，很可能意味着你实验成功了，你可以去喝杯咖啡了，额，我刚刚喝完一杯热咖啡）
RMAN> listincarnation of database;
List of DatabaseIncarnations
DB Key Inc Key DB Name
DB ID STATUS Reset SCN Reset Time
------- --------------- ---------------- --- ---------- ----------
1 1 ORCL
1266235128 PARENT 1 30-JUN-05
2 2 ORCL
1266235128 PARENT 446075 22-DEC-10
3 3 ORCL
1266235128 CURRENT 976513 12-JAN-11
（第一个INCARNATION是ORACLE公司的最原始的建库，第二个是我装完10G
DBCA后（图形界面建库），说一下，DBCA的本质实际上就是把已经压缩好的数据文件解出来，再拷回来，之后RESETLOGS所以DBCA会多出一个INCARNATION（这个东西我没验证过，但是我断定它就是这样，你可以看一下ORACLE的建库脚本，就一清二楚了，而第三个INCARNATION是我们刚刚RESETLOGS产生的，明白？）
SQL> conn hr/hr
Connected.
SQL> select *from test;
A
----------
liujie
（看到没，数据恢复了）
备份恢复实验之九
基于cancel的不完全恢复（跟备份恢复实验之八本质是一样的，只是它一般指的是用sqlplus，即就是手工恢复，不明白的话，看我接下来的操作就明白了）
（顺便说一句，喝着咖啡，写着文档，没有电话，实在是人生一大享受啊）
SQL> conn hr/hr
Connected.
SQL> drop tabletest;
drop table test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('forzainter');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
forzainter
SQL> select *from v$log;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
-------------------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
-------------------------
1 1 47 52428800
2 NO CURRENT
975809 11-JAN-11
2
1 45 52428800 2 YES INACTIVE
975352 09-JAN-11
3
1 46 52428800 2 YES INACTIVE
975770 11-JAN-11
（我们现在知道forzainter（疯狂的国际米兰），在当前日志上（如果你要说，他难道就不可能是在46上面的吗，因为它日志不是一直在走吗，那我没法反驳你，但关键是我这是测试环境，没什么日志量，所以不会走得那么快，OK？）
SQL> altersystem switch logfile;
System altered.
SQL> altersystem switch logfile;
System altered.
（为什么要切换两次日志，因为我怕有一些极端的情况产生，我们现在先做好这个实验再说，但是我并没有说你切换一次实验就会不成功，照着做吧，你先做对这个实验）
SQL> drop tabletest;
Table dropped.
SQL> select *from test;
select * from test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
SQL> select *from v$log;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
-------------------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
-------------------------
1
1 47 52428800 2 YES INACTIVE
975809 11-JAN-11
2 1 48
52428800 2 YES INACTIVE
976516 12-JAN-11
3
1 49 52428800 2 NO
CURRENT
976521 12-JAN-11
（从这里可以看出，我们删除表操作的日志位于序列号49的日志上，待会恢复的时候如果你还是应用日志直到49，那么你的表还是会被删，还是不存在，明白？你可以自己做个实验，让其恢复到日志49，那时候表肯定是不在的，做实验，实验是检验真理的唯一标准）
SQL> conn / assysdba
Connected.
SQL> shutdownabort
ORACLE instanceshut down.
SQL> startupmount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 138412688 bytes
DatabaseBuffers 310378496 bytes
Redo Buffers 2973696 bytes
Database mounted.
[oracle@ocpdbbackup]$ rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Wed Jan 12 15:24:57 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: ORCL (DBID=1266235128, not open)
RMAN> restoredatabase;（利用RMAN这个备份恢复的工具，把旧的数据拷回来（请注意，是旧的数据！），本实验采用的是RMAN+SQLPLUS的结合，你当然用前面的全部是RMAN的来做的当然也没问题，这里只是告诉你有多种方法）
在SQLPLUS里面敲
SQL> recoverdatabase until cancel;
ORA-00279: change975774 generated at 01/11/2011 11:20:55 needed for thread 1
ORA-00289:suggestion :
/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_12/o1_mf_1_4
6_%u_.arc
ORA-00280: change975774 for thread 1 is in sequence #46
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
（现在他准备“吃“下序列号为46的日志，我们让他”吃“，当然，我准备让他”吃“到47就停下来，因为表在那时还没删，PS：敲回车就是让它”吃“。）
（额，我做到这的时候才发现，刚才做完上一个实验，忘了把那个干净的备份拷回来了，这是个教训啊，所以每做完一个实验，要做下一个实验，记得先把干净的备份拷回来。生产环境怎么办？如果你不幸，需要做这种换INCARNATION的不完全恢复，那么你恢复完之后，要立刻做一次全备份（我这么说，是叫你要养成备份的好习惯，实际上到了Oracle10g，可以跨越INCARNATION来恢复，这个我们最后一个实验才会讲到），总之，备份备份，不要玩心跳！）
没事，前面步骤一样，哎，我得再来一次了，稍后片刻。
晕，我做了好久，是这样的，这一步由于用到了归档日志，你之前在准备那份冷备的时候你DELETE ALL INPUT了，等于是你把归档日志包进了RMAN，但是你SQLPLUS要做RECOVER要用到归档日志岂不是找不到了，没办法，这一步这么做吧，你再备一次，不要DELETE
ALL INPUT（这样，BACKUP DATABASE PLUS ARCHIVELOG即可！），RMAN它默认拷回来会用最新的，照着做吧，只是方法的差异而已，生产环境只要能恢复回来就OK了，但是这里做实验所以步骤多一点，明白？不明白，就照着做吧！
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change479637 generated at 01/12/2011 16:28:14 needed for thread 1
ORA-00289:suggestion :
/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_12/o1_mf_1_48
_%u_.arc
ORA-00280: change479637 for thread 1 is in sequence #48
ORA-00278: logfile
'/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_12/o1_mf_1_
6_6ltsjyjf_.arc'no longer needed for this recovery
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recoverycancelled.
（到了48，停下来，也就是CANCEL！因为走到47即可！）
SQL> alterdatabase open resetlogs;
Database altered.
SQL> select *from hr.test;
A
----------
Forzainter
（有了，数据回来了）
PS：讲是这样讲，好像很顺，实际上时至今日，我在做的时候问题还是很多，过程中的曲折需要自己去领悟，这就是艺术啊！）
RMAN> listincarnation of database;
List of DatabaseIncarnations
DB Key Inc Key DB Name
DB ID STATUS Reset SCN Reset Time
------- --------------- ---------------- --- ---------- ----------
1 1 ORCL
1268026867 PARENT 1 30-JUN-05
2 2 ORCL
1268026867 PARENT 446075 12-JAN-11
3 3 ORCL
1268026867 CURRENT 479638 12-JAN-11
（看到没，INCARNATION又多了一个（相对于干净的备份，而不是上一个实验，明白？）
(写到这里，去赶17：24分回厦门的动车了，希望到时还有机会到这个地方偷得浮生半日闲---福州北站麦当劳厕所旁)
备份恢复实验之十
当前控制文件和数据文件完好_日志文件全部损坏_正常关机不完全恢复
（额，比较长，日志损坏指的是在线日志全部损坏，日志损坏肯定是不完全恢复，正常关机与不正常关机有啥差别，看我的实验。数据不丢！！？？不会吧？在线日志内肯定会有记录，损坏了肯定会有数据丢失才对吧？
这个要好好讲一下，自己想象一下，什么叫正常关机。正常关机就是shutdown immediate,他会将内存中的数据同步到数据文件，也就是往下写。日志丢了不怕，他已经同步进了数据文件了！只是它是用不完全恢复的方法实现完全恢复，请注意我的用词！
无需备份，数据也不会丢。）
SQL> conn hr/hr
Connected.
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('liujie');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
liujie
SQL> select *FROM V$LOG;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
-------------------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
-------------------------
1
1 2 52428800 2 YES INACTIVE
472702 12-JAN-11
2
1 3 52428800 2 YES INACTIVE
479066 12-JAN-11
3
1 4 52428800 2 NO
CURRENT
479090 12-JAN-11
（当前的在线日志是序列号4，等会做实验时，把序列号为4的日志全删了，删完后，SHUTDOWN
IMMEDIATE。你要明白一点，我们建的那个表是在序列号为4的日志上面，我们等会把序列号为4的日志全删了，这个表还在吗？思考一下）
因为序列号为4的日志组别是3，所以
select * fromv$logfile l where l.group#=3;
GROUP#
STATUS TYPE MEMBER IS_RECOVE
3
ONLINE /home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_3_6ltqmy1n_.log NO
3
ONLINE /home/oracle/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_3_6ltqmztm_.log YES
等会要把这两个路径下的日志全删了，一个不留。等等，大哥，现在是做实验啊，要在测试环境做啊，别乱来啊。
[oracle@ocpdb ~]$rm -rf /home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_3_6ltqmy1n_.log
[oracle@ocpdb ~]$rm -rf/home/oracle/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_3_6ltqmztm_.log
SQL> shutdownimmediate
Database closed.
Databasedismounted.
ORACLE instanceshut down.
（为什么日志删了，SHUTDOWN IMMEDIATE还能成功？一个我觉得是因为日志本身写的就比较快，COMMIT就写了（当然其实也只是写内存，额，算了，这里要意译一下，自己理解了），你现在就问你自己，日志何时往下写，我不讲。再来，LINUX的强大之处我想就在于此吧，异步IO？WINDOWS可以不？我没试过。你可以做一下实验）
SQL> startupmount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 117441168 bytes
DatabaseBuffers 331350016 bytes
Redo Buffers 2973696 bytes
Database mounted.
（你也只能到MOUNT,你想OPEN是不可能的，不信？）
SQL> alterdatabase open;
alter databaseopen
*
ERROR at line 1:
ORA-00313: openfailed for members of log group 3 of thread 1
ORA-00312: onlinelog 3 thread 1:
'/home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_3_6ltqmy1n_.log'
ORA-00312: onlinelog 3 thread 1:
'/home/oracle/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_3_6ltqmztm_.lo
g'
（看吧，当前的在线日志丢了，发现了）
SQL> alterdatabase open resetlogs;
alter databaseopen resetlogs
*
ERROR at line 1:
ORA-01139:RESETLOGS option only valid after an incomplete database recovery
（额，这里要先RECOVER一下，才能RESETLOGS）
SQL> recoverdatabase until cancel;
Media recoverycomplete.
（怎么讲，我库一开就是STARTUP，直接写当前的在线日志，之前没有切换过日志（也就是之前没有归档的操作），它也无需再走日志，之后发现，没什么号恢复的，该写的都写进去了）
SQL> alterdatabase open resetlogs;
Database altered.
SQL> select *from hr.test;
A
----------
liujie
（神奇吧，数据竟然在！刚才在线日志明明被我删了！因为SHUTDOWN IMMEDIATE背后是一个完全检查点，他已将缓存中的数据往下写了!）
RMAN> listincarnation of database;
using targetdatabase control file instead of recovery catalog
List of DatabaseIncarnations
DB Key Inc Key DB Name
DB ID STATUS Reset SCN Reset Time
------- --------------- ---------------- --- ---------- ----------
1 1 ORCL
1268026867 PARENT 1 30-JUN-05
2 2 ORCL
1268026867 PARENT 446075 12-JAN-11
3 3 ORCL
1268026867 CURRENT 484575 12-JAN-11
（看吧，又多了一个INCARNATION，这就是用不完全恢复的方法实现完全恢复！）
备份恢复实验之十一
当前控制文件和数据文件完好_日志文件全部损坏_不正常关机不完全恢复（看出跟备份恢复实验之十的差别了吗？这次变成了不正常关机，不正常关机意味着数据没有往下写，也就是说数据会丢，虽然你库可以开得起来，明白？还有一点很重要，要把旧的数据文件拷回来！！！）
SQL> conn hr/hr
Connected.
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('empoli');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
empoli
SQL> select *from v$log;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
---------- -------------------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
-------------------------
1
1 5 52428800 2 NO
CURRENT
479922 13-JAN-11
2
1 3 52428800 2 YES INACTIVE
479066 12-JAN-11
3
1 4 52428800 2 YES INACTIVE
479090 12-JAN-11
（看到了当前在线日志是序列号为5，组别为1号组）
select * fromv$logfile;
1
ONLINE /home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_1_6ltqmqho_.log NO
1
ONLINE /home/oracle/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_1_6ltqms7g_.log YES
[oracle@ocpdb ~]$rm -rf /home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_1_6ltqmqho_.log
[oracle@ocpdb ~]$rm -rf /home/oracle/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_1_6ltqms7g_.log
SQL> conn / assysdba
Connected.
SQL> shutdownabort
ORACLE instanceshut down.（不要问我为什么要SHUTDIWN
ABORT，这里是为了做实验，让你知道SHUTDOWN ABORT后怎么恢复或者知道为什么无法恢复，生产环境禁止发SHUTDOWN
ABORT命令！）
SQL> startupmount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 125829776 bytes
DatabaseBuffers 322961408 bytes
Redo Buffers 2973696 bytes
Database mounted.
[oracle@ocpdb ~]$rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Thu Jan 13 12:40:43 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: ORCL (DBID=1268026867, not open)
RMAN> restoredatabase;
SQL> recoverdatabase until cancel using backup controlfile;（这里用SQLPLUS！）
ORA-00279: change479072 generated at 01/12/2011 16:03:24 needed for thread 1
ORA-00289:suggestion :
/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_13/o1_mf_1_3
_%u_.arc
ORA-00280: change479072 for thread 1 is in sequence #3
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change479090 generated at 01/12/2011 16:04:10 needed for thread 1
ORA-00289:suggestion :
/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_13/o1_mf_1_4
_%u_.arc
ORA-00280: change479090 for thread 1 is in sequence #4
ORA-00278: logfile
'/home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_2_6ltqmtqv_.log'no
longer needed forthis recovery
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
ORA-00280: change479922 for thread 1 is in sequence #5
ORA-00278: logfile
'/home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_3_6ltqmy1n_.log'no
longer needed forthis recovery
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
ORA-00328:archived log ends at change 479593, need later change 479922
ORA-00334:archived log:
'/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_12/o1_mf_1_
5_6ltsgnvd_.arc'
（到了5就下不去了，因为已经下不去了，5是在线日志，已经被删了！）
SQL> recoverdatabase until cancel using backup controlfile;
ORA-00279: change479922 generated at 01/13/2011 09:52:14 needed for thread 1
ORA-00289:suggestion :
/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_13/o1_mf_1_5
_%u_.arc
ORA-00280: change479922 for thread 1 is in sequence #5
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
cancel
（再RECOVER一下，把5CANCEL掉）
SQL> alterdatabase open resetlogs;
Database altered.
SQL> conn hr/hr
Connected.
SQL> select *from test;
select * from test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
（表是没了，所以说你SHUTDOWN ABORT后数据是别想恢复回来了）
INCARNATION不看了，你自己试一下，肯定多了个INCARNATION了。
备份恢复实验之十二
当前控制文件损坏_不完全恢复_用控制文件二进制备份_数据不丢——不需备份（控制文件全部损坏，注意，这里日志文件没有损坏，只要日志在什么都好说！不需备份，说明日志就是老大啊！注意，控制文件全部损坏还能SHUTDOWN
IMMEDIATE吗？肯定不行（貌似我有过几次，控制文件删了，还能SHUTDOWN IMMEDIATE，额，特例特例），一旦控制文件损坏就是只能SHUTDOWN
ABORT了（为什么，因为SHUTDONW IMMEDIATE会发一个完全检查点，这个完全检查点会写入控制文件，你损坏了就是没了，它还能写吗？）。（最后，我想说的是，实验看似简单，但是真正自己去做，就会有这样那样的问题，为了写这个实验，我又敲了22遍。很奇怪，可能是我的库有问题，但是我说不上来，我是重新DBCA建库，重新备份数据文件后，再做这个实验，才成功的。还有，不完全恢复说明了，一定要RESETLOGS，这就是为什么平时爱用控制文件脚本来恢复的原因，因为用脚本恢复的话不需要RESETLOGS。总之，看下面的实验。）
SQL> conn hr/hr
Connected.
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('empoli');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
empoli
[oracle@ocpdbbackup]$ rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Mon Jan 17 19:58:58 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: ORCL (DBID=1268460421)
RMAN> backupcurrent controlfile;
Starting backup at17-JAN-11
using targetdatabase control file instead of recovery catalog
allocated channel:ORA_DISK_1
channelORA_DISK_1: sid=142 devtype=DISK
channelORA_DISK_1: starting full datafile backupset
channelORA_DISK_1: specifying datafile(s) in backupset
including currentcontrol file in backupset
channelORA_DISK_1: starting piece 1 at 17-JAN-11
channelORA_DISK_1: finished piece 1 at 17-JAN-11
piecehandle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_17/o1_mf_ncnnf_TAG20110117T195906_6m8crckx_.bkptag=TAG20110117T195906
comment=NONE
channelORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at17-JAN-11
接下来，控制文件损坏，那我怎么知道控制文件在哪呢？
方法一：
select * fromv$controlfile;
STATUS
NAME IS_RECOVE BLOCK_SIZE FILE_SIZE_BLKS
/home/oracle/app/oracle/oradata/ORCL/controlfile/o1_mf_6lzo7cmw_.ctl NO
16384 430
/home/oracle/app/oracle/flash_recovery_area/ORCL/controlfile/o1_mf_6lzo7cvq_.ctl YES
16384 430
方法二：
SQL> conn / assysdba
Connected.
SQL> showparameter control_files
NAME TYPE
VALUE
----------------------------------------------- ------------------------------
control_files string
/home/oracle/app/oracle/oradat
a/ORCL/controlfile/o1_mf_6lzo7
cmw_.ctl,/home/oracle/app/ora
cle/flash_recovery_area/ORCL/c
ontrolfile/o1_mf_6lzo7cvq_.ctl
好了，删除控制文件
[oracle@ocpdbbackup]$ rm -rf/home/oracle/app/oracle/oradata/ORCL/controlfile/o1_mf_6lzo7cmw_.ctl
[oracle@ocpdbbackup]$ rm -rf/home/oracle/app/oracle/flash_recovery_area/ORCL/controlfile/o1_mf_6lzo7cvq_.ctl
[oracle@ocpdbbackup]$
SQL> shutdownabort
ORACLE instanceshut down.
SQL> startupnomount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 134218384 bytes
DatabaseBuffers 314572800 bytes
Redo Buffers 2973696 bytes
（为什么STARTUP NOMOUNT?因为你已经MOUNT不起来了，控制文件删了，看：
SQL> alterdatabase mount;
alter databasemount
*
ERROR at line 1:
ORA-00205: errorin identifying control file, check alert log for more info
[oracle@ocpdborcl]$ rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Mon Jan 17 20:00:41 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: orcl (not mounted)
RMAN> restorecontrolfile from'/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_17/o1_mf_ncnnf_TAG20110117T195906_6m8crckx_.bkp';
Starting restoreat 17-JAN-11
using targetdatabase control file instead of recovery catalog
allocated channel:ORA_DISK_1
channelORA_DISK_1: sid=155 devtype=DISK
channelORA_DISK_1: restoring control file
channelORA_DISK_1: restore complete, elapsed time: 00:00:03
outputfilename=/home/oracle/app/oracle/oradata/orcl/control01.ctl
outputfilename=/home/oracle/app/oracle/oradata/orcl/control02.ctl
outputfilename=/home/oracle/app/oracle/oradata/orcl/control03.ctl
Finished restoreat 17-JAN-11
RMAN> alterdatabase mount;
database mounted
released channel:ORA_DISK_1
（在RMAN中，你把控制文件拷回来还不够，还要手动MOUNT一下，而在SQLPLUS用控制文件脚本恢复时，它会帮你MOUNT，这就是区别）
RMAN> recoverdatabase;
Starting recoverat 17-JAN-11
Starting implicitcrosscheck backup at 17-JAN-11
allocated channel:ORA_DISK_1
channelORA_DISK_1: sid=155 devtype=DISK
Finished implicitcrosscheck backup at 17-JAN-11
Starting implicitcrosscheck copy at 17-JAN-11
using channelORA_DISK_1
Finished implicitcrosscheck copy at 17-JAN-11
searching for allfiles in the recovery area
catalogingfiles...
cataloging done
List of CatalogedFiles
=======================
File Name:/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_17/o1_mf_ncnnf_TAG20110117T225501_6m8p279b_.bkp
using channelORA_DISK_1
starting mediarecovery
archive log thread1 sequence 2 is already on disk as file/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_17/o1_mf_1_2_6m8p0h1j_.arc
archive log thread1 sequence 3 is already on disk as file/home/oracle/app/oracle/oradata/orcl/redo02.log
archive logfilename=/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_17/o1_mf_1_2_6m8p0h1j_.arcthread=1 sequence=2
archive logfilename=/home/oracle/app/oracle/oradata/orcl/redo02.log thread=1 sequence=3
media recoverycomplete, elapsed time: 00:00:10
Finished recoverat 17-JAN-11
想直接OPEN吗？
RMAN> alterdatabase open;
RMAN-00571:===========================================================
RMAN-00569:=============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571:===========================================================
RMAN-03002:failure of alter db command at 01/17/2011 23:05:54
ORA-01589: mustuse RESETLOGS or NORESETLOGS option for database open
RMAN> alterdatabase open resetlogs;
database opened
（不能直接OPEN，所以说这种情况下爱用脚本备份的控制文件去恢复，因为用备份的二进制控制文件去恢复，数据在是在，但是需要RESETLOGS，INCARNATION当然是越少越好，不是吗？）
SQL> select *from hr.test;
A
----------
liujie
（看到没，RESETLOGS数据也还在，最关键的是你的日志在，这点最重要。如果日志也损坏那数据肯定会丢了，多或少的问题而已。）
RMAN> listincarnation of database;
List of DatabaseIncarnations
DB Key Inc Key DB Name
DB ID STATUS Reset SCN Reset Time
------- --------------- ---------------- --- ---------- ----------
1 1 ORCL
1268479776 PARENT 1 30-JUN-05
2 2 ORCL
1268479776 PARENT 446075 17-JAN-11
3 3 ORCL
1268479776 CURRENT 484356 17-JAN-11
（INCARNATION又多了一个，因为你RESETLOGS，又换代了。）
基于时间的不完全恢复（举个例子，你10：00删除了一张表，可事后你发现误删了，那你就要将数据库的时间回退到9：59，也就是回退到这张表还在的时刻，这里当然不是说表被误删就一定要采用传统的备份恢复的方法来恢复，你完全可以通过闪回FLASHBACK来恢复，前提是还在回收站中，这里不讨论闪回恢复，这里只是做实验，OK？）
SQL> conn hr/hr
Connected.
SQL> drop tabletest;
drop table test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('empoli');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
empoli
SQL> selectsysdate from dual;
SYSDATE
------------
11-JAN-11
SQL> altersession set nls_date_format='yyyy-mm-dd:hh24:mi:ss';
Session altered.
SQL> selectsysdate from dual;
SYSDATE
-------------------
2011-01-11:11:36:24
SQL> altersystem switch logfile;（模拟一下生产环境的切换日志，因为你最后是要OPEN
RESETLOGS的，粒度是一个日志，你不切的话，按照我的理解，整个日志上的数据你都找不到了，看不懂的先往下）
System altered.
SQL> altersystem switch logfile;
System altered.
Droptable test;
（有些人就想了，我只恢复TEST这张表的表空间就行了嘛。告诉你，不行？因为日志已经走到“现在”，要想回退到之前的时间点，就要所有表空间（或者说所有数据文件）一齐回到之前的时间点，很正常啊。你想想，你腿是昨天的，胳膊是现在的，可能吗？）
SQL> conn / assysdba
Connected.
SQL> shutdownabort
ORACLE instanceshut down.（生产环境禁止！我们现在只是做实验）
SQL> conn / assysdba
Connected to anidle instance.
SQL> startupmount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 121635472 bytes
DatabaseBuffers 327155712 bytes
Redo Buffers 2973696 bytes
Database mounted.
在使用RMAN恢复之前，请先将RMAN的时间格式变量先设好，不然到时恢复的时候时间格式认不到，明白？看下面：
[root@ocpdb ~]# su - oracle
[oracle@ocpdb ~]$ echo $NLS_DATE_FORMAT
[oracle@ocpdb ~]$ export NLS_DATE_FORMAT='yyyy-mm-dd:hh24:mi:ss'
[oracle@ocpdb ~]$ echo $NLS_DATE_FORMAT
yyyy-mm-dd:hh24:mi:ss
[oracle@ocpdbbackup]$ rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Tue Jan 11 11:42:47 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: ORCL (DBID=1266235128, not open)
RMAN> listbackup;（截取一段）
BS Key Type LV Size
Device Type Elapsed Time CompletionTime
------- ---- ------------ ----------- ------------ -------------------
13 Full 6.83M
DISK 00:00:01 2011-01-11:11:23:14
BP Key: 13
Status: AVAILABLE Compressed: NO Tag: TAG20110111T112313
Piece Name:/home/oracle/app/oracle/flash_recovery_area/ORCL/autobackup/2011_01_11/o1_mf_s_740143393_6lqm927v_.bkp
Control File Included: Ckp SCN: 975815
Ckp time: 2011-01-11:11:23:13
SPFILE Included: Modification time:
2011-01-11:11:19:35
RMAN> restoredatabase;（敲下去，要将旧的数据拷回来，走日志，明白？）
Starting restoreat 2011-01-11:11:43:22
using targetdatabase control file instead of recovery catalog
allocated channel:ORA_DISK_1
channelORA_DISK_1: sid=155 devtype=DISK
channelORA_DISK_1: starting datafile backupset restore
channelORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile00001 to/home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_system_6k5t18qg_.dbf
restoring datafile00002 to /home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_6k5t18td_.dbf
restoring datafile00003 to/home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_6k5t18qx_.dbf
restoring datafile00004 to/home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_users_6k5t18v3_.dbf
restoring datafile00005 to/home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_example_6k5t4xxc_.dbf
restoring datafile00006 to /home/oracle/app/oracle/oradata/ORCL/datafile/o1_mf_test_6kjb532l_.dbf
restoring datafile00007 to /home/oracle/app/oracle/oradata/ORCL/datafile/tets02.dbf
channelORA_DISK_1: reading from backup piece/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_11/o1_mf_nnndf_TAG20110111T112055_6lqm4qnd_.bkp
之前表还在的时间还记得住吗？这句是为什么我SELECT SYSDATE FROM DUAL;
2011-01-11:11:36:24
RMAN> recoverdatabase until time '2011-01-11:11:36:24';
Starting recoverat 2011-01-11:11:56:01
using channelORA_DISK_1
starting mediarecovery
archive log thread1 sequence 47 is already on disk as file/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_11/o1_mf_1_47_6lqn42s6_.arc
channelORA_DISK_1: starting archive log restore to default destination
channelORA_DISK_1: restoring archive log
archive logthread=1 sequence=46
channelORA_DISK_1: reading from backup piece/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_11/o1_mf_annnn_TAG20110111T112311_6lqm90jq_.bkp
channelORA_DISK_1: restored backup piece 1
piecehandle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_11/o1_mf_annnn_TAG20110111T112311_6lqm90jq_.bkptag=TAG20110111T112311
channelORA_DISK_1: restore complete, elapsed time: 00:00:01
archive logfilename=/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_11/o1_mf_1_46_6lqo6lw9_.arcthread=1 sequence=46
channel default:deleting archive log(s)
archive logfilename=/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_11/o1_mf_1_46_6lqo6lw9_.arcrecid=48 stamp=740145362
media recoverycomplete, elapsed time: 00:00:07
Finished recoverat 2011-01-11:11:56:10
RMAN> alterdatabase open resetlogs;
database opened
RMAN> listincarnation of database;
List of DatabaseIncarnations
DB Key Inc Key DB Name
DB ID STATUS Reset SCN Reset Time
------- --------------- ---------------- --- ---------- ----------
1 1 ORCL
1266235128 PARENT 1 2005-06-30:19:09:40
2 2 ORCL
1266235128 PARENT 446075 2010-12-22:22:13:17
3 3 ORCL
1266235128 CURRENT 976306
2011-01-11:11:56:42
(看到没，RESETLOGS后时代换了，所以INCARNATION就换了，多了一个时代了，不知道INCARNATION就没法去ORACLE论坛跟人讨论问题了)
SQL> conn hr/hr
Connected.
SQL> select *from test;
A
----------
empoli
（看到没，数据恢复了）
备份恢复实验之八
基于log序列号的不完全恢复（额，怎么讲，举个例子，在当前日志组是2号时，你删除了一张后来发现还需要的表，那你可以回退到1号日志组（这时表还在），你可以理解为它的粒度更粗一些，还有这个一般指的是用RMAN恢复）
SQL> conn hr/hr
Connected.
SQL> drop tabletest;
drop table test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('liujie');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
liujie
SQL> select *from v$log;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
-------------------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
-------------------------
1
1 47 52428800 2 NO
CURRENT
975809 11-JAN-11
2 1 45
52428800 2 YES INACTIVE
975352 09-JAN-11
3
1 46 52428800 2 YES INACTIVE
975770 11-JAN-11
（可以看出，当前日志序列号是47）
SQL> altersystem switch logfile;
System altered.
SQL> altersystem switch logfile;
System altered.
SQL> select *from v$log;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
-------------------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
------------- ------------
1
1 47 52428800 2 YES ACTIVE
975809 11-JAN-11
2
1 48 52428800 2 YES ACTIVE
976512 12-JAN-11
3
1 49 52428800 2 NO
CURRENT
976514 12-JAN-11
（现在的当前日志是序列号49）
SQL> drop tabletest;
Table dropped.
SQL> select *from test;
select * from test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
SQL> conn / assysdba
Connected.
SQL> shutdownabort
ORACLE instanceshut down.
SQL> startupmount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 130024080 bytes
DatabaseBuffers 318767104 bytes
Redo Buffers 2973696 bytes
Database mounted.
[oracle@ocpdbbackup]$ echo $NLS_LANG
american_america.ZHS16GBK
[oracle@ocpdbbackup]$ rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Wed Jan 12 14:46:30 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: ORCL (DBID=1266235128, not open)
（友情提示，刚刚前面查出来的表还未删除的时候的序列号是47，不会忘了吧，忘了再回到前面看一下）
RMAN> run {
2> set untilsequence 48;（在RMAN中UNTIL到SEQUENCE
48意味着日志走到47，额，这个没有为什么，他就是这么设计的，貌似开发SQLPLUS的与开发RMAN的不是一伙人，PS:开发RMAN的是印度人）
3> restoredatabase;
4> recoverdatabase;
5> }
（点点点，一长串东西，这里不贴出来了）
RMAN> alterdatabase open resetlogs;
database opened（如果这里等待的时间久，恭喜你，他正在打开，很可能意味着你实验成功了，你可以去喝杯咖啡了，额，我刚刚喝完一杯热咖啡）
RMAN> listincarnation of database;
List of DatabaseIncarnations
DB Key Inc Key DB Name
DB ID STATUS Reset SCN Reset Time
------- --------------- ---------------- --- ---------- ----------
1 1 ORCL
1266235128 PARENT 1 30-JUN-05
2 2 ORCL
1266235128 PARENT 446075 22-DEC-10
3 3 ORCL
1266235128 CURRENT 976513 12-JAN-11
（第一个INCARNATION是ORACLE公司的最原始的建库，第二个是我装完10G
DBCA后（图形界面建库），说一下，DBCA的本质实际上就是把已经压缩好的数据文件解出来，再拷回来，之后RESETLOGS所以DBCA会多出一个INCARNATION（这个东西我没验证过，但是我断定它就是这样，你可以看一下ORACLE的建库脚本，就一清二楚了，而第三个INCARNATION是我们刚刚RESETLOGS产生的，明白？）
SQL> conn hr/hr
Connected.
SQL> select *from test;
A
----------
liujie
（看到没，数据恢复了）
备份恢复实验之九
基于cancel的不完全恢复（跟备份恢复实验之八本质是一样的，只是它一般指的是用sqlplus，即就是手工恢复，不明白的话，看我接下来的操作就明白了）
（顺便说一句，喝着咖啡，写着文档，没有电话，实在是人生一大享受啊）
SQL> conn hr/hr
Connected.
SQL> drop tabletest;
drop table test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('forzainter');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
forzainter
SQL> select *from v$log;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
-------------------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
-------------------------
1 1 47 52428800
2 NO CURRENT
975809 11-JAN-11
2
1 45 52428800 2 YES INACTIVE
975352 09-JAN-11
3
1 46 52428800 2 YES INACTIVE
975770 11-JAN-11
（我们现在知道forzainter（疯狂的国际米兰），在当前日志上（如果你要说，他难道就不可能是在46上面的吗，因为它日志不是一直在走吗，那我没法反驳你，但关键是我这是测试环境，没什么日志量，所以不会走得那么快，OK？）
SQL> altersystem switch logfile;
System altered.
SQL> altersystem switch logfile;
System altered.
（为什么要切换两次日志，因为我怕有一些极端的情况产生，我们现在先做好这个实验再说，但是我并没有说你切换一次实验就会不成功，照着做吧，你先做对这个实验）
SQL> drop tabletest;
Table dropped.
SQL> select *from test;
select * from test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
SQL> select *from v$log;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
-------------------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
-------------------------
1
1 47 52428800 2 YES INACTIVE
975809 11-JAN-11
2 1 48
52428800 2 YES INACTIVE
976516 12-JAN-11
3
1 49 52428800 2 NO
CURRENT
976521 12-JAN-11
（从这里可以看出，我们删除表操作的日志位于序列号49的日志上，待会恢复的时候如果你还是应用日志直到49，那么你的表还是会被删，还是不存在，明白？你可以自己做个实验，让其恢复到日志49，那时候表肯定是不在的，做实验，实验是检验真理的唯一标准）
SQL> conn / assysdba
Connected.
SQL> shutdownabort
ORACLE instanceshut down.
SQL> startupmount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 138412688 bytes
DatabaseBuffers 310378496 bytes
Redo Buffers 2973696 bytes
Database mounted.
[oracle@ocpdbbackup]$ rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Wed Jan 12 15:24:57 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: ORCL (DBID=1266235128, not open)
RMAN> restoredatabase;（利用RMAN这个备份恢复的工具，把旧的数据拷回来（请注意，是旧的数据！），本实验采用的是RMAN+SQLPLUS的结合，你当然用前面的全部是RMAN的来做的当然也没问题，这里只是告诉你有多种方法）
在SQLPLUS里面敲
SQL> recoverdatabase until cancel;
ORA-00279: change975774 generated at 01/11/2011 11:20:55 needed for thread 1
ORA-00289:suggestion :
/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_12/o1_mf_1_4
6_%u_.arc
ORA-00280: change975774 for thread 1 is in sequence #46
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
（现在他准备“吃“下序列号为46的日志，我们让他”吃“，当然，我准备让他”吃“到47就停下来，因为表在那时还没删，PS：敲回车就是让它”吃“。）
（额，我做到这的时候才发现，刚才做完上一个实验，忘了把那个干净的备份拷回来了，这是个教训啊，所以每做完一个实验，要做下一个实验，记得先把干净的备份拷回来。生产环境怎么办？如果你不幸，需要做这种换INCARNATION的不完全恢复，那么你恢复完之后，要立刻做一次全备份（我这么说，是叫你要养成备份的好习惯，实际上到了Oracle10g，可以跨越INCARNATION来恢复，这个我们最后一个实验才会讲到），总之，备份备份，不要玩心跳！）
没事，前面步骤一样，哎，我得再来一次了，稍后片刻。
晕，我做了好久，是这样的，这一步由于用到了归档日志，你之前在准备那份冷备的时候你DELETE ALL INPUT了，等于是你把归档日志包进了RMAN，但是你SQLPLUS要做RECOVER要用到归档日志岂不是找不到了，没办法，这一步这么做吧，你再备一次，不要DELETE
ALL INPUT（这样，BACKUP DATABASE PLUS ARCHIVELOG即可！），RMAN它默认拷回来会用最新的，照着做吧，只是方法的差异而已，生产环境只要能恢复回来就OK了，但是这里做实验所以步骤多一点，明白？不明白，就照着做吧！
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change479637 generated at 01/12/2011 16:28:14 needed for thread 1
ORA-00289:suggestion :
/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_12/o1_mf_1_48
_%u_.arc
ORA-00280: change479637 for thread 1 is in sequence #48
ORA-00278: logfile
'/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_12/o1_mf_1_
6_6ltsjyjf_.arc'no longer needed for this recovery
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
cancel
Media recoverycancelled.
（到了48，停下来，也就是CANCEL！因为走到47即可！）
SQL> alterdatabase open resetlogs;
Database altered.
SQL> select *from hr.test;
A
----------
Forzainter
（有了，数据回来了）
PS：讲是这样讲，好像很顺，实际上时至今日，我在做的时候问题还是很多，过程中的曲折需要自己去领悟，这就是艺术啊！）
RMAN> listincarnation of database;
List of DatabaseIncarnations
DB Key Inc Key DB Name
DB ID STATUS Reset SCN Reset Time
------- --------------- ---------------- --- ---------- ----------
1 1 ORCL
1268026867 PARENT 1 30-JUN-05
2 2 ORCL
1268026867 PARENT 446075 12-JAN-11
3 3 ORCL
1268026867 CURRENT 479638 12-JAN-11
（看到没，INCARNATION又多了一个（相对于干净的备份，而不是上一个实验，明白？）
(写到这里，去赶17：24分回厦门的动车了，希望到时还有机会到这个地方偷得浮生半日闲---福州北站麦当劳厕所旁)
备份恢复实验之十
当前控制文件和数据文件完好_日志文件全部损坏_正常关机不完全恢复
（额，比较长，日志损坏指的是在线日志全部损坏，日志损坏肯定是不完全恢复，正常关机与不正常关机有啥差别，看我的实验。数据不丢！！？？不会吧？在线日志内肯定会有记录，损坏了肯定会有数据丢失才对吧？
这个要好好讲一下，自己想象一下，什么叫正常关机。正常关机就是shutdown immediate,他会将内存中的数据同步到数据文件，也就是往下写。日志丢了不怕，他已经同步进了数据文件了！只是它是用不完全恢复的方法实现完全恢复，请注意我的用词！
无需备份，数据也不会丢。）
SQL> conn hr/hr
Connected.
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('liujie');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
liujie
SQL> select *FROM V$LOG;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
-------------------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
-------------------------
1
1 2 52428800 2 YES INACTIVE
472702 12-JAN-11
2
1 3 52428800 2 YES INACTIVE
479066 12-JAN-11
3
1 4 52428800 2 NO
CURRENT
479090 12-JAN-11
（当前的在线日志是序列号4，等会做实验时，把序列号为4的日志全删了，删完后，SHUTDOWN
IMMEDIATE。你要明白一点，我们建的那个表是在序列号为4的日志上面，我们等会把序列号为4的日志全删了，这个表还在吗？思考一下）
因为序列号为4的日志组别是3，所以
select * fromv$logfile l where l.group#=3;
GROUP#
STATUS TYPE MEMBER IS_RECOVE
3
ONLINE /home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_3_6ltqmy1n_.log NO
3
ONLINE /home/oracle/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_3_6ltqmztm_.log YES
等会要把这两个路径下的日志全删了，一个不留。等等，大哥，现在是做实验啊，要在测试环境做啊，别乱来啊。
[oracle@ocpdb ~]$rm -rf /home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_3_6ltqmy1n_.log
[oracle@ocpdb ~]$rm -rf/home/oracle/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_3_6ltqmztm_.log
SQL> shutdownimmediate
Database closed.
Databasedismounted.
ORACLE instanceshut down.
（为什么日志删了，SHUTDOWN IMMEDIATE还能成功？一个我觉得是因为日志本身写的就比较快，COMMIT就写了（当然其实也只是写内存，额，算了，这里要意译一下，自己理解了），你现在就问你自己，日志何时往下写，我不讲。再来，LINUX的强大之处我想就在于此吧，异步IO？WINDOWS可以不？我没试过。你可以做一下实验）
SQL> startupmount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 117441168 bytes
DatabaseBuffers 331350016 bytes
Redo Buffers 2973696 bytes
Database mounted.
（你也只能到MOUNT,你想OPEN是不可能的，不信？）
SQL> alterdatabase open;
alter databaseopen
*
ERROR at line 1:
ORA-00313: openfailed for members of log group 3 of thread 1
ORA-00312: onlinelog 3 thread 1:
'/home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_3_6ltqmy1n_.log'
ORA-00312: onlinelog 3 thread 1:
'/home/oracle/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_3_6ltqmztm_.lo
g'
（看吧，当前的在线日志丢了，发现了）
SQL> alterdatabase open resetlogs;
alter databaseopen resetlogs
*
ERROR at line 1:
ORA-01139:RESETLOGS option only valid after an incomplete database recovery
（额，这里要先RECOVER一下，才能RESETLOGS）
SQL> recoverdatabase until cancel;
Media recoverycomplete.
（怎么讲，我库一开就是STARTUP，直接写当前的在线日志，之前没有切换过日志（也就是之前没有归档的操作），它也无需再走日志，之后发现，没什么号恢复的，该写的都写进去了）
SQL> alterdatabase open resetlogs;
Database altered.
SQL> select *from hr.test;
A
----------
liujie
（神奇吧，数据竟然在！刚才在线日志明明被我删了！因为SHUTDOWN IMMEDIATE背后是一个完全检查点，他已将缓存中的数据往下写了!）
RMAN> listincarnation of database;
using targetdatabase control file instead of recovery catalog
List of DatabaseIncarnations
DB Key Inc Key DB Name
DB ID STATUS Reset SCN Reset Time
------- --------------- ---------------- --- ---------- ----------
1 1 ORCL
1268026867 PARENT 1 30-JUN-05
2 2 ORCL
1268026867 PARENT 446075 12-JAN-11
3 3 ORCL
1268026867 CURRENT 484575 12-JAN-11
（看吧，又多了一个INCARNATION，这就是用不完全恢复的方法实现完全恢复！）
备份恢复实验之十一
当前控制文件和数据文件完好_日志文件全部损坏_不正常关机不完全恢复（看出跟备份恢复实验之十的差别了吗？这次变成了不正常关机，不正常关机意味着数据没有往下写，也就是说数据会丢，虽然你库可以开得起来，明白？还有一点很重要，要把旧的数据文件拷回来！！！）
SQL> conn hr/hr
Connected.
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('empoli');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
empoli
SQL> select *from v$log;
GROUP# THREAD#
SEQUENCE# BYTES MEMBERS ARC STATUS
---------- -------------------- ---------- ---------- --- ----------------
FIRST_CHANGE#FIRST_TIME
-------------------------
1
1 5 52428800 2 NO
CURRENT
479922 13-JAN-11
2
1 3 52428800 2 YES INACTIVE
479066 12-JAN-11
3
1 4 52428800 2 YES INACTIVE
479090 12-JAN-11
（看到了当前在线日志是序列号为5，组别为1号组）
select * fromv$logfile;
1
ONLINE /home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_1_6ltqmqho_.log NO
1
ONLINE /home/oracle/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_1_6ltqms7g_.log YES
[oracle@ocpdb ~]$rm -rf /home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_1_6ltqmqho_.log
[oracle@ocpdb ~]$rm -rf /home/oracle/app/oracle/flash_recovery_area/ORCL/onlinelog/o1_mf_1_6ltqms7g_.log
SQL> conn / assysdba
Connected.
SQL> shutdownabort
ORACLE instanceshut down.（不要问我为什么要SHUTDIWN
ABORT，这里是为了做实验，让你知道SHUTDOWN ABORT后怎么恢复或者知道为什么无法恢复，生产环境禁止发SHUTDOWN
ABORT命令！）
SQL> startupmount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 125829776 bytes
DatabaseBuffers 322961408 bytes
Redo Buffers 2973696 bytes
Database mounted.
[oracle@ocpdb ~]$rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Thu Jan 13 12:40:43 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: ORCL (DBID=1268026867, not open)
RMAN> restoredatabase;
SQL> recoverdatabase until cancel using backup controlfile;（这里用SQLPLUS！）
ORA-00279: change479072 generated at 01/12/2011 16:03:24 needed for thread 1
ORA-00289:suggestion :
/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_13/o1_mf_1_3
_%u_.arc
ORA-00280: change479072 for thread 1 is in sequence #3
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change479090 generated at 01/12/2011 16:04:10 needed for thread 1
ORA-00289:suggestion :
/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_13/o1_mf_1_4
_%u_.arc
ORA-00280: change479090 for thread 1 is in sequence #4
ORA-00278: logfile
'/home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_2_6ltqmtqv_.log'no
longer needed forthis recovery
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
ORA-00280: change479922 for thread 1 is in sequence #5
ORA-00278: logfile
'/home/oracle/app/oracle/oradata/ORCL/onlinelog/o1_mf_3_6ltqmy1n_.log'no
longer needed forthis recovery
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
ORA-00328:archived log ends at change 479593, need later change 479922
ORA-00334:archived log:
'/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_12/o1_mf_1_
5_6ltsgnvd_.arc'
（到了5就下不去了，因为已经下不去了，5是在线日志，已经被删了！）
SQL> recoverdatabase until cancel using backup controlfile;
ORA-00279: change479922 generated at 01/13/2011 09:52:14 needed for thread 1
ORA-00289:suggestion :
/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_13/o1_mf_1_5
_%u_.arc
ORA-00280: change479922 for thread 1 is in sequence #5
Specify log:{<RET>=suggested | filename | AUTO | CANCEL}
cancel
（再RECOVER一下，把5CANCEL掉）
SQL> alterdatabase open resetlogs;
Database altered.
SQL> conn hr/hr
Connected.
SQL> select *from test;
select * from test
*
ERROR at line 1:
ORA-00942: tableor view does not exist
（表是没了，所以说你SHUTDOWN ABORT后数据是别想恢复回来了）
INCARNATION不看了，你自己试一下，肯定多了个INCARNATION了。
备份恢复实验之十二
当前控制文件损坏_不完全恢复_用控制文件二进制备份_数据不丢——不需备份（控制文件全部损坏，注意，这里日志文件没有损坏，只要日志在什么都好说！不需备份，说明日志就是老大啊！注意，控制文件全部损坏还能SHUTDOWN
IMMEDIATE吗？肯定不行（貌似我有过几次，控制文件删了，还能SHUTDOWN IMMEDIATE，额，特例特例），一旦控制文件损坏就是只能SHUTDOWN
ABORT了（为什么，因为SHUTDONW IMMEDIATE会发一个完全检查点，这个完全检查点会写入控制文件，你损坏了就是没了，它还能写吗？）。（最后，我想说的是，实验看似简单，但是真正自己去做，就会有这样那样的问题，为了写这个实验，我又敲了22遍。很奇怪，可能是我的库有问题，但是我说不上来，我是重新DBCA建库，重新备份数据文件后，再做这个实验，才成功的。还有，不完全恢复说明了，一定要RESETLOGS，这就是为什么平时爱用控制文件脚本来恢复的原因，因为用脚本恢复的话不需要RESETLOGS。总之，看下面的实验。）
SQL> conn hr/hr
Connected.
SQL> createtable test(a varchar2(10));
Table created.
SQL> insertinto test values('empoli');
1 row created.
SQL> commit;
Commit complete.
SQL> select *from test;
A
----------
empoli
[oracle@ocpdbbackup]$ rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Mon Jan 17 19:58:58 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: ORCL (DBID=1268460421)
RMAN> backupcurrent controlfile;
Starting backup at17-JAN-11
using targetdatabase control file instead of recovery catalog
allocated channel:ORA_DISK_1
channelORA_DISK_1: sid=142 devtype=DISK
channelORA_DISK_1: starting full datafile backupset
channelORA_DISK_1: specifying datafile(s) in backupset
including currentcontrol file in backupset
channelORA_DISK_1: starting piece 1 at 17-JAN-11
channelORA_DISK_1: finished piece 1 at 17-JAN-11
piecehandle=/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_17/o1_mf_ncnnf_TAG20110117T195906_6m8crckx_.bkptag=TAG20110117T195906
comment=NONE
channelORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at17-JAN-11
接下来，控制文件损坏，那我怎么知道控制文件在哪呢？
方法一：
select * fromv$controlfile;
STATUS
NAME IS_RECOVE BLOCK_SIZE FILE_SIZE_BLKS
/home/oracle/app/oracle/oradata/ORCL/controlfile/o1_mf_6lzo7cmw_.ctl NO
16384 430
/home/oracle/app/oracle/flash_recovery_area/ORCL/controlfile/o1_mf_6lzo7cvq_.ctl YES
16384 430
方法二：
SQL> conn / assysdba
Connected.
SQL> showparameter control_files
NAME TYPE
VALUE
----------------------------------------------- ------------------------------
control_files string
/home/oracle/app/oracle/oradat
a/ORCL/controlfile/o1_mf_6lzo7
cmw_.ctl,/home/oracle/app/ora
cle/flash_recovery_area/ORCL/c
ontrolfile/o1_mf_6lzo7cvq_.ctl
好了，删除控制文件
[oracle@ocpdbbackup]$ rm -rf/home/oracle/app/oracle/oradata/ORCL/controlfile/o1_mf_6lzo7cmw_.ctl
[oracle@ocpdbbackup]$ rm -rf/home/oracle/app/oracle/flash_recovery_area/ORCL/controlfile/o1_mf_6lzo7cvq_.ctl
[oracle@ocpdbbackup]$
SQL> shutdownabort
ORACLE instanceshut down.
SQL> startupnomount
ORACLE instancestarted.
Total SystemGlobal Area 452984832 bytes
Fixed Size 1219952 bytes
Variable Size 134218384 bytes
DatabaseBuffers 314572800 bytes
Redo Buffers 2973696 bytes
（为什么STARTUP NOMOUNT?因为你已经MOUNT不起来了，控制文件删了，看：
SQL> alterdatabase mount;
alter databasemount
*
ERROR at line 1:
ORA-00205: errorin identifying control file, check alert log for more info
[oracle@ocpdborcl]$ rman target /
Recovery Manager:Release 10.2.0.1.0 - Production on Mon Jan 17 20:00:41 2011
Copyright (c)1982, 2005, Oracle. All rights reserved.
connected totarget database: orcl (not mounted)
RMAN> restorecontrolfile from'/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_17/o1_mf_ncnnf_TAG20110117T195906_6m8crckx_.bkp';
Starting restoreat 17-JAN-11
using targetdatabase control file instead of recovery catalog
allocated channel:ORA_DISK_1
channelORA_DISK_1: sid=155 devtype=DISK
channelORA_DISK_1: restoring control file
channelORA_DISK_1: restore complete, elapsed time: 00:00:03
outputfilename=/home/oracle/app/oracle/oradata/orcl/control01.ctl
outputfilename=/home/oracle/app/oracle/oradata/orcl/control02.ctl
outputfilename=/home/oracle/app/oracle/oradata/orcl/control03.ctl
Finished restoreat 17-JAN-11
RMAN> alterdatabase mount;
database mounted
released channel:ORA_DISK_1
（在RMAN中，你把控制文件拷回来还不够，还要手动MOUNT一下，而在SQLPLUS用控制文件脚本恢复时，它会帮你MOUNT，这就是区别）
RMAN> recoverdatabase;
Starting recoverat 17-JAN-11
Starting implicitcrosscheck backup at 17-JAN-11
allocated channel:ORA_DISK_1
channelORA_DISK_1: sid=155 devtype=DISK
Finished implicitcrosscheck backup at 17-JAN-11
Starting implicitcrosscheck copy at 17-JAN-11
using channelORA_DISK_1
Finished implicitcrosscheck copy at 17-JAN-11
searching for allfiles in the recovery area
catalogingfiles...
cataloging done
List of CatalogedFiles
=======================
File Name:/home/oracle/app/oracle/flash_recovery_area/ORCL/backupset/2011_01_17/o1_mf_ncnnf_TAG20110117T225501_6m8p279b_.bkp
using channelORA_DISK_1
starting mediarecovery
archive log thread1 sequence 2 is already on disk as file/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_17/o1_mf_1_2_6m8p0h1j_.arc
archive log thread1 sequence 3 is already on disk as file/home/oracle/app/oracle/oradata/orcl/redo02.log
archive logfilename=/home/oracle/app/oracle/flash_recovery_area/ORCL/archivelog/2011_01_17/o1_mf_1_2_6m8p0h1j_.arcthread=1 sequence=2
archive logfilename=/home/oracle/app/oracle/oradata/orcl/redo02.log thread=1 sequence=3
media recoverycomplete, elapsed time: 00:00:10
Finished recoverat 17-JAN-11
想直接OPEN吗？
RMAN> alterdatabase open;
RMAN-00571:===========================================================
RMAN-00569:=============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571:===========================================================
RMAN-03002:failure of alter db command at 01/17/2011 23:05:54
ORA-01589: mustuse RESETLOGS or NORESETLOGS option for database open
RMAN> alterdatabase open resetlogs;
database opened
（不能直接OPEN，所以说这种情况下爱用脚本备份的控制文件去恢复，因为用备份的二进制控制文件去恢复，数据在是在，但是需要RESETLOGS，INCARNATION当然是越少越好，不是吗？）
SQL> select *from hr.test;
A
----------
liujie
（看到没，RESETLOGS数据也还在，最关键的是你的日志在，这点最重要。如果日志也损坏那数据肯定会丢了，多或少的问题而已。）
RMAN> listincarnation of database;
List of DatabaseIncarnations
DB Key Inc Key DB Name
DB ID STATUS Reset SCN Reset Time
------- --------------- ---------------- --- ---------- ----------
1 1 ORCL
1268479776 PARENT 1 30-JUN-05
2 2 ORCL
1268479776 PARENT 446075 17-JAN-11
3 3 ORCL
1268479776 CURRENT 484356 17-JAN-11
（INCARNATION又多了一个，因为你RESETLOGS，又换代了。）
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- Oracle 备份恢复 31个实验 准备工作
- Oracle 备份恢复 31个实验 1-6
- Oracle 备份恢复 31个实验 13-18
- Oracle 备份恢复 31个实验 19-24
- Oracle 备份恢复 31个实验 25-31
- oracle: OCA-047-题解与实验(12)--Create table的常见写法
- oracle: ocp题解与实验(12 & 13/205)
- Oracle12--DDL触发器(五十七)
- oracle实验-目录
- oracle实验42：编写包package
- 《Oracle Applications DBA 基础》 - 11 - 12 FNDCPASS ，FND_STATS 和 FNDLOAD
- 6 关于 Oracle NULL栏位和PL./SQL执行实验
- oracle 备份恢复概要介绍
- oracle实验记录 （flashback）
- Linux udev 动态管理Oracle ASM磁盘-实验
- 1-12 实验10 网络管理实验2 已知网络地址查询MAC地址
- [转]Oracle DataGuard学习、实验笔记
- Oracle PLSQL Demo - 12.定义包体[Define PACKAGE BODY]
- 实验一 VMware Workstation 12的安装
- [Oracle Streams] 初步实验Oracle Streams