环境说明
 
OS操作系统：WINDOWS 2012 64位
 
数据库版 本：ORACLE 11.2.0.1
 
故障问题描述
 
客户反映数据库无法启动，报ORA-01589：要打开数据库必须使用RESETLOGS或NORESETLOGS选项。使用alter database open
 
resetlogs启动数据库报ORA-01194：文件1需要更多恢复来保持一致性，ORA-01110：数据文件1：‘E:\APP\YING_LUN\ORADATA\ORCL\SYSTEM01.DBF’。
 
故障分析
 
1、在网上搜索相关文档，对于这样的问题需要进行控制文件恢复：
 
SQL> recover database using backup controlfile;
 
由于数据库在出故障之前没有开启归档日志，因为找不到需要的归档日志控制文件恢复失败。
 
2.使用NORESETLOGS方式重建控制文件
 
目前数据库可以启动到MOUNT状态，可以备份控制文件创建脚本到TRACE文件中，获取控制文件创建脚本
 
SQL>alter database backup controlfile to trace;
 
==>在11G中可以通过v$diag_info视图查看备份的TRACE文件的位置
 
SQL> select value from v$diag_info where name='Default Trace
 
File';
 
==>把TRACE文件中的NORESETLOGS方式创建控制文件的SQL语句复制到create.sql脚本
 
STARTUP NOMOUNT
 
CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGSARCHIVELOG
 
MAXLOGFILES 16
 
MAXLOGMEMBERS 3
 
MAXDATAFILES 100
 
MAXINSTANCES 8
 
MAXLOGHISTORY 584
 
LOGFILE
 
GROUP 1
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO01.LOG'SIZE 500M BLOCKSIZE 512,
 
GROUP 2
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO02.LOG'SIZE 500M BLOCKSIZE 512,
 
GROUP 3
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO03.LOG'SIZE 500M BLOCKSIZE 512,
 
GROUP 4 'E:\APP\YING_LIU\ORADATA\ORCL\REDO04.LOG'SIZE 500M BLOCKSIZE 512,
 
GROUP 5
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO05.LOG'SIZE 500M BLOCKSIZE 512,
 
GROUP 6
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO06.LOG'SIZE 500M BLOCKSIZE 512
 
-- STANDBY LOGFILE
 
DATAFILE
 
'E:\APP\YING_LIU\ORADATA\ORCL\SYSTEM01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\SYSAUX01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\UNDOTBS01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\USERS01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\EXAMPLE01.DBF',
 
'E:\APP\TABLESPACE\MALASONG.DBF',
 
'E:\APP\TABLESPACE\WX_REDPACKET.DBF',
 
'D:\ORACLE\ORCL\SIGNIN_USER_TEST.DBF',
 
'E:\APP\TABLESPACE\EXAM_SYSTEM.DBF',
 
'E:\APP\TABLESPACE\EXAM_SYSTEM_TEST.DBF',
 
'E:\APP\TABLESPACE\ICLUB.DBF',
 
'E:\APP\TABLESPACE\PINBAO.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\SYSTEM3.DBF'
 
CHARACTER SET ZHS16GBK
 
;
 
==>执行create.sql脚本重建控制文件
 
SQL> shutdown immediate;
 
SQL>@create.sql
 
==>执行create.sql脚本时报错日志组5与日志文件redo5.log不匹配。在网上搜索到的资料建议删除日志组相关内容或使用RESETLOGS方式创建控制文件，于是删除日志文件相关内容。
 
STARTUP NOMOUNT
 
CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGSARCHIVELOG
 
MAXLOGFILES 16
 
MAXLOGMEMBERS 3
 
MAXDATAFILES 100
 
MAXINSTANCES 8
 
MAXLOGHISTORY 584
 
LOGFILE
 
-- STANDBY LOGFILE
 
DATAFILE
 
'E:\APP\YING_LIU\ORADATA\ORCL\SYSTEM01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\SYSAUX01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\UNDOTBS01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\USERS01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\EXAMPLE01.DBF',
 
'E:\APP\TABLESPACE\MALASONG.DBF',
 
'E:\APP\TABLESPACE\WX_REDPACKET.DBF',
 
'D:\ORACLE\ORCL\SIGNIN_USER_TEST.DBF',
 
'E:\APP\TABLESPACE\EXAM_SYSTEM.DBF',
 
'E:\APP\TABLESPACE\EXAM_SYSTEM_TEST.DBF',
 
'E:\APP\TABLESPACE\ICLUB.DBF',
 
'E:\APP\TABLESPACE\PINBAO.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\SYSTEM3.DBF'
 
CHARACTER SET ZHS16GBK
 
;
 
==>执行修改后的 create.sql报数据库名与SPFILE中的DB_NAME不一致，经检查数据库名称与SPFILE
 
==>在的DB_NAME是一致。于是决定使用 RESETLOGS方式重建控制文件。
 
;
 
3、使用RESETLOGS方式重建控制文件：
 
==>把 RESETLOGS方式创建控制文件的脚本复制到create_2.sql文件中
 
STARTUP NOMOUNT
 
CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGSARCHIVELOG
 
MAXLOGFILES 16
 
MAXLOGMEMBERS 3
 
MAXDATAFILES 100
 
MAXINSTANCES 8
 
MAXLOGHISTORY 584
 
LOGFILE
 
GROUP 1
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO01.LOG'SIZE 500M BLOCKSIZE 512,
 
GROUP 2
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO02.LOG'SIZE 500M BLOCKSIZE 512,
 
GROUP 3
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO03.LOG'SIZE 500M BLOCKSIZE 512,
 
