在公司里面想到做一个测试，当某个作测试用的归档模式数据库在无备份的前提下如何打开数据库，如果是把全库推到该丢失的归档之前，可以使用flashback或者在有备份的前提下做(本次不作介绍)，如果只是将该丢失的datafile恢复到该丢失的归档之前，可以通过调用隐含参数来实现，下面演示通过调用隐含参数来恢复数据库的例子：

（前提：归档模式）

1.在测试库上面创建一个新的表空间，用于测试丢失datafile；
SQL> create tablespace test1 
  2  datafile '/u01/app/oracle/oradata/PROD/test1.dbf' size 10m;

SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/PROD/system01.dbf
/u01/app/oracle/oradata/PROD/sysaux01.dbf
/u01/app/oracle/oradata/PROD/undotbs01.dbf
/u01/app/oracle/oradata/PROD/users01.dbf
/u01/app/oracle/oradata/PROD/example01.dbf
/u01/app/oracle/oradata/PROD/treasury.dbf
/u01/app/oracle/oradata/PROD/test1.dbf

7 rows selected.

2.在该表空间上创建一张表，插入几行数据；
SQL> create table t1 (id int) tablespace test1;

Table created.

SQL> insert into t1 values (1);

1 row created

...commit；


SQL> select * from t1;

        ID
----------
         1
         2
         3
         4

3.将其归档
SQL> alter system switch logfile;

System altered.
...

4.操作系统上手动删除22号归档文件与datafile
[oracle@odd arch]$ rm 1_22_871143053.arc
[oracle@odd arch]$ rm test1.dbf

5.重启数据库
SQL> startup force;
ORACLE instance started.


Total System Global Area  485441536 bytes
Fixed Size                  1337380 bytes
Variable Size             327157724 bytes
Database Buffers          150994944 bytes
Redo Buffers                5951488 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 7 - see DBWR trace file
ORA-01110: data file 7: '/u01/app/oracle/oradata/PROD/test1.dbf'
该datafile已丢失，现在按正常步骤可以将其datafile利用归档进行恢复


6.利用归档跟在线日志恢复datafile
SQL> recover datafile 7;                    
Specify log: {=suggested | filename | AUTO | CANCEL}

ORA-00279: change 1003755 generated at 05/19/2015 15:45:17 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/arch/1_19_871143053.dbf
ORA-00280: change 1003755 for thread 1 is in sequence #19

Specify log: {=suggested | filename | AUTO | CANCEL}

ORA-00279: change 1003796 generated at 05/19/2015 15:46:21 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/arch/1_20_871143053.dbf
ORA-00280: change 1003796 for thread 1 is in sequence #20

Specify log: {=suggested | filename | AUTO | CANCEL}

ORA-00279: change 1003800 generated at 05/19/2015 15:46:24 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/arch/1_21_871143053.dbf
ORA-00280: change 1003800 for thread 1 is in sequence #21

Specify log: {=suggested | filename | AUTO | CANCEL}

ORA-00279: change 1003804 generated at 05/19/2015 15:46:27 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/arch/1_22_871143053.dbf
ORA-00280: change 1003804 for thread 1 is in sequence #22

Specify log: {=suggested | filename | AUTO | CANCEL}

ORA-00308: cannot open archived log '/u01/app/oracle/arch/1_22_871143053.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
发现22号归档不存在，此时我们可以通过调用隐含参数_allow_resetlogs_corruption=true 去强制resetlogs通过一致性检查
此时通过sqlplus直接设置隐含参数可能出现以下情况
SQL> alter system set _allow_resetlogs_corruption=true scope=spfile;
alter system set _allow_resetlogs_corruption=true scope=spfile
                 *
ERROR at line 1:
ORA-00911: invalid character
所以我们可以直接将其隐含参数直接写入到pfile中

7.在pfile当中写入
*._allow_resetlogs_corruption=true
设置该参数，有可能引发ORA-00600错误

