相较INSTANCE_NAME参数来说，对于Oracle数据库更为重要的一个参数是DB_NAME.DB_NAME代表了实例即将挂接的数据库名称， 关系到具体的物理文件。通常缺省的数据库instance_name和db_name可以设置相同（在RAC环境下，由于多个实例对应一个数据库，所以 instance_name和db_name不同）。

在创建数据库的过程中，下图是用于定义数据库名称（db_name）和影响INSTANCE_NAME的SID：

Oracle文档中对于db_name的定义如下：DB_NAME用来定义数据库名称，必须是一个不超过8个字符的文本串，在数据库创建过程 中，db_name被记录在数据文件，日志文件和控制文件中。如果数据库实例启动过程中参数文件中的db_name和控制文件中的数据库名称不一致，则数 据库不能启动。

此外常见的几个结论有：

1. 一个实例可以mount并打开任何数据库，但是同一时间一个实例只能打开一个数据库

2. 一个数据库可以被一个或多个实例所mount并打开（在OPS/RAC环境下，一个数据库可以被多个实例所打开）。

DB_NAME的另外一个作用是在监听器动态注册时作为缺省服务名注册，以下是Oracle10g的动态注册监听示范：

Services Summary...
Service "julia" has 1 instance(s).
Instance "eygle", status READY, has 1 handler(s) for this service...

通过下面的测试来看一下DB_NAME与数据库的关系。首先initeygle.ora文件代表了一个数据库实例：

[oracle@jumper oracle]$ cd $ORACLE_HOME/dbs
[oracle@jumper dbs]$ grep name initeygle.ora
*.db_name='eygle'
*.instance_name='eygle'

这个实例以及当前数据库的相关参数如下：

SQL> show parameter db_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_name string eygle
SQL> show parameter instance_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
instance_name string eygle

现在创建另外一个实例，通过复制创建一个pfile文件为名为julia这个新的实例使用：

[oracle@jumper oracle]$ cd $ORACLE_HOME/dbs
[oracle@jumper dbs]$ cp initeygle.ora initjulia.ora
[oracle@jumper dbs]$ ll init*
-rw-r--r-- 1 oracle dba 982 Jul 25 14:03 initeygle.ora
-rw-r--r-- 1 oracle dba 982 Jul 25 14:04 initjulia.ora

修改这个文件，更改instance_name参数，设置instance_name = julia，修改后的参数设置如下所示:

[oracle@jumper dbs]$ grep name initjulia.ora
*.db_name='eygle'
*.instance_name='julia'

现在来启动这个实例名称为julia的instance：

[oracle@jumper dbs]$ export ORACLE_SID=julia
[oracle@jumper dbs]$ sqlplus "/ as sysdba"
SQL> startup mount;
ORACLE instance started.

Total System Global Area 139531744 bytes
Fixed Size 452064 bytes
Variable Size 121634816 bytes
Database Buffers 16777216 bytes
Redo Buffers 667648 bytes
ORA-01102: cannot mount database in EXCLUSIVE mode

注意，当试图加载数据库时出现错误，因为当前数据库被另外一个实例（instance）加载。在非并行模式（Ops/RAC）下，一个数据库同时只能被一个实例加载。

此时已经启动了两个数据库实例，从后台进程可以看出：

[oracle@jumper dbs]$ ps -ef|grep dbw
oracle 27323 1 0 Jul14 ? 00:00:00 ora_dbw0_eygle
oracle 15447 1 0 14:04 ? 00:00:00 ora_dbw0_julia
oracle 25030 25000 0 18:38 pts/2 00:00:00 grep dbw

关闭eygle这个数据库实例:

[oracle@jumper dbs]$ export ORACLE_SID=eygle
[oracle@jumper dbs]$ sqlplus "/ as sysdba"
SQL> shutdown immediate;

然后就可以通过实例julia加载并打开db_name=eygle的数据库了，这也就是前面所说的，一个数据库可以被任何一个实例挂接打开（当然是有条件限制的）：

[oracle@jumper dbs]$ export ORACLE_SID=julia
[oracle@jumper dbs]$ sqlplus "/ as sysdba"
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-01990: error opening password file '/opt/oracle/product/9.2.0/dbs/orapw'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
SQL> alter database open;
Database altered.
SQL> select name from v$datafile;
NAME
----------------------------------------------------------------------------
/opt/oracle/oradata/eygle/system01.dbf
/opt/oracle/oradata/eygle/undotbs01.dbf
/opt/oracle/oradata/eygle/users01.dbf
/opt/oracle/oradata/eygle/eygle01.dbf
SQL> show parameter instance_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
instance_name string julia
SQL> show parameter db_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_name string eygle

进一步的，再来研究一下如果参数文件中的db_name和控制文件中的db_name不一致会出现什么错误。

修改参数文件中的db_name参数：

[oracle@jumper dbs]$ grep name initjulia.ora
*.db_name='julia'
*.instance_name='julia'

在nomount环节不存在任何问题，而在mount阶段，数据库会对参数文件和控制文件进行比较，如果两者记录的db_name不一致，则数据库无法启动，错误提示指定的数据库名称和控制文件中记录的名称不符：

