Global Database Technical Services
Document Title
Document Category
Original Author
Reviewer(s)
GDTS Policy Regarding Oracle Database Connectivity and the use of Database Links
Policy
Dan Quast
John Dupay, Bob Kyarsgaard, Arlynn Leapaldt, Ed Miller, Dave Moore, Jeremy Thompson, Tim Watts
Document Scope
This document establishes GDTS oracle database connectivity policies for global name, service name, database
links, oracle names aliases and the various parameters that affect them. It applies to both tnsnames and Oracle
Names for new and existing oracle databases. It also takes into account constraints placed on connectivity by
oracle replication.
Introduction
In the absence of connectivity standards applications that use oracle are vulnerable to connection-related
problems in the areas of replication, database links, changes to DNS definitions and database moves. The
policies and recommendations in this document establish standards that minimize connection-related failures for
compliant oracle databases and the applications that access them.
The general approach and plan is to implement oracle names using a hierarchical naming model and regional
administration while using a flat naming standard for global name and service name. The flat naming standard
ensures that database moves from one domain to another will be transparent to application code. This document
also includes a section that demonstrates how applications should code when using database links.
Document Sections
Section 1: Terminology
1.1. Node
1.2. Domain
1.3. Database Name
1.4. Oracle Names Alias
Section 2: Summary of Approach
Section 3: Policies
3.1. GLOBAL_NAMES Initialization Parameter
3.2. Naming Conventions for flat domain name, Global Name, Service Name, Database Link Name
3.3. Database Link Ownership and Creation
3.4. Use of Global, Public, and Private Database Links
3.5. Use of Userid and Password When Creating Database Links
3.6. sqlnet.ora
3.7. sqlnet.ora’s NAMES.DEFAULT_DOMAIN parameter
3.8. sqlnet.ora’s NAMES.DIRECTORY_PATH parameter
Section 4: Application Perspective
Section 5: Resolving service name collisions for partner, vendor, and/or non-GDTS-supported databases.
533580269
Page 1 of 8
Last printed 3/9/2016 4:24:00 PM
Global Database Technical Services
Section 1: Terminology
1.1 Node
An Oracle Names term that refers to a server. A node’s name matches exactly the server’s DNS entry
and must be kept in sync with DNS at all times.
1.2 Domain
An Oracle Names term that is ‘used to divide the namespace of a network’. ‘world’, ‘cargill.com’, and
‘fert.cargill.com’ are examples of domain names.
1.3 Database Name
Database name consists of a name component and a domain component. sales.cargill.com is an example
of a database name, where cargill.com is the domain component.
1.4 Oracle Names Alias
An alternate name for a Database.
533580269
Page 2 of 8
Last printed 3/9/2016 4:24:00 PM
Global Database Technical Services
Section 2: Summary of Approach
The drivers of the policies contained in this document are the following:




Implement Oracle Names
Make database moves transparent to application code
Ensure that the use of oracle replication does not render previously-defined database links unusable
Accommodate the use of either a flat or a hierarchical domain naming model in Oracle Names.
The approach is to impose a flat domain name for global name and service name in Oracle Names even if a
hierarchical naming model is used in Oracle Names. Use of a hierarchical naming model has these implications:

When using an Oracle Names hierarchical naming model, global database link name is no longer
usable. This is seen as an acceptable trade-off to secure application-transparent database moves in a
hierarchical Oracle Names environment.

In a hierarchical name environment, an alias is required for each database in the root administration
region. All delegated regions must go through the root region to resolve service names from foreign
regions when first referenced. After the first reference they are cached locally and so do not
represent a performance concern.
533580269
Page 3 of 8
Last printed 3/9/2016 4:24:00 PM
Global Database Technical Services
Section 3: Policies
3.1 GLOBAL_NAMES Initialization Parameter
Policy
Set GLOBAL_NAMES initialization parameter to TRUE for all Cargill oracle databases. This applies to
development, test, production, and standby databases.
Notes
Replication requires that initialization parameter GLOBAL_NAMES be set to TRUE. Setting
GLOBAL_NAMES=TRUE immediately for new databases avoids the problem of database link names
becoming unusable when this parameter is changed from FALSE to TRUE to support replication.
3.2 Naming Conventions for flat domain name, Global Name, Service Name, Database Link Name
Policy
flat domain name cargill.com
Global Name <database>.cargill.com (example: piodsch.cargill.com)
Service Name exactly the same as Global Name
Database Link Name same as remote database’s Global Name
Notes
 flat domain name
o Oracle names currently uses a hierarchical naming model to support regional
administration of oracle names servers. An artificial flat naming standard is being
imposed for global name and service name to prevent problems with application database
links when databases are moved from one domain to another. This applies to all new
databases, and all existing databases where feasible.
o ‘cargill.com’ is preferred over ‘world’ because it is less likely to collide with non-GDTS
supported databases.
 Global Name