GROUP 4
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO04.LOG'SIZE 500M BLOCKSIZE 512,
 
GROUP 5
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO05.LOG'SIZE 500M BLOCKSIZE 512,
 
GROUP 6 'E:\APP\YING_LIU\ORADATA\ORCL\REDO06.LOG'SIZE 500M BLOCKSIZE 512
 
-- STANDBY LOGFILE
 
DATAFILE
 
'E:\APP\YING_LIU\ORADATA\ORCL\SYSTEM01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\SYSAUX01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\UNDOTBS01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\USERS01.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\EXAMPLE01.DBF',
 
'E:\APP\TABLESPACE\MALASONG.DBF',
 
'E:\APP\TABLESPACE\WX_REDPACKET.DBF',
 
'D:\ORACLE\ORCL\SIGNIN_USER_TEST.DBF',
 
'E:\APP\TABLESPACE\EXAM_SYSTEM.DBF',
 
'E:\APP\TABLESPACE\EXAM_SYSTEM_TEST.DBF',
 
'E:\APP\TABLESPACE\ICLUB.DBF',
 
'E:\APP\TABLESPACE\PINBAO.DBF',
 
'E:\APP\YING_LIU\ORADATA\ORCL\SYSTEM3.DBF'
 
CHARACTER SET ZHS16GBK
 
==>执行create_2.sql脚本重建控制文件,启动数据库报UNDO段 _SYSSMU8_1682283174$快照过旧。
 
SQL> shutdown immediate;
 
SQL>@create_2.sql
 
SQL> alter database openresetlogs;
 
alter database openresetlogs
 
*
 
第1行出现错误:
 
ORA-01092: ORACLE instance terminated.
 
Disconnection forced
 
ORA-00704: bootstrap process failure
 
ORA-00704: bootstrap process failure
 
ORA-00604: error occurred at recursive SQL
 
level 1
 
ORA-01555: snapshot too old: rollback
 
segment number 8 with name
 
"_SYSSMU8_1682283174$" too small
 
进程ID: 8600
 
会话ID: 576序列号:
 
1
 
4、推高数据库SCN：
 
经向同时请教觉得通过推高SCN跳过UNDO的回滚操作。
 
SQL> startupopenresetlogs;
 
ORACLE例程已经启动。
 
Total System Global Area 3423965184 bytes
 
Fixed Size2180544 bytes
 
Variable Size2566916672 bytes
 
Database Buffers838860800 bytes
 
Redo Buffers16007168 bytes
 
ORA-01504: ???? 'RESETLOGS' ??? db_name 'ORCL' ???
 
==>查看数据文件头的SCAN
 
select name,checkpoint_change# from v$datafile_header;
 
NAME
 
--------------------------------------------------------------------------------
 
CHECKPOINT_CHANGE#
 
----------------------------
 
E:\APP\YING_LIU\ORADATA\ORCL\SYSTEM01.DBF
 
10150360067303
 
.... ==>其他输出信息省略
 
==>重建控制文件，把数据库SCN推高一个亿，启动数据库仍然报错
 
SQL>@create_2.sql
 
SQL> alter session set
 
events '10015 trace name adjust_scn level 1';
 
SQL> alter database open resetlogs;
 
alter database open resetlogs
 
*
 
第1行出现错误:
 
ORA-01092: ORACLE instance terminated. Disconnection forced
 
ORA-00704: bootstrap process failure
 
ORA-00704: bootstrap process failure
 
ORA-00604: error occurred at recursive SQL level 1
 
ORA-01555: snapshot too old: rollback segment number 8 with name
 
"_SYSSMU8_1682283174$" too small
 
进程ID: 6420
 
会话ID: 576序列号: 1
 
==>最后把数据库SCN推高到1亿亿还是报错
 
SQL>@create_2.sql
 
SQL> alter session set
 
events '10015 trace name adjust_scn level 100000000';
 
SQL> alter database open resetlogs;
 
alter database open resetlogs
 
*
 
第1行出现错误:
 
ORA-01092: ORACLE instance terminated. Disconnection forced
 
ORA-00704: bootstrap process failure
 
ORA-00704: bootstrap process failure
 
ORA-00604: error occurred at recursive SQL level 1
 
ORA-01555: snapshot too old: rollback segment number 8 with name
 
"_SYSSMU8_1682283174$" too small
 
进程ID: 6420
 
会话ID: 576序列号: 1
 
==>最后查了下，在11.2.0.1中这个方法无法推高SCN，于是重建控制文件使用oradebug来推高数据库SCN,启动数据库时仍然报错，有可能是在WINDOWS 64位平台不支持oradebug推高SCN
 
SQL>@create_2.sql
 
SQL> select to_char('10150360067303','xxxxxxxxxxxxxxxxxxxxxx')
 
from dual;
 
