：ORACLE中极易混淆的几个NAME

前言

    实例(对应INSTANCE_NAME)，就是管理相关库的内存结构的名字（由SGA、PGA、服务器进程、用户进程、后台进程等组成）。
    数据库(对应DB_NAME或GLOBAL_NAME)，就是实际的磁盘上的文件（数据文件、日志文件、控制文件等），负责保存数据，但由对应的实例来操作它的数据。
    服务名(对应SERVICE_NAME)，就是对外公布的名称，为网络监听服务。
    一个Oracle数据库系统中可以同时安装多个数据库，每一个数据库对应一个唯一的实例(1:1)，但是OPS系统除外，可以多个实例同时对一个数据库操作，称为并行服务器(1:N)，还有RAC架构，也是多个实例为一个数据库实例服务(1:N)，另外还有ASM磁盘组实例，用于管理ASM这种OMF存储结构而诞生的实例，这些都是很容易混淆的概念。

详细

ORACLE_SID：（ORACLE SYSTEM IDENTIFIER）

    以环境变量的形式出现的。
    Oracle实例是由SGA和一组后台进程组成的，实例的创建和启动需要一个参数文件，而参数文件的名称就是由ORACLE_SID决定的。对于init文件，缺省的文件名称是init<ORACLE_SID>.ora，对于spfile文件，缺省的文件名称是spfile<ORACLE_SID>.ora。
    设置不同的ORACLE_SID值，就可以默认使用不同的参数文件启动不同的数据库实例。另外，ORACLE_SID的作用远远不是作为一个实例入口这么简单的，在实例启动后，实例名称INSTANCE_NAME也是从ORACLE_SID得到的。

 

若登录时不指定连接串，一般是采用环境变量 ORACLE_SID,WINDOWS系统默认的ORACLE_SID值为最后所安装的实例。

 

    在Unix/Linux环境可以 echo $ORACLE_SID 查看ORACLE_SID的值；
    在Windows环境可以（以我自己的机器为例）：
    （1）开始—>运行（输入regedit），在HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraDb10g_home1中有ORACLE_SID的键值（系统默认值）

    （2）登陆数据库，通过SQL语句查看（查看当前使用的数据库所对应的实例名称）：
     SQL>show parameter instance_name;
     SQL>select * from v$instance;

     SQL>show parameter instance;

 

INSTANCE_NAME:

    实例名称，这是Oracle实例的名字，用来区分不通的实例。在Oracle9i之前，该名字存储在两个地方：参数文件和数据库的内部试图（V$INSTANCE）.
    而在Oracle10g之后的版本中，该名字不再出现在参数文件中，而是动态从系统中获得，默认是取自ORACLE_SID。
    INSTANCE_NAME的作用除了区别不同实例之外，在监听器动态注册时，还会用于向监听器注册。比如instance_name=kanon,监听中将动态注册Instance "kanon",status READY信息。

DB_NAME：    

             对一个数据库（Oracle database）的唯一标识。这种表示对于单个数据库是足够的，但是随着由多个数据库构成的分布式数据库的普及，这种命令数据库的方法给数据库的管理造成一定的负担，因为各个数据库的名字可能一样，造成管理上的混乱。为了解决这种情况，引入了Db_domain参数，这样在数据库的标识是由Db_name和Db_domain两个参数共同决定的，避免了因为数据库重名而造成管理上的混乱。这类似于互连网上的机器名的管理。我们将Db_name和Db_domain两个参数用’.’连接起来，表示一个数据库，并将该数据库的名称称为Global_name，即它扩展了Db_name。Db_name参数只能由字母、数字、’_’、’#’、’$’组成，而且最多8个字符。特别要注意这个限制，有的时候会掉坑里，我就掉过一次T_T。

DB_DOMAIN:

    定义一个数据库所在的域，该域的命名同互联网的’域’没有任何关系，只是数据库管理员为了更好的管理分布式数据库而根据实际情况决定的。当然为了管理方便，可以将其等于互联网的域。

GLOBAL_NAME：

    对一个数据库（Oracle database）的唯一标识，oracle建议用此种方法命令数据库。该值是在创建数据库是决定的，缺省值为Db_name.Db_domain。在以后对参数文件中Db_name与Db_domain参数的任何修改不影响Global_name的值，如果要修改Global_name，只能用ALTER DATABASE RENAME GLOBAL_NAME TO <db_name.db_domain>命令进行修改，然后修改相应参数。

SERVICE_NAME：

    该参数是oracle8i新引进的。在8i以前，我们用SID来表示标识数据库的一个实例，但是在Oracle的并行环境中，一个数据库对应多个实例，这样就需要多个网络服务名，设置繁琐。为了方便并行环境中的设置，引进了Service_name参数，该参数对应一个数据库，而不是一个实例，而且该参数有许多其它的好处。该参数的缺省值为Db_name. Db_domain，即等于Global_name。一个数据库可以对应多个Service_name，以便实现更灵活的配置。该参数与SID没有直接关系，即Service name不必与SID一样。
    比方说我可以在设置环境变量的时候，设置ORACLE_SID=zlm，那么这个时候SID就是zlm,而在tnsnames.ora中，我可以把SERVICE_NAME改成zlm_SN。

