Oracle RESETLOGS 和 NORESETLOGS 区别说明
一．创建控制文件时：Resetlogs和Noresetlogs
当我们将控制文件备份到trace 文件时，可以看到里面包含了2部分的重建语句，一个是使用resetlogs，另一个是使用noresetlogs。
备份控制文件的SQL 如下：
SQL>alterdatabase backup controlfile to trace
有关控制文件的详细说明，参考：
http://blog.csdn.net/tianlesoftware/article/details/4974440
Set #1. NORESETLOGS case
The followingcommands will create a new control file and use it to open the database. Dataused by Recovery Manager will be lost.
Additional logsmay be required for media recovery of offline.
Use this only ifthe current versions of all online logs are available.
--使用noresetlogs仅是当前所有的online logs可用时。
Set #2. RESETLOGS case
The followingcommands will create a new control file and use it to open the database. Dataused by Recovery Manager will be lost.
The contents ofonline logs will be lost and all backups will be invalidated. Use this only ifonline logs are damaged.
--使用resetlogs，将导致online logs里的内容丢失，并且所有的备份失效，仅当online logs 随坏的情况下，才使用resetlos模式。
CREATE CONTROLFILE REUSE DATABASE"DAVE" RESETLOGS/NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 2
MAXDATAFILES 30
MAXINSTANCES 1
MAXLOGHISTORY 292
LOGFILE
GROUP 1'/u01/app/oracle/oradata/dave/redo01.log' SIZE 50M,
GROUP 2'/u01/app/oracle/oradata/dave/redo02.log' SIZE 50M,
GROUP 3'/u01/app/oracle/oradata/dave/redo03.log' SIZE 50M
-- STANDBY LOGFILE
DATAFILE
'/u01/app/oracle/oradata/dave/system01.dbf',
'/u01/app/oracle/oradata/dave/undotbs01.dbf',
'/u01/app/oracle/oradata/dave/sysaux01.dbf',
'/u01/app/oracle/oradata/dave/users01.dbf'
CHARACTER SET ZHS16GBK
;
二．打开数据库时：Resetlogs 和Noresetlogs
2.1 说明
Use RESETLOGSafter incomplete recovery (when the entire redo stream wasn't applied).RESETLOGS will initialize the logs, reset your log sequence number, and start anew "incarnation" of the database.
--RESETLOGS会初始化logs，重置log sequence号，创建一个新的incarnation。
Use NORESETLOGSwhen doing complete recovery (when the entire redo stream was applied). Oraclewill continue using the existing (valid) log files.
--NORESETLOGS 会继续使用已经存在，且有效的log files。
可以使用RMAN命令查看incarnation的信息：
RMAN> list incarnation;
更多内容参考：
RMAN 系列（八）---- RMAN List和report命令
http://blog.csdn.net/tianlesoftware/article/details/5728116
http://blog.csdn.net/tianlesoftware/article/details/4682463
做不完全恢复必须使用resetlogs, resetlogs也可以做完全恢复。而noresetlogs则是必须做完全恢复时使用。resetlogs会重置日志序列号强制清空或重建REDO，而noresetlogs则不会这么做。
2.2 MOS 上对这个RESETLOGS和NORESETLOGS的说明：
Physical Backup and Recovery: An Insider'sPerspective [ID 16530.1]：
After recoverdatabase operation, open the database with: ALTER DATABASE OPEN [NO]RESETLOGS
（1） NORESETLOGS
The NORESETLOGSoption does not clear the redo log files during startup and the online redologs to be used for recovery. Only used in scenario where MANUAL RECOVERY isstarted, CANCEL is used, and then RECOVER DATABASE is started.
（2）RESETLOGS
CAUTION: Never use RESETLOGS unlessnecessary.
Once RESETLOGS is used then the redo logfiles cannot be used and any completed transactions in those redo logs arelost!!
Before using the RESETLOGS option take anoffline backup of the database.
The RESETLOGSoption clears all the online redo logs and modifies all the online data filesto indicate no recovery is needed. After resetting the redo logs none of theexisting log files or data file backups can be used.
In the control file, the log sequence number is modified,which is very important for recovery purposes. Therecovery will be applied only to the log files whose sequence number is greaterthan log sequence number in the control file. One has to be very cautious whenusing RESETLOGS option. It is important to remember that all datafiles must beonline otherwise they will become useless once the database is up。
2.3 几种情况的说明
（1） 第一种情况
假设仅仅控制文件丢失，而其他文件没有丢失（主要是归档和REDO），那么恢复的时候如果选择从备份中恢复控制文件。恢复后，控制文件会去读数据文件头中与CHECKPOINT SCN对应的RBA信息来确定从那个序列的归档日志开始恢复，一直推进恢复到NEXT SCN是无穷大的那个REDOLOG，此时恢复是完全恢复的，但打开的时候还要以resetlogs方式打开，这样要重置归档日志的sequence，也就是说，如果你恢复时使用了备份控制文件，那么打开数据库时必然是要resetlogs的。
不完全恢复时是必须RESETLOGS，但是完全恢复时如果使用备份控制文件来恢复，那么使用RESETLOGS一样可以完全恢复。但是丢失控制文件也可以不使用RESETLOGS方式打开数据库，这样也就可以避免重置日志序列号带来的不变，详情请见第四种情况。
（2） 第二种情况
不完全恢复，不管是要什么样的不完全恢复，SCN，TIME，跨越REDO，都必须使用resetlogs。
（3） 第三种情况
丢失REDOLOG，这就更需要resetlogs了，因为resetlogs能够重建REDOLOG。如果你的REDOLOG、控制文件、数据文件丢失的话，需要先恢复控制文件，然后restore database;recover database;alter database open resetlogs;
注意，这时候做的是不完全恢复，因为REDO没有了。在recover过程中可能会报错然后自动退出RMAN，无视，alter database open resetlogs即可，
（4） 第四种情况
没有丢失控制文件及各种日志，仅丢失数据文件，这种问题比较常见，有可能磁盘损坏造成数据文件丢失，等磁盘故障排除后，需要恢复，此时的恢复就很简单了，restore database;recover database;alter database open;就一切OK，也就是说，在不使用备份控制文件恢复的情况下，是可以使用noresetlog方式打开数据库的。
前提有一，不能丢失日志文件。假若丢失了控制文件和数据文件但还是想以noresetlog打开的话，就必须手动以noresetlogs方式重建控制文件，而且REDOLOG的状态都必须正常，否则是无法使用noresetlogs方式打开。
几种情况的分析转自一下Blog：
http://space.itpub.net/16628454/viewspace-524593
最近做试验求证出这两个选项到底是什么作用：
很多人说，resetlogs就是不完全恢复，这是不对的，做不完全恢复必须使用resetlogs，但resetlogs也可以做完全恢复。而noresetlogs则是必须做完全恢复时使用。resetlogs会重置日志序列号强制清空或重建REDO，而noresetlogs则不会这么做。
数据库恢复分完全恢复和不完全恢复，完全恢复就是完整恢复数据库全部数据，但是完全恢复也要根据丢失的文件类型有所区分。
第一种情况，我们假设仅仅控制文件丢失，而其他文件没有丢失（主要是归档和REDO），那么恢复的时候如果选择从备份中恢复控制文件。恢复后，控制文件会去读数据文件头中与CHECKPOINT SCN对应的RBA信息来确定从那个序列的归档日志开始恢复，一直推进恢复到NEXT SCN是无穷大的那个REDOLOG，此时恢复是完全恢复的，但打开的时候还要以resetlogs方式打开，这样要重置归档日志的sequence，也就是说，如果你恢复时使用了备份控制文件，那么打开数据库时必然是要resetlogs的。附测试用例：
SQL> archive log list;
数据库日志模式 存档模式
自动存档 启用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 35
下一个存档日志序列 37
当前日志序列 37
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ------------
FIRST_CHANGE# FIRST_TIME
------------- --------------
1 1 37 52428800 1 NO CURRENT
341837 29-12月-08
2 1 35 52428800 1 YES ACTIVE
341817 29-12月-08
3 1 36 52428800 1 YES ACTIVE
341827 29-12月-08
SQL> select count(*) from t;
COUNT(*)
----------
30
10条记录在备份中，10条在归档日志中，10条在当前的REDO中，以下模拟控制文件丢失
SQL> shutdown abort;
ORACLE 例程已经关闭。
SQL> exit
从 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options 断
开
C:\Documents and Settings\Administrator>del G:\oradata\orcl\*.CTL
C:\Documents and Settings\Administrator>rman target /
恢复管理器: Release 11.1.0.6.0 - Production on 星期一 12月 29 17:41:07 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
已连接到目标数据库 (未启动)
RMAN> startup nomount;
Oracle 实例已启动
系统全局区域总计 535662592 字节
Fixed Size 1334380 字节
Variable Size 213910420 字节
Database Buffers 314572800 字节
Redo Buffers 5844992 字节
RMAN> restore controlfile from 'G:\backup\CTL_C-1202355191-20081229-02';
启动 restore 于 29-12月-08
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=153 设备类型=DISK
通道 ORA_DISK_1: 正在还原控制文件
通道 ORA_DISK_1: 还原完成, 用时: 00:00:07
输出文件名=G:\ORADATA\ORCL\CONTROL01.CTL
输出文件名=G:\ORADATA\ORCL\CONTROL02.CTL
输出文件名=G:\ORADATA\ORCL\CONTROL03.CTL
完成 restore 于 29-12月-08
RMAN> alter database mount;
数据库已装载
释放的通道: ORA_DISK_1
RMAN> recover database;
启动 recover 于 29-12月-08
启动 implicit crosscheck backup 于 29-12月-08
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=153 设备类型=DISK
已交叉检验的 3 对象
完成 implicit crosscheck backup 于 29-12月-08
启动 implicit crosscheck copy 于 29-12月-08
使用通道 ORA_DISK_1
完成 implicit crosscheck copy 于 29-12月-08
搜索恢复区中的所有文件
正在编制文件目录...
目录编制完毕
已列入目录的文件的列表
=======================
文件名: G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_27_4OK6HKRW_.
RC
文件名: G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_28_4OK6J11G_.
RC
文件名: G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_29_4OK6JKBQ_.
RC
文件名: G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_30_4OK6K37T_.
RC
文件名: G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_31_4OK6KO7B_.
RC
文件名: G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_32_4OK6L76C_.
RC
文件名: G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_33_4OK6LS8S_.
RC
文件名: G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_34_4OK6MCHN_.
RC
文件名: G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_35_4OK6MX8S_.
RC
文件名: G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_36_4OK6NH6T_.
RC
使用通道 ORA_DISK_1
正在开始介质的恢复
线程 1 序列 27 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008
12_29\O1_MF_1_27_4OK6HKRW_.ARC 存在于磁盘上
线程 1 序列 28 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008
12_29\O1_MF_1_28_4OK6J11G_.ARC 存在于磁盘上
线程 1 序列 29 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008
12_29\O1_MF_1_29_4OK6JKBQ_.ARC 存在于磁盘上
线程 1 序列 30 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008
12_29\O1_MF_1_30_4OK6K37T_.ARC 存在于磁盘上
线程 1 序列 31 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008
12_29\O1_MF_1_31_4OK6KO7B_.ARC 存在于磁盘上
线程 1 序列 32 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008
12_29\O1_MF_1_32_4OK6L76C_.ARC 存在于磁盘上
线程 1 序列 33 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008
12_29\O1_MF_1_33_4OK6LS8S_.ARC 存在于磁盘上
线程 1 序列 34 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008
12_29\O1_MF_1_34_4OK6MCHN_.ARC 存在于磁盘上
线程 1 序列 35 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008
12_29\O1_MF_1_35_4OK6MX8S_.ARC 存在于磁盘上
线程 1 序列 36 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008
12_29\O1_MF_1_36_4OK6NH6T_.ARC 存在于磁盘上
线程 1 序列 37 的归档日志已作为文件 G:\ORADATA\ORCL\REDO01.LOG 存在于磁盘上
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_27_4OK
HKRW_.ARC 线程=1 序列=27
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_28_4OK
J11G_.ARC 线程=1 序列=28
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_29_4OK
JKBQ_.ARC 线程=1 序列=29
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_30_4OK
K37T_.ARC 线程=1 序列=30
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_31_4OK
KO7B_.ARC 线程=1 序列=31
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_32_4OK
L76C_.ARC 线程=1 序列=32
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_33_4OK
LS8S_.ARC 线程=1 序列=33
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_34_4OK
MCHN_.ARC 线程=1 序列=34
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_35_4OK
MX8S_.ARC 线程=1 序列=35
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_36_4OK
NH6T_.ARC 线程=1 序列=36
归档日志文件名=G:\ORADATA\ORCL\REDO01.LOG 线程=1 序列=37 ------这一步注意看，是重点，是RESETLOGS方式自动恢复的
介质恢复完成, 用时: 00:00:05
完成 recover 于 29-12月-08
RMAN> exit
恢复管理器完成。
C:\Documents and Settings\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.1.0.6.0 - Production on 星期一 12月 29 17:43:30 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
连接到:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项
SQL> alter database open resetlogs;
数据库已更改。
SQL> select count(*) from nam.t;
COUNT(*)
----------
30
SQL> archive log list;
数据库日志模式 存档模式
自动存档 启用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 1
下一个存档日志序列 1
当前日志序列 1
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- --------------
1 1 1 52428800 1 NO CURRENT
341863 29-12月-08
2 1 0 52428800 1 YES UNUSED
0
3 1 0 52428800 1 YES UNUSED
0
SQL>
至此完成完全恢复，事实证明不完全恢复时是必须RESETLOGS，但是完全恢复时如果使用备份控制文件来恢复，那么使用RESETLOGS一样可以完全恢复。但是丢失控制文件也可以不使用RESETLOGS方式打开数据库，这样也就可以避免重置日志序列号带来的不变，详情请见第四种情况
第二种情况，不完全恢复，不管你是要什么样的不完全恢复，SCN，TIME，跨越REDO，都必须使用resetlogs。测试用例可以参见EYGLE老师的相关教程。
第三种情况，丢失REDOLOG，这就更需要resetlogs了，因为resetlogs能够重建REDOLOG。如果你的REDOLOG、控制文件、数据文件丢失的话，需要先恢复控制文件，然后restore database;recover database;alter database open resetlogs;注意，这时候做的是不完全恢复，因为REDO没有了。在recover过程中可能会报错然后自动退出RMAN，无视，alter database open resetlogs即可，附测试用例：
C:\Documents and Settings\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.1.0.6.0 - Production on 星期一 12月 29 15:12:57 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
连接到:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> shutdown abort;
ORACLE 例程已经关闭。
SQL> exit
从 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options 断
开
C:\Documents and Settings\Administrator>rman target /
恢复管理器: Release 11.1.0.6.0 - Production on 星期一 12月 29 15:13:30 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
已连接到目标数据库 (未启动)
RMAN> startup nomount;
Oracle 实例已启动
系统全局区域总计 535662592 字节
Fixed Size 1334380 字节
Variable Size 213910420 字节
Database Buffers 314572800 字节
Redo Buffers 5844992 字节
RMAN> restore controlfile from 'g:\backup\CTRL_C-1202355191-20081229-05'
2> ;
启动 restore 于 29-12月-08
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=153 设备类型=DISK
通道 ORA_DISK_1: 正在还原控制文件
通道 ORA_DISK_1: 还原完成, 用时: 00:00:07
输出文件名=G:\ORADATA\ORCL\CONTROL01.CTL
输出文件名=G:\ORADATA\ORCL\CONTROL02.CTL
输出文件名=G:\ORADATA\ORCL\CONTROL03.CTL
完成 restore 于 29-12月-08
RMAN> alter database mount;
数据库已装载
释放的通道: ORA_DISK_1
RMAN> restore database;
启动 restore 于 29-12月-08
启动 implicit crosscheck backup 于 29-12月-08
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=153 设备类型=DISK
已交叉检验的 14 对象
完成 implicit crosscheck backup 于 29-12月-08
启动 implicit crosscheck copy 于 29-12月-08
使用通道 ORA_DISK_1
完成 implicit crosscheck copy 于 29-12月-08
搜索恢复区中的所有文件
正在编制文件目录...
没有为文件编制目录
使用通道 ORA_DISK_1
通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00001 还原到 G:\ORADATA\ORCL\SYSTEM01.DBF
通道 ORA_DISK_1: 将数据文件 00002 还原到 G:\ORADATA\ORCL\SYSAUX01.DBF
通道 ORA_DISK_1: 将数据文件 00003 还原到 G:\ORADATA\ORCL\UNDOTBS01.DBF
通道 ORA_DISK_1: 将数据文件 00004 还原到 G:\ORADATA\ORCL\USERS01.DBF
通道 ORA_DISK_1: 将数据文件 00005 还原到 G:\ORADATA\ORCL\NAM01.DBF
通道 ORA_DISK_1: 正在读取备份片段 G:\BACKUP\B__20081229_28_1
通道 ORA_DISK_1: 段句柄 = G:\BACKUP\B__20081229_28_1 标记 = TAG20081229T142045
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:01:05
完成 restore 于 29-12月-08
RMAN> recover database;
启动 recover 于 29-12月-08
使用通道 ORA_DISK_1
正在开始介质的恢复
线程 1 序列 7 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_1
2_29\O1_MF_1_7_4OJV5T1Y_.ARC 存在于磁盘上
线程 1 序列 8 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_1
2_29\O1_MF_1_8_4OJV6989_.ARC 存在于磁盘上
线程 1 序列 9 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_1
2_29\O1_MF_1_9_4OJWKFC7_.ARC 存在于磁盘上
线程 1 序列 10 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_
12_29\O1_MF_1_10_4OJWKCNZ_.ARC 存在于磁盘上
线程 1 序列 11 的归档日志已作为文件 G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_
12_29\O1_MF_1_11_4OJWKDKL_.ARC 存在于磁盘上
通道 ORA_DISK_1: 正在开始将归档日志还原到默认目标
通道 ORA_DISK_1: 正在还原归档日志
归档日志线程=1 序列=6
通道 ORA_DISK_1: 正在读取备份片段 G:\BACKUP\B__20081229_29_1
通道 ORA_DISK_1: 段句柄 = G:\BACKUP\B__20081229_29_1 标记 = TAG20081229T142204
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:00:01
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_6_4OJYG
PD6_.ARC 线程=1 序列=6
通道 default: 正在删除归档日志
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_6_4OJYG
PD6_.ARC RECID=113 STAMP=674752726
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_7_4OJV5
T1Y_.ARC 线程=1 序列=7
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_8_4OJV6
989_.ARC 线程=1 序列=8
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_9_4OJWK
FC7_.ARC 线程=1 序列=9
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_10_4OJW
KCNZ_.ARC 线程=1 序列=10
归档日志文件名=G:\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2008_12_29\O1_MF_1_11_4OJW
KDKL_.ARC 线程=1 序列=11
无法找到归档日志
归档日志线程=1 序列=1
DBGANY: Mismatched message length! [15:18:53.296] (krmiduem)
DBGANY: Mismatched message length! [15:18:53.296] (krmiduem)
………………………………
RMAN> alter database open resetlogs;
使用目标数据库控制文件替代恢复目录
数据库已打开
RMAN> exit
SQL> select * from nam.t;
ID TDATE TSCN
---------- -------------- ----------
1 29-12月-08 339936
2 29-12月-08 339946
3 29-12月-08 339956
4 29-12月-08 339966
1 29-12月-08 339996
2 29-12月-08 339996
3 29-12月-08 339996
4 29-12月-08 339996
1 29-12月-08 340131
2 29-12月-08 340141
3 29-12月-08 340151
ID TDATE TSCN
---------- -------------- ----------
4 29-12月-08 340161
已选择12行。
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ---------------
FIRST_CHANGE# FIRST_TIME
------------- --------------
1 1 1 52428800 1 NO CURRENT
340183 29-12月-08
2 1 0 52428800 1 YES UNUSED
0
3 1 0 52428800 1 YES UNUSED
0
SQL>
从数据验证的结果来看，除了REDO里面的记录没有恢复，其他基本都恢复了，REDO及ARCHIVELOG的序列被重置。
第四种情况，没有丢失控制文件及各种日志，仅丢失数据文件，这种问题比较常见，有可能磁盘损坏造成数据文件丢失，等磁盘故障排除后，需要恢复，此时的恢复就很简单了，restore database;recover database;alter database open;就一切OK，也就是说，在不使用备份控制文件恢复的情况下，是可以使用noresetlog方式打开数据库的。前提有一，不能丢失日志文件。假若丢失了控制文件和数据文件但还是想以noresetlog打开的话，就必须手动以noresetlogs方式重建控制文件，而且REDOLOG的状态都必须正常，否则是无法使用noresetlogs方式打开。
SQL> select count(*) from t;
COUNT(*)
----------
32
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- -------------
FIRST_CHANGE# FIRST_TIME
------------- --------------
1 1 19 52428800 1 YES ACTIVE
340578 29-12月-08
2 1 20 52428800 1 YES ACTIVE
340588 29-12月-08
3 1 21 52428800 1 NO CURRENT
340598 29-12月-08
SQL> archive log list;
ORA-01031: 权限不足
SQL> conn / as sysdba
已连接。
SQL> archive log list;
数据库日志模式 存档模式
自动存档 启用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 19
下一个存档日志序列 21
当前日志序列 21
SQL> exit
从 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options 断
开
C:\Documents and Settings\Administrator>rman target /
恢复管理器: Release 11.1.0.6.0 - Production on 星期一 12月 29 15:52:36 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
连接到目标数据库: ORCL (DBID=1202355191)
RMAN> backup database plus archivelog delete all input;
……………………过程省略………………………………由于我之前数据库备份搞的序列都乱了，所以需要重新备份用于这个测试，这里我只模拟丢失控制文件的情况
SQL> conn nam/nam
已连接。
SQL> begin
2 for i in 1 .. 10 loop
3 insert into t values(i,sysdate,dbms_flashback.get_system_change_number);
4 commit;
5 execute immediate 'alter system switch logfile';
6 dbms_lock.sleep(15);
7 end loop;
8 end;
9 /
PL/SQL 过程已成功完成。
SQL> begin
2 for i in 1 .. 10 loop
3 insert into t values(i,sysdate,dbms_flashback.get_system_change_number);
4 end loop;
5 commit;
6 end;
7 /
PL/SQL 过程已成功完成。
SQL> select count(*) from t;
COUNT(*)
----------
52
32条记录在备份中，10条在归档中，10条在redo中
SQL> shutdown abort;
ORA-01031: 权限不足
SQL> conn / as sysdba
已连接。
SQL> shutdown abort;
ORACLE 例程已经关闭。
SQL>exit
C:\Documents and Settings\Administrator>rman target /
恢复管理器: Release 11.1.0.6.0 - Production on 星期一 12月 29 16:10:09 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
已连接到目标数据库 (未启动)
RMAN> startup nomount;
Oracle 实例已启动
系统全局区域总计 535662592 字节
Fixed Size 1334380 字节
Variable Size 213910420 字节
Database Buffers 314572800 字节
Redo Buffers 5844992 字节
RMAN> restore controlfile from 'g:\backup\CTRL_C-1202355191-20081229-07';
………………………………（过程由于粗心没有及时复制）
RMAN> alter database mount;
………………………………（过程由于粗心没有及时复制）
RMAN> restore database;
………………………………（过程由于粗心没有及时复制）
SQL> shutdown abort;
ORACLE 例程已经关闭。
SQL> startup nomount;
ORACLE 例程已经启动。
Total System Global Area 535662592 bytes
Fixed Size 1334380 bytes
Variable Size 213910420 bytes
Database Buffers 314572800 bytes
Redo Buffers 5844992 bytes
SQL> alter database mount;
数据库已更改。
SQL> alter database backup controlfile to trace;
数据库已更改。
SQL> shutdown abort;
ORACLE 例程已经关闭。
SQL> startup nomount;
ORACLE 例程已经启动。
Total System Global Area 535662592 bytes
Fixed Size 1334380 bytes
Variable Size 213910420 bytes
Database Buffers 314572800 bytes
Redo Buffers 5844992 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS ARCHIVELOG
2 MAXLOGFILES 16
3 MAXLOGMEMBERS 3
4 MAXDATAFILES 100
5 MAXINSTANCES 8
6 MAXLOGHISTORY 292
7 LOGFILE
8 GROUP 1 'G:\ORADATA\ORCL\REDO01.LOG' SIZE 50M,
9 GROUP 2 'G:\ORADATA\ORCL\REDO02.LOG' SIZE 50M,
10 GROUP 3 'G:\ORADATA\ORCL\REDO03.LOG' SIZE 50M
11 -- STANDBY LOGFILE
12 DATAFILE
13 'G:\ORADATA\ORCL\SYSTEM01.DBF',
14 'G:\ORADATA\ORCL\SYSAUX01.DBF',
15 'G:\ORADATA\ORCL\UNDOTBS01.DBF',
16 'G:\ORADATA\ORCL\USERS01.DBF',
17 'G:\ORADATA\ORCL\NAM01.DBF'
18 CHARACTER SET ZHS16GBK
19 ;
控制文件已创建。
SQL> recover database;
完成介质恢复。
SQL> select count(*) from nam.t;
COUNT(*)
----------
52
SQL>
另外，如果丢失初始化参数文件，也不过是在开头多了一个恢复步骤而已
About Me
...............................................................................................................................
● 本文整理自网络
● QQ群：230161599 微信群：私聊
● 联系我请加QQ好友(642808185)，注明添加缘由
● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解
● 版权所有，欢迎分享本文，转载请保留出处
...............................................................................................................................
拿起手机使用微信客户端扫描下边的左边图片来关注小麦苗的微信公众号：xiaomaimiaolhr，扫描右边的二维码加入小麦苗的QQ群，学习最实用的数据库技术。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26736162/viewspace-2134187/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/26736162/viewspace-2134187/
1413
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