TO_CHAR('10650360067303
 
-----------------------
 
9afbaedb4e7
 
SQL>oradebug setmypid
 
SQL>oradebug dumpvar sga kcsgscn_
 
SQL>oradebug poke 0x0082237B0 8 0x000012539f0dcce7
 
SQL>alter database open resetlogs;
 
alter database open resetlogs
 
*
 
第1行出现错误:
 
ORA-01092: ORACLE instance terminated. Disconnection forced
 
ORA-00704: bootstrap process failure
 
ORA-00704: bootstrap process failure
 
ORA-00604: error occurred at recursive SQL level 1
 
ORA-01555: snapshot too old: rollback segment number 8 with name
 
"_SYSSMU8_1682283174$" too small
 
进程ID: 6420
 
会话ID: 576序列号: 1
 
5、跳过有问题的UNDO段，强制打开数据库：
 
SQL>
 
alter system set "_allow_resetlogs_corruption"=true
 
scope=spfile; ==>允许跳过损坏的UNDO段
 
alter system set
 
"_corrupted_rollback_segments"='_SYSSMU8$' scope=spfile; ==>把有问题的UNDO段标记为坏的UDNO段。
 
==>启动数据库
 
SQL>alter database open resetlogs;
 
==>创建信息的UNDO表空间，并修改数据库的默认UNDO表空间为新的UNDO表空间
 
SQL>
 
create undo tablespace UNDO02 datafile
 
'E:\app\ying_liu\oradata\ORCL\undo02_01.dbf' size 2G autoextend on;
 
alter system set undo_tablespace=UNDO02 scope=both;
 
==>删除旧的UNDO表空间
 
alter tablespace undotbs1 offline normal;
 
drop tablespace UNDOTBS1 including contents and datafiles;
 
==>把SPFILE中的隐藏参数恢复默认值，重启数据库
 
SQL>
 
alter system reset "_allow_resetlogs_corruption"
 
scope=spfile;
 
alter system reset "_corrupted_rollback_segments"
 
scope=spfile;
 
SQL> startup;
 
至此故障解决，数据库正常启动。
 
5、为了找到控制文件出问题的原因分析数据库告警日志：
 
==> 2016年11月15日16:06:07启动数据库报无法找到REDO LOG的错误，可能是redo log损坏了，
 
==>也可是被删除了，这也是使用NORESETLOGS创建控制文件失败的原因
 
Tue Nov 15 16:06:07 2016
 
Starting ORACLE instance (normal)
 
.... ==>省略部分日志信息
 
Successful mount of redo thread 1, with mount id 1455795184
 
Database mounted in Exclusive Mode
 
Lost write protection disabled
 
Completed: alter database mount exclusive
 
alter database open
 
Beginning crash recovery of 1 threads
 
parallel recovery started
 
with 7 processes
 
Started redo scan
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_ora_11860.trc:
 
ORA-00313: ??????? 5 (???? 1) ???
 
ORA-00312: ???? 5 ?? 1: 'E:\APP\YING_LIU\ORADATA\ORCL\REDO05.LOG'
 
ORA-27041: ??????
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
Aborting crash recovery due to error 313
 
Errors in file e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_ora_11860.trc:
 
ORA-00313: ??????? 5 (???? 1) ???
 
ORA-00312: ???? 5 ?? 1: 'E:\APP\YING_LIU\ORADATA\ORCL\REDO05.LOG'
 
ORA-27041: ??????
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_ora_11860.trc:
 
ORA-00313: ??????? 5 (???? 1) ???
 
ORA-00312: ???? 5 ?? 1: 'E:\APP\YING_LIU\ORADATA\ORCL\REDO05.LOG'
 
ORA-27041: ??????
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
ORA-313 signalled during: alter database open...
 
Tue Nov 15 16:06:13 2016
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_m000_16324.trc:
 
ORA-00313: open failed for members of log group 1 of thread 1
 
ORA-00312: online log 1 thread 1:
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO01.LOG'
 
ORA-27041: unable to open file
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_m000_16324.trc:
 
ORA-00313: open failed for members of log group 2 of thread 1
 
ORA-00312: online log 2 thread 1:
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO02.LOG'
 
ORA-27041: unable to open file
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_m000_16324.trc:
 
ORA-00313: open failed for members of log group 3 of thread 1
 
ORA-00312: online log 3 thread 1: 'E:\APP\YING_LIU\ORADATA\ORCL\REDO03.LOG'
 
ORA-27041: unable to open file
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_m000_16324.trc:
 
ORA-00313: open failed for members of log group 4 of thread 1
 
ORA-00312: online log 4 thread 1:
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO04.LOG'
 
ORA-27041: unable to open file
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_m000_16324.trc:
 
ORA-00313: open failed for members of log group 5 of thread 1
 
ORA-00312: online log 5 thread 1:
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO05.LOG'
 
ORA-27041: unable to open file
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_m000_16324.trc:
 
ORA-00313: open failed for members of log group 6 of thread 1
 
ORA-00312: online log 6 thread 1:
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO06.LOG'
 
ORA-27041: unable to open file
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
Checker run found 12 new persistent data failures
 
Tue Nov 15 16:07:18 2016
 
==>在2016/11/15 16:54:59执行了不完全恢复，但因为没有开启归档日志，找不到需要的归档日志
 
==>恢复失败
 
Tue Nov 15 16:54:59 2016
 
ALTER DATABASE RECOVERdatabase until time '2011-10-01 00:00:00'
 
Media Recovery Start
 
started logmerger process
 
Parallel Media Recovery started with 8 slaves
 
Tue Nov 15 16:55:00 2016
 
Media Recovery failed with error 19907
 
Slave exiting with ORA-283 exception
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_pr00_560.trc:
 
ORA-00283: recovery session canceled due to errors
 
ORA-19907: recovery time or SCN does not belong to recovered
 
incarnation
 
ORA-283 signalled during: ALTER DATABASE RECOVERdatabase until time '2011-10-01
 
00:00:00'.
 
Tue Nov 15 16:55:11 2016
 
ALTER DATABASE RECOVERdatabase until time '2016-10-01 00:00:00'
 
Media Recovery Start
 
started logmerger process
 
Parallel Media Recovery started with 8 slaves
 
Media Recovery Not Required
 
Tue Nov 15 16:55:11 2016
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_pr00_5260.trc:
 
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: 'E:\APP\YING_LIU\ORADATA\ORCL\SYSTEM01.DBF'
 
Slave exiting with ORA-1547 exception
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_pr00_5260.trc:
 
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: 'E:\APP\YING_LIU\ORADATA\ORCL\SYSTEM01.DBF'
 
ORA-10879 signalled during: ALTER DATABASE RECOVERdatabase until time '2016-10-01
 
00:00:00'...
 
Tue Nov 15 16:55:23 2016
 
alter database open resetlogs
 
ORA-1194 signalled during: alter database open resetlogs...
 
Tue Nov 15 16:55:43 2016
 
alter database clear unarchived logfile group 5
 
ORA-1624 signalled during: alter database clear unarchived logfile
 
group 5...
 
Tue Nov 15 16:55:43 2016
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_m000_932.trc:
 
ORA-00313: open failed for members of log group 5 of thread 1
 
ORA-00312: online log 5 thread 1:
 
'E:\APP\YING_LIU\ORADATA\ORCL\REDO05.LOG'
 
ORA-27041: unable to open file
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
Checker run found 13 new persistent data failures
 
==> 2016/11/15 17:03:07手动执行了控制文件恢复操作，但因为没有对应的归档日志失败(没开归档)
 
==>这个操作直接导致了控制文件与数据文件头SCN不一致，以至于后续启动数据库时都要求恢复控制文
 
==>文件。
 
Tue Nov 15 17:03:07 2016
 
ALTER DATABASE RECOVERdatabase using backup controlfile
 
Media Recovery Start
 
started logmerger process
 
Tue Nov 15 17:03:07 2016
 
WARNING! Recovering data file 1 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 2 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 3 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 4 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 5 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 6 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 7 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 8 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 9 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 10 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 11 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 12 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
WARNING! Recovering data file 13 from a fuzzy file. If not the
 
current file
 
it might be an online backup taken without entering the begin backup
 
command.
 
Parallel Media Recovery started with 8 slaves
 
ORA-279 signalled during: ALTER DATABASE RECOVERdatabase using backup controlfile...
 
Tue Nov 15 17:04:40 2016
 
ALTER DATABASE RECOVERLOGFILE 'E:\app\ying_liu\oradata\ORCL\REDO01.LOG;'
 
Media Recovery Log E:\app\ying_liu\oradata\ORCL\REDO01.LOG;
 
Tue Nov 15 17:04:40 2016
 
Errors with log E:\app\ying_liu\oradata\ORCL\REDO01.LOG;
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_pr00_10108.trc:
 
ORA-00308: cannot open archived log
 
'E:\app\ying_liu\oradata\ORCL\REDO01.LOG;'
 
ORA-27041: unable to open file
 
OSD-04002:无法打开文件
 
O/S-Error: (OS 2)系统找不到指定的文件。
 
ORA-308 signalled during: ALTER DATABASE RECOVERLOGFILE
 
'E:\app\ying_liu\oradata\ORCL\REDO01.LOG;'...
 
Tue Nov 15 17:05:00 2016
 
ALTER DATABASE RECOVERLOGFILE 'E:\app\ying_liu\oradata\ORCL\REDO01.LOG'
 
Media Recovery Log E:\app\ying_liu\oradata\ORCL\REDO01.LOG
 
Tue Nov 15 17:05:00 2016
 
Errors with log E:\app\ying_liu\oradata\ORCL\REDO01.LOG
 
Errors in file
 
e:\app\ying_liu\diag\rdbms\orcl\orcl\trace\orcl_pr00_10108.trc:
 
ORA-00339: archived log does not contain any redo
 
ORA-00334: archived log: 'E:\APP\YING_LIU\ORADATA\ORCL\REDO01.LOG'
 
ORA-339 signalled during: ALTER DATABASE RECOVERLOGFILE 'E:\app\ying_liu\oradata\ORCL\REDO01.LOG'...
 
ALTER DATABASE RECOVER CANCEL
 
Media Recovery Canceled
 
Completed: ALTER DATABASE RECOVER CANCEL
 
总结：
 
1.处理故障前没检查数据库告警日志，做了使用NORESETLOGS创建控制文件的无用功，如果
 
查看了数据库告警日志知道redo
 
log损坏了，就会直接使用RESETLOGS重建控制文件。
 
2.选择解决问题的方案之前，要思考下这么做的目的是什么，是否有更高效的处理方式。比如推高数据库SCN的目的是为了跳过实例恢复时的回滚操作，其实可以直接使用隐藏参数
 
跳过有问题的回滚段，可以节省推高SCN操作的时间，提供工作效率。

 
相关题目与解析
 
Windows下恢复被误删除的文件应使用()。A.我的电脑B.文档C.设置D.回收站
 
在Windows中，恢复被误删除的文件应使用()。A.我的电脑B.文档C.设置D.回收站
 
在MSDOS方式下删除文件后，被删除文件()。A)放入“回收站”B)在“回收站”中找不到C)放入“我的文
 
