Managing Global Names in a Distributed System

In a distributed database system, each database should have a unique global database name. Global database names uniquely identify a database in the system. A primary administration task in a distributed system is managing the creation and alteration of global database names.

This section contains the following topics:

Understanding How Global Database Names Are Formed
Determining Whether Global Naming Is Enforced
Viewing a Global Database Name
Changing the Domain in a Global Database Name
Changing a Global Database Name: Scenario

Understanding How Global Database Names Are Formed

A global database name is formed from two components: a database name and a domain. The database name and the domain name are determined by the following initialization parameters at database creation:

Component	Parameter	Requirements	Example
Database name	`DB_NAME`	Must be eight characters or less.	`sales`
Domain containing the database	`DB_DOMAIN`	Must follow standard Internet conventions. Levels in domain names must be separated by dots and the order of domain names is from leaf to root, left to right.	`us.example.com`

These are examples of valid global database names:

DB_NAME	DB_DOMAIN	Global Database Name
`sales`	`example.com`	`sales.example.com`
`sales`	`us.example.com`	`sales.us.example.com`
`mktg`	`us.example.com`	`mktg.us.example.com`
`payroll`	`example.org`	`payroll.example.org`

The DB_DOMAIN initialization parameter is only important at database creation time when it is used, together with the DB_NAME parameter, to form the database global name. At this point, the database global name is stored in the data dictionary. You must change the global name using an ALTER DATABASE statement, not by altering the DB_DOMAIN parameter in the initialization parameter file. It is good practice, however, to change the DB_DOMAIN parameter to reflect the change in the domain name before the next database startup.

Determining Whether Global Naming Is Enforced

The name that you give to a link on the local database depends on whether the remote database that you want to access enforces global naming. If the remote database enforces global naming, then you must use the remote database global database name as the name of the link. For example, if you are connected to the local hq server and want to create a link to the remote mfg database, and mfg enforces global naming, then you must use the mfg global database name as the link name.

You can also use service names as part of the database link name. For example, if you use the service names sn1 and sn2 to connect to database hq.example.com, and hq enforces global naming, then you can create the following link names to hq:

HQ.EXAMPLE.COM@SN1
HQ.EXAMPLE.COM@SN2

See Also:
"Using Connection Qualifiers to Specify Service Names Within Link Names" for more information about using services names in link names

To determine whether global naming on a database is enforced on a database, either examine the database initialization parameter file or query the V$PARAMETER view. For example, to see whether global naming is enforced on mfg, you could start a session on mfg and then create and execute the following globalnames.sql script (sample output included):

COL NAME FORMAT A12
COL VALUE FORMAT A6
SELECT NAME, VALUE FROM V$PARAMETER
   WHERE NAME = 'global_names'
/

SQL> @globalnames

NAME         VALUE
------------ ------
global_names FALSE

Viewing a Global Database Name

Use the data dictionary view GLOBAL_NAME to view the database global name. For example, issue the following:

SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
-------------------------------------------------------------------------------
SALES.EXAMPLE.COM

Changing the Domain in a Global Database Name

Use the ALTER DATABASE statement to change the domain in a database global name. Note that after the database is created, changing the initialization parameter DB_DOMAIN has no effect on the global database name or on the resolution of database link names.

The following example shows the syntax for the renaming statement, where database is a database name and domain is the network domain:

ALTER DATABASE RENAME GLOBAL_NAME TO database.domain;

Use the following procedure to change the domain in a global database name:

Determine the current global database name. For example, issue:

SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
----------------------------------------------------------------------------
SALES.EXAMPLE.COM

Rename the global database name using an ALTER DATABASE statement. For example, enter:
```
ALTER DATABASE RENAME GLOBAL_NAME TO sales.us.example.com;
```

Query the GLOBAL_NAME table to check the new name. For example, enter:

SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
----------------------------------------------------------------------------
SALES.US.EXAMPLE.COM

Changing a Global Database Name: Scenario

In this scenario, you change the domain part of the global database name of the local database. You also create database links using partially specified global names to test how Oracle Database resolves the names. You discover that the database resolves the partial names using the domain part of the current global database name of the local database, not the value for the initialization parameter DB_DOMAIN.

You connect to SALES.US.EXAMPLE.COM and query the GLOBAL_NAME data dictionary view to determine the current database global name:

CONNECT SYSTEM@sales.us.example.com
SELECT * FROM GLOBAL_NAME;

GLOBAL_NAME
---------------------------------------------------------------------------- 
SALES.US.EXAMPLE.COM

You query the V$PARAMETER view to determine the current setting for the DB_DOMAIN initialization parameter:

SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'db_domain'; 

NAME       VALUE
---------  -----------
db_domain  US.EXAMPLE.COM

You then create a database link to a database called hq, using only a partially-specified global name:
```
CREATE DATABASE LINK hq USING 'sales'; 
```
The database expands the global database name for this link by appending the domain part of the global database name of the local database to the name of the database specified in the link.
You query USER_DB_LINKS to determine which domain name the database uses to resolve the partially specified global database name:
```
SELECT DB_LINK FROM USER_DB_LINKS; 

DB_LINK
------------------
HQ.US.EXAMPLE.COM
```
This result indicates that the domain part of the global database name of the local database is us.example.com. The database uses this domain in resolving partial database link names when the database link is created.

Because you have received word that the sales database will move to Japan, you rename the sales database to sales.jp.example.com:

ALTER DATABASE RENAME GLOBAL_NAME TO sales.jp.example.com;
SELECT * FROM GLOBAL_NAME; 

GLOBAL_NAME
---------------------------------------------------------------------------- 
SALES.JP.EXAMPLE.COM

You query V$PARAMETER again and discover that the value of DB_DOMAIN is not changed, although you renamed the domain part of the global database name:
```
SELECT NAME, VALUE FROM V$PARAMETER 
  WHERE NAME = 'db_domain'; 

NAME       VALUE
---------  -----------
db_domain  US.EXAMPLE.COM 
```
This result indicates that the value of the DB_DOMAIN initialization parameter is independent of the ALTER DATABASE RENAME GLOBAL_NAME statement. The ALTER DATABASE statement determines the domain of the global database name, not the DB_DOMAIN initialization parameter (although it is good practice to alter DB_DOMAIN to reflect the new domain name).
You create another database link to database supply, and then query USER_DB_LINKS to see how the database resolves the domain part of the global database name of supply:
```
CREATE DATABASE LINK supply USING 'supply'; 
SELECT DB_LINK FROM USER_DB_LINKS; 

DB_LINK
------------------
HQ.US.EXAMPLE.COM 
SUPPLY.JP.EXAMPLE.COM
```
This result indicates that the database resolves the partially specified link name by using the domain jp.example.com. This domain is used when the link is created because it is the domain part of the global database name of the local database. The database does not use the DB_DOMAIN initialization parameter setting when resolving the partial link name.

You then receive word that your previous information was faulty: sales will be in the ASIA.JP.EXAMPLE.COM domain, not the JP.EXAMPLE.COM domain. Consequently, you rename the global database name as follows:

ALTER DATABASE RENAME GLOBAL_NAME TO sales.asia.jp.example.com; 
SELECT * FROM GLOBAL_NAME; 

GLOBAL_NAME
---------------------------------------------------------------------------- 
SALES.ASIA.JP.EXAMPLE.COM

You query V$PARAMETER to again check the setting for the parameter DB_DOMAIN:
```
SELECT NAME, VALUE FROM V$PARAMETER 
  WHERE NAME = 'db_domain'; 

NAME        VALUE
----------  -----------
db_domain   US.EXAMPLE.COM 
```
The result indicates that the domain setting in the parameter file is the same as it was before you issued either of the ALTER DATABASE RENAME statements.
Finally, you create a link to the warehouse database and again query USER_DB_LINKS to determine how the database resolves the partially-specified global name:
```
CREATE DATABASE LINK warehouse USING 'warehouse'; 
SELECT DB_LINK FROM USER_DB_LINKS; 

DB_LINK
------------------
HQ.US.EXAMPLE.COM 
SUPPLY.JP.EXAMPLE.COM
WAREHOUSE.ASIA.JP.EXAMPLE.COM
```
Again, you see that the database uses the domain part of the global database name of the local database to expand the partial link name during link creation.

Note:
In order to correct the supply database link, it must be dropped and re-created.

See Also:
Oracle Database Reference for more information about specifying the DB_NAME and DB_DOMAIN initialization parameters