8.利用pfile生成spfile，启动数据库，以下为启动数据库部分警告日志信息
System parameters with non-default values:
  processes                = 150
  memory_target            = 464M
  control_files            = "/u01/app/oracle/oradata/PROD/control01.ctl"
  control_files            = "/u01/app/oracle/flash_recovery_area/PROD/control02.ctl"
  db_block_size            = 8192
  compatible               = "11.2.0.0.0"
  log_archive_dest_1       = "location=/u01/app/oracle/arch"
  db_recovery_file_dest    = "/u01/app/oracle/flash_recovery_area"
  db_recovery_file_dest_size= 3852M
  _allow_resetlogs_corruption= TRUE
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=PRODXDB)"
  local_listener           = ""
  audit_file_dest          = "/u01/app/oracle/admin/PROD/adump"
  audit_trail              = "DB"
  db_name                  = "PROD"
  open_cursors             = 300
  diagnostic_dest          = "/u01/app/oracle"
Tue May 19 16:44:58 2015
PMON started with pid=2, OS id=8200 
Tue May 19 16:44:58 2015
VKTM started with pid=3, OS id=8202 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Tue May 19 16:44:58 2015
GEN0 started with pid=4, OS id=8206 
Tue May 19 16:44:58 2015
DIAG started with pid=5, OS id=8208 
Tue May 19 16:44:58 2015
DBRM started with pid=6, OS id=8210 
Tue May 19 16:44:58 2015
PSP0 started with pid=7, OS id=8212 
Tue May 19 16:44:58 2015
DIA0 started with pid=8, OS id=8214 
Tue May 19 16:44:58 2015
MMAN started with pid=9, OS id=8216 
Tue May 19 16:44:58 2015
DBW0 started with pid=10, OS id=8218 
Tue May 19 16:44:58 2015
LGWR started with pid=11, OS id=8220 
Tue May 19 16:44:58 2015
CKPT started with pid=12, OS id=8222 
Tue May 19 16:44:58 2015
SMON started with pid=13, OS id=8224 
Tue May 19 16:44:58 2015
RECO started with pid=14, OS id=8226 
Tue May 19 16:44:58 2015
MMON started with pid=15, OS id=8228 
Tue May 19 16:44:58 2015
MMNL started with pid=16, OS id=8230 
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01/app/oracle
Tue May 19 16:44:58 2015
ALTER DATABASE   MOUNT
Tue May 19 16:45:02 2015
Sweep [inc][18153]: completed
Sweep [inc2][18153]: completed
Successful mount of redo thread 1, with mount id 291985674
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Tue May 19 16:45:03 2015
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
 read 0 KB redo, 0 data blocks need recovery
Started redo application at
 Thread 1: logseq 2, block 2, scn 1023814
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0: /u01/app/oracle/oradata/PROD/redo02.log
Completed redo application of 0.00MB
Completed crash recovery at
 Thread 1: logseq 2, block 3, scn 1043816
 0 data blocks read, 0 data blocks written, 0 redo k-bytes read
LGWR: STARTING ARCH PROCESSES
Tue May 19 16:45:03 2015
ARC0 started with pid=20, OS id=8276 
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thread 1 advanced to log sequence 3 (thread open)
Tue May 19 16:45:04 2015
ARC1 started with pid=21, OS id=8278 
Thread 1 opened at log sequence 3
  Current log# 3 seq# 3 mem# 0: /u01/app/oracle/oradata/PROD/redo03.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Tue May 19 16:45:04 2015
ARC2 started with pid=22, OS id=8280 
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Tue May 19 16:45:04 2015
ARC3 started with pid=23, OS id=8282 
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is WE8MSWIN1252
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
LOGSTDBY: Validating controlfile with logical metadata
Archived Log entry 19 added for thread 1 sequence 1 ID 0x11675682 dest 1:
Tue May 19 16:45:04 2015
QMNC started with pid=24, OS id=8284 
Archived Log entry 20 added for thread 1 sequence 2 ID 0x11675682 dest 1:
LOGSTDBY: Validation complete
Completed: ALTER DATABASE OPEN
Tue May 19 16:45:05 2015
db_recovery_file_dest_size of 3852 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Starting background process CJQ0
Tue May 19 16:45:05 2015
CJQ0 started with pid=28, OS id=8298 
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Spfile /u01/app/oracle/product/11.2.0/db_1/dbs/spfilePROD.ora is in old pre-11 format and compatible >= 11.0.0; converting to new H.A.R.D. compliant format.
Tue May 19 16:47:33 2015

9.查看表数据
SQL> select * from t1;

        ID
----------
         1
         2
         3
         4

通过这个方法启动数据库应该导出重要的数据，
之后并且记得在pfile中删除该隐含参数，之后生成spfile，再重启数据库，必要时需要重建数据库。