o A given standby database’s global name value will not match the corresponding
production database’s global name value, although both will have identical SID’s. The
naming convention for standby databases is to use ‘s’ as the first letter, whereas the
corresponding production database uses ‘p’ as its first letter. An example standby
database name for a production database named piodsch.cargill.com is
siodsch.cargill.com.
 Service Name
o When Oracle Names is implemented using a hierarchical naming model it creates
hierarchical service names that match the hierarchical database name. From an
application database link perspective this does not allow for transparent movement of
databases between domains.
To make movement of databases transparent to application code, each database will
require an additional oracle names alias at the root administrative level whose name
matches the database’s global name and that identifies the appropriate server.
Performance for distributed administrative sites is mitigated by the use of Oracle Names
local caching of database names.
o Use only the alias when forming synonyms for application database links to specific
database objects.
 Database Link Name
533580269
Page 4 of 8
Last printed 3/9/2016 4:24:00 PM
Global Database Technical Services
o Database link name and Global Name of the remote database will always match even if
multiple public and private database links are created. Creating multiple public database
links implies the use of Connection Qualifiers. Connection qualifiers may also be used
for security purposes.
3.3 Database Link Ownership and Creation
No Policy
Notes
Users may create these if their security architecture has already granted them permissions to create
database links. Database link naming convention is automatically enforced when the
GLOBAL_NAMES initialization parameter is set to TRUE.
3.4 Use of Global, Public, and Private Database Links
Policy
 Do not use Global Database Links. The flat domain name makes these invalid in a Oracle Names
hierarchical naming model environment.

Allow both public and private database links.

Private database links are recommended over public database links.
3.5 Use of Userid and Password When Creating Database Links
No Policy
Recommendation
Userid and password should not be explicitly stated at dblink creation time (referred to as a Connected
User Link). This means that the user must have an identical userid and password on the remote database.
This applies to both public and private database links.
3.6 sqlnet.ora
Policy
Maintain a sqlnet.ora on every server and every client.
3.7 sqlnet.ora’s NAMES.DEFAULT_DOMAIN parameter
Policy
Set this value to the flat domain name (see flat domain name above).
3.8 sqlnet.ora’s NAMES.DIRECTORY_PATH parameter
Policy
Set this parameter as follows:
533580269

Order as 1) oracle names, 2) hostname, and 3) tnsnames for servers where service name is
resolved using Oracle Names.

Order as 1) tnsnames, 2) hostname, and 3) oracle names for servers where service name is
resolved using tnsnames.
Page 5 of 8
Last printed 3/9/2016 4:24:00 PM
Global Database Technical Services
Section 4: Application Perspective
The policies stated in this document will allow either a local database or a remote database to be moved from
one domain to another without requiring a change to application database link definitions. This section is
specific to a development environment where development, test, and production each have a set of linked
databases, such as a transaction database linking to a data warehouse, or vice versa. Example:
Development
Test
Production
dtrans.cargill.com
ttrans.cargill.com
ptrans.cargill.com
links to
links to
links to
dsales.cargill.com
tsales.cargill.com
psales.cargill.com
The goal is to be able to move application code from development to test and then to production without having
to change application code that uses a database link. This is accomplished using database synonyms. See the
example code that follows:
Use This:
database synonym:
application code:
CREATE SYNONYM SALES_TOTAL FOR SALES_TOTAL@DSALES.CARGILL.COM;
SELECT COUNT(*) FROM SALES_TOTAL;
DO NOT USE THIS:
application code:
SELECT COUNT(*) FROM SALES_TOTAL@DSALES.CARGILL.COM;
Only the synonym is changed ( in the test database) when moving this code to test:
database synonym: CREATE SYNONYM SALES_TOTAL FOR SALES_TOTAL@TSALES.CARGILL.COM;
application code:
<no change>
When moved to production again only the synonym changes:
database synonym: CREATE SYNONYM SALES_TOTAL FOR SALES_TOTAL@PSALES.CARGILL.COM;
application code:
<no change>
533580269
Page 6 of 8
Last printed 3/9/2016 4:24:00 PM
Global Database Technical Services
Section 5: Resolving service name collisions for partner, vendor, and/or non-GDTS-supported databases.
Use a tnsnames.ora file to resolve database name collisions. Set the order of the sqlnet.ora’s
NAMES.DIRECTORY_PATH parameter to 1) tnsnames, 2) hostname, and 3) oracle names.
533580269
Page 7 of 8
Last printed 3/9/2016 4:24:00 PM
Global Database Technical Services
Section 6: References
533580269
Page 8 of 8
Last printed 3/9/2016 4:24:00 PM