windowsXP下列恢复被误删除的文件，应使用()A.我的电脑B.文档C.设置D.回收站
 
Windows中显示并可以恢复做了逻辑删除的文件的是()A、资源管理器B、回收站C、网上邻居D、我的文档
 
Windows提供了一个恢复被删除文件的工具，即()。A.我的电脑B.网上邻居C.我的文档D.回收站
 
WINDOWS98把用户删除的硬盘上的文件夹和快捷方式放入()。A．我的电脑B．回收站C．我的
 
下列图标中，()主要用来管理计算机的资源A:收件箱B:我的电脑C:网上邻居D:回收站
 
在“我的电脑”中，删除()中的文件时不把被删除的文件送入回收站，而是直接删除。A.C盘B.D盘C.A盘D.wi
 
下列【】应用程序是Windows2000提供的对文件和文件夹进行管理的程序．A．“我的电脑”B．“回收站”C．“资
 
在Windows中，如果删除了u盘上的文件，则该文件()。A．可以在“我的文档”中找到B．可以恢复C．可以在“
 
●WindowsXP中，被删除的文件默认存放在(25)中，需要时还可以进行恢复。(25)A．我的文档B．C盘Myg
 
“我的电脑”窗口包含用户计算机的所有资源所有驱动器及()图标等。A.网上邻居B.我的文档C.控制
 
