Analysis and Summary of several names that are easily obfuscated in Oracle

Analysis and Summary of several names that are easily obfuscated in Oracle

We know that various names in Oracle often appear in our configuration files, which are roughly as follows:

DB_NAME, INSTANCE_NAME, SERVICE_NAME in init. ora

When configuring DG, DB_UNIQUE_NAME is also used to differentiate the master and slave databases.

You must configure the environment variable ORACLE_SID in the operating system.

SID_NAME and GLOBAL_DBNAME are available in listener. ora.

SERVICE_NAME, SID, and net service name are available in tnsname. ora.

So what are the differences between so many names? What should we pay attention to during use? Here is a summary:

Some of these names are initialization parameters, such as DB_NAME, DB_QUNIQUE_NAME, DB_DOMAIN, and GLOBAL_NAME.
 
Some are just a naming or concept (there is no place to set it), such as net service name.
 
Some are field names in some tables/views, such as INSTANCE_NAME in the V $ INSTANCE view.
 
Some are the names of environment variables, such as ORACLE_SID.
 
Or the parameters set in the listener or client configuration file, such as SID, SID_NAME, SERVICE_NAME, GLOBAL_DBNAME

--------------------------------------------------------------------------------

Installing Oracle 12C in Linux-6-64

Install Oracle 11gR2 (x64) in CentOS 6.4)

Steps for installing Oracle 11gR2 in vmwarevm

Install Oracle 11g XE R2 In Debian

--------------------------------------------------------------------------------

DB_NAME:

The unique identifier of an Oracle database. This expression is sufficient for a single database, but with the popularization of distributed databases composed of multiple databases, this method of Command database creates a certain burden on database management, because the names of various databases may be the same, resulting in management confusion. To solve this problem, the Db_domain parameter is introduced. In this way, the database ID is determined by the two parameters Db_name and Db_domain, avoiding management confusion caused by database name duplication. This is similar to managing machine names on the Internet. We connect the parameters Db_name and Db_domain with '.' to indicate a database, and the database name is Global_name, that is, it extends Db_name. The Db_name parameter can only contain letters, numbers, '_', '#', and '$', and can contain a maximum of 8 characters. Pay special attention to this restriction. Sometimes it will fall into the trap and I will lose T_T once.

DB_DOMAIN:

Define the domain where a database is located. The domain name has nothing to do with the 'region' on the Internet. It is determined by the database administrator to better manage the distributed database. Of course, to facilitate management, it can be equal to the domain of the Internet.
 
GLOBAL_NAME:

For the unique identifier of a database (Oracle database), we recommend that you use this method to command the database. This value is determined when you create a database. The default value is Db_name.Db_domain. Any modifications TO the parameters of Db_name and Db_domain In the parameter file will not affect the value of Global_name. TO modify Global_name, you can only use the alter database rename GLOBAL_NAME TO <db_name.db_domain> command TO modify it, modify the parameters.
 
SERVICE_NAME:

This parameter is newly introduced by oracle8i. Before 8i, we used SID to identify an instance of the database. However, in the parallel environment of Oracle, a database corresponds to multiple instances, so that multiple network service names are required, configuration is cumbersome. To facilitate the setting in the parallel environment, the Service_name parameter is introduced, which corresponds to a database rather than an instance, and has many other advantages. The default value of this parameter is Db_name. Db_domain, which is equal to Global_name. A database can correspond to multiple service_names for more flexible configuration. This parameter has no direct relationship with SID, that is, the Service name does not have to be the same as the SID.

For example, if I can set ORACLE_SID = zlm when setting environment variables, then the SID is zlm. In tnsnames. ora, I can change SERVICE_NAME to zlm_SN.

# Tnsnames. ora

ZLM10G = # ZLM10G is the NET SERVICE NAME
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.1.91) (PORT = 1521 ))
)
(CONNECT_DATA =
(SERVICE_NAME = zlm_SN)
# SERVICE_NAME is zlm_SN, which is different from SID zlm.
)
)

As you can see, SERVICE_NAME uses the zlm_SN configured in netca just now, SID uses the zlm set by ORACLE_SID, and sets tnsnames. the net service name-related content automatically added by the system in ora is deleted (that is, the two dynamic listeners automatically registered by the pmon process), leaving only the configured part

Note: Here I also use netmgr to configure static listeners (as you can see from status UNKNOWN). The purpose of static listeners is to simplify the configurations, the pmon process dynamically registers the service to the listener after the database instance is started, which usually lags behind, after the listener is started, it takes several minutes to see that the service is listened on.

# 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)
)
)

After the above configurations of tnsnames. ora and linstener. ora, when we check the listening status, we will find that the following differences are true:

$ 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). # indicates that the corresponding SERVICE_NAME is zlm_SN
Instance "zlm", status UNKNOWN, has 1 handler (s) for this service... # indicates that the corresponding INSTANCE_NAME is zlm, that is, SID and ORACLE_SID.
The command completed successfully

In general, we will set SERVICE_NAME to be consistent with INSTANCE_NAME. It should be noted that although SERVICE_NAME can be used as an alias from INSTANCE_NAME, it must correspond to GLOBAL_DBNAME configured in listener. ora. Otherwise, even if static listening is configured, the service cannot be registered.

Note that the path for storing database data files is determined by DB_NAME. For a single-instance database, it is consistent with SID and INSTANCE_NAME by default. Of course, it can also be inconsistent (when DB_DOMAIN exists). You can select DBCA. Generally, after these three parameters are confirmed at DBCA, they will not be modified, the data file path is determined, for example, in my environment:
 
Data files are stored under/u01/app/oracle/oradata/zlm.
 
The tracking logs are stored in/u01/app/oracle/admin/zlm/bdump.

After a moment, check the listening status and find that a SERVICE_NAME consistent with INSTANCE_NAME (SID) will be dynamically registered automatically.

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

In this case, I personally judge that if static listening is not configured, The pmon process will always register a SERVICE_NAME with the same name as INSTANCE_NAME (SID), even if it is already in tnsnames. in ora, SERVICE_NAME = zlm_SN is modified. Only SERVICE_NAME inconsistent with INSTANCE_NAME (SID) is forcibly registered through static listening.

For more details, please continue to read the highlights on the next page:

1 2 Next Page