mount阶段并不会做数据文件的存在性判断

看到好些资料描述说，数据库在mount阶段会做数据文件的存在性判断，意思就是如果数据文件不存在，则要抛出错误。根据我的在11g上的试验，不会！

先关闭数据库：

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> 

在将除控制文件之外的其他文件删除：

[oracle@db1 denver]$ pwd

/u01/oradata/denver

[oracle@db1 denver]$ ll

total 9840

-rw-r-----. 1 oracle oinstall 10076160 Oct  5 10:52 control01.ctl

[oracle@db1 denver]$ 

再启动数据库到mount阶段，并观察alert日志：

SQL> startup mount;

ORACLE instance started.

Total System Global Area  835104768 bytes

Fixed Size                  2217952 bytes

Variable Size             595593248 bytes

Database Buffers          230686720 bytes

Redo Buffers                6606848 bytes

Database mounted.

SQL> 

Mon Oct 05 10:55:26 2015

Starting ORACLE instance (normal)

Mon Oct 05 10:56:17 2015

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Picked latch-free SCN scheme 3

Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST

Autotune of undo retention is turned on. 

IMODE=BR

ILAT =27

LICENSE_MAX_USERS = 0

SYS auditing is disabled

Starting up:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options.

Using parameter settings in server-side spfile /u01/app/oracle/dbs/spfiledenver.ora

System parameters with non-default values:

  processes                = 150

  memory_target            = 800M

  control_files            = "/u01/oradata/denver/control01.ctl"

  control_files            = "/u01/flash_recovery_area/denver/control02.ctl"

  db_block_size            = 8192

  compatible               = "11.2.0.0.0"

  db_recovery_file_dest    = "/u01/flash_recovery_area"

  db_recovery_file_dest_size= 6882M

  undo_tablespace          = "UNDOTBS1"

  remote_login_passwordfile= "EXCLUSIVE"

  db_domain                = ""

  dispatchers              = "(PROTOCOL=TCP) (SERVICE=denverXDB)"

  local_listener           = "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=1521))))"

  job_queue_processes      = 1000

  audit_file_dest          = "/u01/admin/denver/adump"

  audit_trail              = "DB"

  db_name                  = "denver"

  open_cursors             = 300

  diagnostic_dest          = "/u01"

Mon Oct 05 10:56:19 2015

PMON started with pid=2, OS id=2962 

Mon Oct 05 10:56:19 2015

VKTM started with pid=3, OS id=2964 at elevated priority

VKTM running at (10)millisec precision with DBRM quantum (100)ms

Mon Oct 05 10:56:19 2015

GEN0 started with pid=4, OS id=2968 

Mon Oct 05 10:56:19 2015

DIAG started with pid=5, OS id=2970 

Mon Oct 05 10:56:19 2015

DBRM started with pid=6, OS id=2972 

Mon Oct 05 10:56:19 2015

PSP0 started with pid=7, OS id=2974 

Mon Oct 05 10:56:19 2015

DIA0 started with pid=8, OS id=2976 

Mon Oct 05 10:56:20 2015

MMAN started with pid=9, OS id=2978 

Mon Oct 05 10:56:20 2015

DBW0 started with pid=10, OS id=2980 

Mon Oct 05 10:56:20 2015

LGWR started with pid=11, OS id=2982 

Mon Oct 05 10:56:20 2015

CKPT started with pid=12, OS id=2984 

Mon Oct 05 10:56:20 2015

SMON started with pid=13, OS id=2986 

Mon Oct 05 10:56:20 2015

RECO started with pid=14, OS id=2988 

Mon Oct 05 10:56:20 2015

MMON started with pid=15, OS id=2990 

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

Mon Oct 05 10:56:21 2015

MMNL started with pid=16, OS id=2992 

starting up 1 shared server(s) ...

ORACLE_BASE from environment = /u01

Mon Oct 05 10:56:22 2015

ALTER DATABASE   MOUNT

Mon Oct 05 10:56:32 2015

Successful mount of redo thread 1, with mount id 4181190748

Database mounted in Exclusive Mode

Lost write protection disabled

Mon Oct 05 10:56:34 2015

Completed: ALTER DATABASE   MOUNT

好明显的结果，数据库并没有做数据文件存在性检查。难道有什么参数控制吗？