下列叙述不正确的是()A.通过“我的电脑“图标可以浏览和使用所有的计算机资源B.“我的电

 
一、SCN内容
 
1、概念：SCN(The System Change Number)
 
system change number (SCN)是一个非常重要的标记，Oracle使用它来标记数据库在过去时间内的状态和轨迹。
 
SCN就是ORACLE 数据库自己的时间，通过它特有的生成机制形成SCN，
 
SCN这个数字是由当时的timestamp转换过来的。每当需要产生一个最新的SCN到redo记录时，系统获取当时的timestamp，将其转换为数字作为SCN。
 
2、分类
 
a:系统检查点scn(system scn)
 
当一个检查点动作完成后，Oracle就把系统检查点的SCN存储到控制文件中。
 
select to_char(checkpoint_change#)system_scn from v$database;
 
针对数据库，只有一个SCN
 
b)数据文件检查点scn(datafile scn)
 
当一个检查点动作完成后，Oracle就把每个数据文件的scn单独存放在控制文件中。
 
select name,to_char(checkpoint_change#) data_scn from v$datafile
 
where rownum<1;
 
针对数据文件，每个数据文件一个。
 
c)启动scn(start scn)
 
Oracle把这个检查点的scn存储在每个数据文件的文件头中，这个值称为启动scn，因为它用于在数据库实例启动时，
 
检查是否需要执行数据库恢复.
 
select name,to_char(checkpoint_change#) start_scn from
 
v$datafile_header where rownum<2;
 
针对数据文件，每个数据文件一个。
 
d)终止scn
 
每个数据文件的终止scn都存储在控制文件中
 
select name,to_char(checkpoint_change#)
 
data_scn,to_char(last_change#) stop_scn from v$datafile;
 
针对数据文件，每个数据文件一个。
 
e)日志文件SCN( Lowest system change number (SCN) in the log)
 
select group#,sequence#,status,first_change# from v$log;
 
select first_change# from v$log
 
---当前日志组中的第一个SCN号。
 
f)当前current scn
 
select to_char(dbms_flashback.get_system_change_number) from
 
dual;---当前SCN号
 
select to_char(current_scn)system_scn from v$database;---当前SCN号
 
select to_char(TIMESTAMP_TO_SCN(SYSDATE)) from dual;
 
SELECT TO_CHAR(SCN_TO_TIMESTAMP(scn)) from
 
dual;
 
备注：SCN实际是和系统时间挂钩的，通过SYSDATE可以自动生成SCN号。
 
3、SCN工作理论
 
SCN有点类似于sequence，Oracle在SGA中增加它。当一个事务修改或者插入数据，Oracle首先写入一个新的SCN到回滚段中log
 
writer进程立刻把提交的记录写入到重做日志中，这条提交的记录将拥有唯一的SCN.事实上，把SCN写入到日志，就意味着一个事务的完成。每当数据库发生checkpoint，Oracle
 
写一个START SCN命令到数据文件头。控制文件维护着每个数据文件的SCN，称为STOP
 
SCN，通常是无穷大，每当实例正常关闭(SHUTDOWN NORMAL or SHUTDOWN
 
IMMEDIATE)，Oracle会复制数据文件头START
 
SCN到控制文件的STOP
 
SCN。如果是正常的重启数据库，是不需要恢复的，因为控制文件和数据文件的SCN是吻合的。反之，突然中断系统就没法同步SCN，SCN不匹配，Oracle就认为需要做恢复
 
二、CHECKPOINT内容
 
1、概念--什么是checkpoint
 
在数据库系统中，写日志和写数据文件是数据库中IO消耗最大的两种操作，在这两种操作中写数据文件属于分散写，写日志文件是顺序写，因此为了保证数据库的性能，通常数据库都是保证在提交(commit)完成之前要先保证日志都被写入到日志文件中，而脏数据块着保存在数据缓存(buffer
 
cache)中再不定期的分批写入到数据文件中。也就是说日志写入和提交操作是同步的，而数据写入和提交操作是不同步的。这样就存在一个问题，当一个数据库崩溃的时候并不能保证缓存里面的脏数据全部写入到数据文件中，这样在实例启动的时候就要使用日志文件进行恢复操作，将数据库恢复到崩溃之前的状态，保证数据的一致性。检查点是这个过程中的重要机制，通过它来确定，恢复时哪些重做日志应该被扫描并应用于恢复。
 
一般所说的checkpoint是一个数据库事件(event)，checkpoint事件由checkpoint进程(LGWR/CKPT进程)发出，当checkpoint事件发生时DBWn会将脏块写入到磁盘中，同时数据文件和控制文件的文件头也会被更新以记录checkpoint信息。
 
2、checkpoint作用
 
保证数据库的一致性，这是指将脏数据写入到硬盘，保证内存和硬盘上的数据是一样的；
 
缩短实例恢复的时间，实例恢复要把实例异常关闭前没有写出到硬盘的脏数据通过日志进行恢复。如果脏块过多，实例恢复的时间也会很长，检查点的发生可以减少脏块的数量，从而提高实例恢复的时间。
 
通俗的说checkpoint就像word的自动保存一样。
 