##tnsnames.ora
ZLM10G = ##ZLM10G为NET SERVICE NAME
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.91)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = zlm_SN) ##SERVICE_NAME为zlm_SN，与SID为zlm不同
)

    可以看到，SERVICE_NAME用了刚才在netca中配置的zlm_SN，SID用了ORACLE_SID设置的zlm，并且把tnsnames.ora里系统自动添加的NET SERVICE NAME相关的内容删除了(即由pmon进程自动注册的2个动态监听)，只留下自己配置的部分。
    注意，这里我还使用了netmgr配置了静态监听（从status UNKNOWN其实便可知），静态监听的目的，除了简化配置外，还可以提供在数据库未启动前仍能连接的功能，而不再是等数据库实例启动后，由pmon进程负责动态向监听注册服务，动态监听会通常比较滞后，启动监听后，要等若干分钟，才能看到服务被监听。

##listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = zlm_SN)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(SID_NAME = zlm)
)
)

    经过上面的tnsnames.ora和linstener.ora的配置，当我们查看监听状态的时候，就会发现不同：

$lsnrctl status ...... Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "zlm_SN" has 1 instance(s).## 表示对应的SERVICE_NAME为zlm_SN
Instance "zlm", status UNKNOWN, has 1 handler(s) for this service... ##表示对应的INSTANCE_NAME为zlm，也即SID和ORACLE_SID
The command completed successfully

    而通常情况下，我们会设置SERVICE_NAME和INSTANCE_NAME一致。这里还要注意的是，SERVICE_NAME虽然可以脱离INSTANCE_NAME搞别名，但是必须对应listener.ora里配置的GLOBAL_DBNAME，否则就算配好了静态监听，也是注册不了服务的。注意，数据库数据文件存放的路径，是根据DB_NAME来确定的，而对于单实例数据库而言，默认与SID和INSTANCE_NAME是一致的，当然，也可以不一致(有DB_DOMAIN的情况下)，DBCA的时候可以选择，通常这3个参数在DBCA的时候确认下来后，就基本不再去修改了，那么数据文件路径也就确定下来了，如我的环境中：数据文件就放在/u01/app/oracle/oradata/zlm下面而跟踪日志就放在/u01/app/oracle/admin/zlm/bdump下面
过了片刻以后，再查看监听状态，发现自动还是会去动态注册一个和INSTANCE_NAME(SID)一致的SERVICE_NAME

Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.91)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "zlm" has 1 instance(s).
Instance "zlm", status READY, has 1 handler(s) for this service...
Service "zlmXDB" has 1 instance(s).
Instance "zlm", status READY, has 1 handler(s) for this service...
Service "zlm_SN" has 1 instance(s).
Instance "zlm", status UNKNOWN, has 1 handler(s) for this service...
Service "zlm_XPT" has 1 instance(s).
Instance "zlm", status READY, has 1 handler(s) for this service...
The command completed successfully

    这样的话，我个人判断，如果不配置静态监听的话，pmon进程始终会去监听那里注册一个名字和INSTANCE_NAME(SID)一致的SERVICE_NAME，即便是已经在tnsnames.ora中修改了SERVICE_NAME=zlm_SN，而只有通过静态监听强制注册一个与INSTANCE_NAME(SID)不一致的SERVICE_NAME，才会被监听到

 

NET SERVICE NAME：

    网络服务名，又可以称为数据库别名(database alias)。是客户端程序访问数据库时所需，屏蔽了客户端如何连接到服务器端的细节，实现了数据库的位置透明的特性。通常当我们用DBLINK连接数据库时，使用的就是这个名字，由USING关键字指定，USING 'connect_string'这里connect_string其实就是NET SERVICE NAME。说到DBLINK还要提一点，就是当源数据库GLOBAL_NAME=TRUE时，link_name必须与远程数据库的全局数据库名global_name）相同；否则，可以任意命名。同样地，当我们用sqlplus system/oracle@xxx来连接DB SERVER时，这个xxx就是NET SERVICE NAME，我的环境中是ZLM10G，如：

ZLM10G =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.91)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = zlm_SN)
)
)

    那么根据tnsnames.ora的配置，这里ZLM10G就是zlm_SN这个SERVICE_NAME所对应的NET SERVICE NAME 如果用sqlplus system/oracle@zlm是连不上DB SERVER的，只有用sqlplus system/oracle@zlm10g才行。

 

 

总结

    一条startup命令，究竟是如何启动庞大的oracle数据库的呢？下面我们来贯穿起来整个启动流程，一探究竟：
    首先，系统接收到startup命令，立刻采取行动，取得环境变量ORACLE_SID的值，启动第一阶段--实例创建。系统根据找到的参数文件启动ORACLE数据库实例，实例启动后，一切由实例接管：注册INSTANCE_NAME,往往INSTANCE_NAME就是来自ORACLE_SID，接着向监听器动态注册实例自己，并将INSTANCE_NAME写入系统数据字典表，
    接下来，实例进一步读取参数文件，取得DB_NAME、控制文件、检查点等信息，进入第二阶段--挂载数据库。实例从控制文件中取得DB_NAME，并取得数据文件、日志文件等信息，进行DB_NAME的一致性检验、文件的存在性判断等工作之后，实例将挂载数据库，挂载的数据库就是DB_NAME指定的数据库。
    最后，实例进入第三阶段--启动数据库。这一阶段，实例进行了两项检查：检查点和更改点检查，之后启动数据库。