SQL> startup nomount;
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-01103: database name 'EYGLE' in controlfile is not 'JULIA'

在使用RMAN（Recovery Manager）时存在更为特殊的情况，Oracle允许在不存在参数文件的情况下启动一个实例，数据库的db_name会被缺省的命名为DUMMY，这是最为极端的情况，在某些恢复过程中，这个功能可以帮助我们减少很多麻烦：

[oracle@jumper dbs]$ rman target /
Recovery Manager: Release 9.2.0.4.0 - Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
connected to target database (not started)
RMAN> startup nomount;
startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/9.2.0/dbs/initconner.ora'
trying to start the Oracle instance without parameter files ...
Oracle instance started
Total System Global Area 97588504 bytes
Fixed Size 451864 bytes
Variable Size 46137344 bytes
Database Buffers 50331648 bytes
Redo Buffers 667648 bytes

RMAN> host ;
[oracle@jumper dbs]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Tue Mar 12 14:17:07 2006
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
SQL> show parameter db_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_name string DUMMY

此时警告日志文件中会记录如下信息：

Starting up ORACLE RDBMS Version: 9.2.0.4.0.
System parameters with non-default values:
remote_login_passwordfile= EXCLUSIVE
db_name = DUMMY
PMON started with pid=2
DBW0 started with pid=3
.....

总结一下，数据库的Nomount过程实质上就是在创建实例，这个步骤只和参数文件相关，在完成实例的创建之后，Oracle就可以逐步导航，完成数据库的加载，打开等工作。

1.1.1.9 Nomount案例两则

在创建数据库时，如果在这一步骤就出现问题，那么通常可能是系统配置（如内核参数等）存在问题，你需要检查是否分配了足够的系统资源等。

以下是一个启动到nomount状态可能会遇到的常见错误：

$ export ORACLE_SID=julia
$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Wed Feb 28 09:55:24 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to an idle instance.

SQL> startup nomount;
ORA-00600: internal error code, arguments: [OSDEP_INTERNAL], [], [], [], [], [], [], []
ORA-27302: failure occurred at: skgpwreset1
ORA-27303: additional information: invalid shared ctx
ORA-27146: post/wait initialization failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpsemsper

（注意：ORA-00600是Oracle内部错误的一个集合，其具体含义要看后面的参数提示，数据库出现ORA-00600错误应当引起DBA的充分重视，很多600错误可能会导致数据损失。）

在Nomount状态就出现问题，通常是系统问题，OS类错误一般说明是系统资源不足，这在Linux/Unix下和信号量等参数设置有关，多出现在同一 主机运行多个数据库实例的情况（在Solaris上需要修改/etc/system文件中的内核参数，重起系统后修改生效）。在这个错误提示中，600错 误的第一个参数是OSDEP_INTERNAL，我们大致可以猜测到这是一个OS Dependent/Internal Error.很多Oracle的提示可以根据缩写猜到大致的含义，但是如果是错误号那就要依赖Oracle的文档来寻找答案。

在另外一个客户现场，遭遇过另外一个案例，当时客户的服务器异常断电，当系统重新启动后，数据库无法启动（提示：重启主机对于DBA来说应当极其慎重，很多隐藏的故障可能在重启时爆发出来，在没有做好充分 之前，不要贸然从事）。

数据库的症状是，启动主机到Nomount状态后，后台进程会立即将实例中止，也就是说数据库实例都无法稳定创建，告警日志文件信息如下：

Mon Dec 3 14:24:30 2007
Errors in file /oraclehx/app/admin/sxlss/bdump/sxlss_pmon_360454.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
PSP0 started with pid=3, OS id=422106
MMAN started with pid=4, OS id=303332
DBW0 started with pid=5, OS id=299324
。。。。。。。。。。。。。。。。。。
SMON started with pid=11, OS id=278882
RECO started with pid=12, OS id=319898
CJQ0 started with pid=13, OS id=295404
MMON started with pid=14, OS id=303428
MMNL started with pid=15, OS id=438776
Mon Dec 3 14:24:33 2007
PSP0: terminating instance due to error 472
Instance terminated by PSP0, pid = 422106

综合前面介绍的知识，如果实例都无法创建，那通常是在OS方面存在问题，这些问题在系统重新启动后才体现出来，经过检查，发现客户系统是AIX操作系统补丁应用不完全，最后导致了数据库无法启动，应用完整的系统补丁后，数据库恢复正常：

instfix -i|grep ML
All filesets for 5.3.0.0_AIX_ML were found.
All filesets for 5300-01_AIX_ML were found.
All filesets for 5300-02_AIX_ML were found.
All filesets for 5300-03_AIX_ML were found.
All filesets for 5300-04_AIX_ML were found.
All filesets for 5300-05_AIX_ML were found.
Not all filesets for 5300-06_AIX_ML were found.

这个案例给我们的经验是，当进行OS补丁应用时一定要认真确认，对关键补丁应当进行服务器重启验证，不能掉以轻心。

MSN空间完美搬家到新浪博客!