3、分类
 
完全检查点(Normal checkpoint)
 
增量检查点(Incremental checkpoint)
 
4、相关概念
 
RBA(Redo Byte Address), Low RBA(LRBA), High RBA(HRBA)
 
RBA就是重做日志块(redo log
 
block)的地址，相当与数据文件中的ROWID，通过这个地址来定位重做日志块。RBA由三个部分组成：
 
日志文件序列号(4字节)
 
日志文件块编号(4字节)
 
重做日志记录在日志块中的起始偏移字节数(2字节)
 
通常使用RBA的形式有：
 
LRBA
 
数据缓存(buffer cache)中一个脏块第一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为LRBA。
 
HRBA
 
数据缓存(buffer
 
cache)中一个脏块最近一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为HRBA。
 
checkpoint RBA
 
当一个checkpoint事件发生的时候，checkpoint进程会记录下当时所写的重做日志块的地址即RBA，此时记录的RBA被称为checkpoint
 
RBA。从上一个checkpoint RBA到当前的checkpoint RBA之间的日志所保护的buffer
 
cache中的脏块接下来将会被写入到数据文件当中去。 topBuffer checkpoint Queues (BCQ)
 
Oracle将所有在数据缓存中被修改的脏块按照LRBA顺序的组成一个checkpoint队列，这个队列主要记录了buffer
 
cache第一次发生变化的时间顺序，然后有DBWn进程根据checkpoint队列顺序将脏块写入到数据文件中，这样保证了先发生变更的buffer能先被写入到数据文件中。BCQ的引入是为了支持增量checkpoint的。
 
topActive checkpoint Queue (ACQ)
 
ACQ中包含了所有活动的checkpoint请求。每次有新checkpoint请求是都会在ACQ中增加一条记录，ACQ记录中包含了相应的checkpoint
 
RBA。checkpoint完成以后相应的记录将被移出队列。
 
5、完全检查点 (normal checkpoint)完全检查点工作过程
 
一个checkpoint操作可以分成三个不同的阶段：
 
第一阶段，checkpoint进程开始一个checkpoint事件，并记录下checkpoint
 
RBA，这个通常是当前的RBA。
 
第二阶段，checkpoint进程通知DBWn进程将所有checkpoint RBA之前的buffer
 
cache里面的脏块写入磁盘。
 
第三阶段，checkpoint进程将checkpoint信息(SCN)写入/更新数据文件和控制文件中。
 
更新SCN的操作由CKPT进程完成，在Oracle
 
8.0之后CKPT进程默认是被启用的，如果CKPT进程没有启用的话那相应的操作将由LGWR进程完成。
 
什么时候发生normal checkpoint
 
下面这些操作将会触发checkpoint事件：
 
日志切换，通过ALTER SYSTEM SWITCH LOGFILE。
 
DBA发出checkpoint命令，通过ALTER SYSTEM checkpoint。
 
对数据文件进行热备时，针对该数据文件的checkpoint也会进行，ALTER TABLESPACE TS_NAME BEGIN
 
BACKUP/END BACKUP。
 
当运行ALTER TABLESPACE/DATAFILE READ ONLY的时候。
 
SHUTDOWN命令发出时。
 
特别注意：
 
日志切换会导致checkpoint事件发生，但是checkpoint发生却不会导致日志切换。
 
日志切换触发的是normal checkpoint，而不是大家所说的增量checkpoint，只不过log switch
 
checkpoint的优先级非常低，当一个log switch
 
checkpoint发生的时候它并不会立即的通知DBWn进程去写数据文件，但是当有其它原因导致checkpoint或者是写入数据文件的RBA超过log
 
switch checkpoint的checkpoint RBA的时候，这次的log switch
 
checkpoint将会被标记成完成状态，同时更新控制文件和数据文件头。我们随后可以做个实验验证这个说法。
 
checkpoint和SCN有什么关系？
 
在Oracle中SCN相当于它的时钟，在现实生活中我们用时钟来记录和衡量我们的时间，而Oracle就是用SCN来记录和衡量整个Oracle系统的更改。
 
Oracle中checkpoint是在一个特定的“时间点”发生的，衡量这个“时间点”用的就是SCN，因此当一个checkpoint发生时SCN会被写入文件头中以记录这个checkpoint。
 
6、增量checkpoint
 
增量checkpoint工作过程
 
因为每次完全的checkpoint都需要把buffer
 
cache所有的脏块都写入到数据文件中，这样就是产生一个很大的IO消耗，频繁的完全checkpoint操作很对系统的性能有很大的影响，为此Oracle引入的增量checkpoint的概念，buffer
 
cache中的脏块将会按照BCQ队列的顺序持续不断的被写入到磁盘当中，同时CKPT进程将会每3秒中检查DBWn的写入进度并将相应的RBA信息记录到控制文件中。
 
有了增量checkpoint之后在进行实例恢复的时候就不需要再从崩溃前的那个完全checkpoint开始应用重做日志了，只需要从控制文件中记录的RBA开始进行恢复操作，这样能节省恢复的时间。
 
发生增量checkpoint的先决条件
 
恢复需求设定 (FAST_START_IO_TARGET/FAST_START_MTTR_TARGET)
 
LOG_checkpoint_INTERVAL参数值
 
LOG_checkpoint_TIMEOUT参数值
 
最小的日志文件大小
 
buffer cache中的脏块的数量
 
增量checkpoint的特点
 
增量checkpoint是一个持续活动的checkpoint。
 
没有checkpoint RBA，因为这个checkpoint是一直都在进行的，所以不存在normal
 
checkpoint里面涉及的checkpoint RBA的概念。
 
