看到好些资料描述说,数据库在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
好明显的结果,数据库并没有做数据文件存在性检查。难道有什么参数控制吗?