checkpoint advanced in memory only
 
增量checkpoint所完成的RBA信息被记录在控制文件中。
 
增量checkpoint可以减少实例恢复时间。
 

 
一． RMAN 还原与恢复基础
 
在RMAN 用于中，还原与恢复是两个不同的概念。
 
还原(restore)：指访问先前生成的备份，从中得到一个或多个对象，然后在磁盘上的某个位置还原这些对象。
 
恢复(recover)：是一个数据库与给定时间点相一致以保证能够打开这个数据库的实际进程，该进程通常是通过应用重做(包括联机重做日志和归档的重做日志)来完成的。
 
数据库中的数据状态对数据库是非常重要的，在数据库启动时要求数据与给定的时间状态一致。 如果数据库是一致的，就可以打开这个数据库，如果不一致，就不能打开。 通过使用回滚段，就可以在启动和运行数据库时保持这种一致性。 正常关闭数据库时，数据文件会再一次一致。
 
Oracle 严格要求数据的一致性。 当我们在恢复数据文件后重新启动数据库时，Oracle 会检测这些数据文件是否状态不一致。 Oracle 会跟踪每个数据库数据文件头中的当前SCN和控制文件中的当前SCN。 打开数据库时，Oracle 要经历3个阶段： 未加载，加载和打开。 数据库启动进入打开阶段时，Oracle 会开始尝试打开这个数据库。 在尝试打开数据库的时候，Oracle 检测控制文件中的SCN以及每个数据文件中的SCN，如果这些SCN 不匹配，Oracle 就会知道数据库存在某些错误并且处于不一致的状态。
 
如果发现数据库是不一致的。 Oracle 就需要判断是否能够基于联机重做日志来恢复这个数据库，或者是否需要归档的重做日志来完成恢复操作。 如果Oracle 能够使用联机重做日志来执行恢复操作，它就会执行灾难恢复(或者在RAC 环境中执行实例恢复操作)。 如果Oracle 不能使用联机重做来确保数据库的一致性，它就会停止启动进程，通知报告需要执行介质恢复操作。
 
二． RMAN 还原与恢复前的操作
 
启动数据库恢复时，我们必须先恢复服务器参数文件，然后恢复控制文件。
 
补充知识： 先对控制文件和spfile的备份的知识做下回顾：
 
当我们修改为自动备份后，在每次备份之后都会自动备份控制文件和初始化pfile.
 
RMAN> show all;
 
CONFIGURE CONTROLFILE AUTOBACKUP ON; -- 该参数默认是关闭的
 
RMAN> backup database;
 
......
 
启动 Control File and SPFILE Autobackup 于 25-6月 -10
 
段 handle=D:/APP/ADMINISTRATOR/FLASH_RECOVERY_AREA/ORCL/AUTOBACKUP/2010_06_25/O1
 
_MF_S_722604317_6288DYQF_.BKP comment=NONE
 
完成 Control File and SPFILE Autobackup 于 25-6月 -10
 
配置控制文件和参数文件的自动备份时的一些规则：
 
(1) 在RUN 程序块之外执行每个RMAN的backup 或者 copy 命令时，都会自动备份控制文件和参数文件。
 
(2) 使用使用了RUN 程序块，而且该程序块的最后一个命令不是backup 或者copy，在RUN 程序块结尾处会备份控制文件和参数文件。
 
除了上面2种自动控制文件备份类型，我们还可以配置另一种特殊的控制文件备份类型。该类型发生在数据库变化时，这些变化包括添加新的表空间，添加数据文件，添加联机重做日志等。 这些自动备份类型只在磁盘上发生，使用configure controlfile autobackup命令的特殊选项可以简化备份。如：
 
Configure controlfile autobackup format for device type disk to 'd:/backup/sid_%F';
 
使用了该选项，RDBMS 会在数据结构的变化控制文件产生影响时自动备份控制文件。强调一点，只支持磁盘。
 
手动的备份控制文件
 
Alter database backup controlfile to 'd:/backup/orcl_backup.ctl';
 
手工备份spfile：
 
RMAN> backup spfile ;
 
启动 Control File and SPFILE Autobackup 于 26-6月 -10
 
段 handle=D:/APP/ADMINISTRATOR/FLASH_RECOVERY_AREA/ORCL/AUTOBACKUP/2010_06_26/O1
 
_MF_S_722706435_62CD44SN_.BKP comment=NONE
 
完成 Control File and SPFILE Autobackup 于 26-6月 -10
 
三、还原服务器参数文件
 
1、使用RMAN(不使用FRA)从自动备份中恢复服务器参数文件
 
ORACLE 会默认地在$ORACLE_HOME/dbs 或者 $ORACLE_HOME/DATABASE 目录中创建服务器参数文件与控制文件。
 
还原服务器参数文件的一般过程是先设置ORACLE_SID 和 登陆 RMAN， 然后设置DBID, 使RMAN知道需要查找哪一个数据库的服务器参数文件，还必须在这个操作的同时启动数据库实例。
 
启动数据库实例后，如果使用默认的位置来存储控制文件的自动备份，就可以简单的执行：Restore spfile from autobackup， 这样RMAN 就可以查找包含最新服务器参数备份的控制文件备份集。 一旦恢复了服务器参数文件，就必须关闭重启数据库实例。如果使用的是非默认位置，就需要分配一个指向该位置的通道，然后在使用相同的方法来还原服务器参数文件。
 
执行 restore spfile from autobackup 命令时，Oracle 会在默认位置中(或者在使用allocate channel 命令定义的为位置中)查找自动的控制文件备份集。 RMAN 创建控制文件自动备份片时，会使用默认的命名约定: C-DBID-DATE-序列号。 如：C-1247395743-2010627-00。 注意的是， 这种命名规则不适用于FRA。
 
需要注意的是，如果没有使用恢复目录(并且没有使用控制文件，这是可能的)，Oracle 就不知道最新控制文件备份片的名称，因此Oracle 会基于这些备份集的默认命名标准来构造控制文件备份片的名称。 Oracle 会遍历整个目录，向后查找数据库的控制文件备份集。 在默认情况下，Oracle 会查找一个在过去10天内创建的控制文件备份集。 如果Oracle 美欧查找到指定时间周期内创建的控制文件备份集，就会产生一个错误。 如果Oracle 发现一个有效的控制文件备份集，就会为用户还原服务器参数文件。
 
使用restore 命令的maxseq 和 maxdays 参数可以修改RMAN 向后查找控制文件自动备份的时间周期。
 
使用默认设置的示例：
 
set oracle_sid=orcl
 
rman target sys/pwd
 
set dbid=1247395743
 
startup nomount;
 
restore spfile from autobackup;
 
shutdown immediate;
 
不使用默认设置的示例:
 
set oracle_sid=orcl
 
rman target sys/pwd
 
set dbid=1247395743
 
startup nomount;
 
run
 
{
 
set controlfile autobackup format for device type disk to 'f:/backup/%f';
 
allocate channel c1 device type disk;
 
restore spfile from autobackup;
 
}
 
shutdown immediate;
 
使用maxseq 和 maxdays 参数在超过默认天数(10天)的时间周期内向后查找控制文件备份集：
 
set oracle_sid=orcl
 
rman target sys/pwd
 
set dbid=1247395743
 
startup nomount;
 
run
 
{
 
set controlfile autobackup format for device type disk to 'f:/backup/%f';
 
allocate channel c1 device type disk;
 
restore spfile from autobackup maxseq 200 maxdays 1000;
 
}
 
shutdown immediate;
 
将参数文件还原到不同的位置和文件中的示例(假定数据库正在启动和运行)：
 
set oracle_sid=orcl
 
rman target sys/pwd
 
set dbid=1247395743
 
startup nomount;
 
restore spfile to 'f:/backup/spfile.restore' from autobackup;
 
shutdown immediate;
 
2、使用RMAN 和 FRA 从自动备份中恢复服务器参数文件
 
使用FRA 恢复参数文件比不使用FRA 简单。 首先，我们不需要担心DBID 没有意义，也不用操心分配通道的工作，这就节省了一定的时间。 恢复服务器参数文件时，我们只需要正确配置临时参数文件(确保适当的设置FRA目标目录)，启动ORACLE 实例，并且执行restore spfile 命令。
 
set oracle_sid=orcl
 
rman target sys/pwd
 
startup nomount;
 
restore spfile from autobackup;
 
shutdown immediate;
 
3、从特定的备份集中恢复服务器参数文件
 
在Oracle 10g中， restore 命令包含了一个from backup子句， 使用该子句可以指示包含服务器参数文件的备份的备份集片。 因此，只需要知道该备份集片的名称和它的位置，就可以还原服务器参数文件。 在某些情况下，查找包含服务器参数文件备份的备份集片可能存在一些困难，但一旦找到了该备份集片，还原工作就会非常简单，当然，最好还原最新的控制文件备份。
 
为了还原服务器参数文件，首先要启动数据库实例并标识包含服务器参数文件备份的备份集片(或者进行猜测)。 接着启动RMAN，然后设置数据库饿DBID。 一旦设置了DBID，就需要分配通道给要还原的设备。 分配通道后，执行restore spfile 命令，在命令的末尾传入备份集片的名称。 于是RMAN 将服务器参数还原到正确的位置。
 
set oracle_sid=orcl
 
rman target sys/pwd
 
set dbid=1247395743
 
startup nomount;
 
run
 
{
 
allocate channel c1 device type disk;
 
restore spfile from 'f:/backup/c-1247395743-2010627-00';
 
}
 
shutdown immediate;
 
4、使用恢复目录恢复服务器参数文件
 
如果使用了恢复目录，在启动(未加载)ORACLE 实例后简单执行restore spfile 命令就可以还原最新的服务器参数文件。 RMAN 会使用恢复目录找出最新的控制文件备份，并析取这个备份以供用户使用。
 
set oracle_sid=orcl
 
rman target sys/pwd catalog user/pwd@sid
 
startup nomount;
 
restore spfile from autobackup;
 
shutdown immediate;
 
5、使用联机操作的数据库还原备份的服务器参数文件
 
不管是否使用控制文件或恢复目录，在数据库启动时从数据库备份中析取服务器参数文件的副本是非常容易的。 我们应当注意到这个操作会生成一个文本参数文件，而不是生成一个服务器参数文件。 因此如果要将这个文本参数文件用作服务器参数文件，就必须转换该文件。
 
如果不是使用恢复目录并且控制文件的自动备份已经启动，只需要执行下面的命令：
 
RMAN>RESTORE SPFILE TO PFILE 'D:/BAKCUP/ORCL.ORA' FROM AUTOBACKUP;
 
对于任何自动备份的还原操作来说，如果不提供maxseq 和maxdays 参数值，RMAN 只需要查找过去7天内生成的控制文件的自动备份片。
 
如果没有使用恢复目录与控制文件自动备份，或者是在使用恢复目录，就可以执行：
 
RMAN>RESTORE SPFILE TO PFILE 'D:/BACKUP/ORCL.ORA';
 
这种情况下，Oracle 会使用数据库控制文件找到最新的备份集，并从这个备份集中还原服务器参数文件。