| Oracle® Database Advanced Security Administrator's Guide 10g Release 1 (10.1) Part Number B10772-01 |
|
|
View PDF |
| Oracle® Database Advanced Security Administrator's Guide 10g Release 1 (10.1) Part Number B10772-01 |
|
|
View PDF |
Oracle DCE Integration enables Oracle applications and tools to access Oracle Database servers in a distributed computing environment. This chapter briefly describes the Distributed Computing Environment (DCE), the Oracle DCE Integration product, and how to configure it. It contains the following topics:
The Distributed Computing Environment (DCE) from the Open Group is a set of integrated network services that works across multiple systems to provide a distributed environment. The network services include remote procedure calls (RPCs), directory service, security service, threads, distributed file service, diskless support, and distributed time service.
DCE is the middleware between distributed applications and the operating system/network services and is based on a client/server model of computing. By using the services and tools that DCE provides, users can create, use, and maintain distributed applications that run across a heterogeneous environment.
Oracle DCE Integration enables Oracle applications and tools to access Oracle database servers in a DCE environment.
Oracle DCE Integration requires Oracle Net Services and Oracle Database. It is based on the Open Software Foundation (OSF) DCE protocol (V1.1 and later).
Note that OSF has merged with X/OPEN, another standards group, to form The Open Group. This group is committed to continuing DCE support.
Oracle servers running DCE Integration 2.3.2 and later are backward compatible with clients running SQL*Net/DCE 2.1.6 or 2.2.3; however, Release 2.1.6 clients cannot take advantage of external roles.
A client running DCE Integration 2.3.2 or later cannot connect to a SQL*Net/DCE 2.1.6 or 2.2.3 server. A DCE Integration Release 2.3.2 or later client requires a Release 2.3.2 or later server in order to connect to a database.
Oracle DCE Integration has two components: DCE Communication/Security and DCE CDS Native Naming.
This component has three principal features:
Oracle DCE Integration provides authenticated Remote Procedure Call (RPC) as the transport mechanism that enables multi-vendor interoperability. RPC also uses some of the other DCE services, including directory and security services, to provide location transparency and secure distributed computing.
Oracle DCE Integration works with the DCE Security service to provide security within DCE cells. It enables a user logged onto DCE to securely access any Oracle database without having to specify a user name or password. This is sometimes called external authentication to the database, or single sign-on (SSO). Clients and servers that are not running DCE authentication services can interoperate with systems that have DCE security by specifying an Oracle password.
Oracle DCE Integration uses the multiple levels of security that DCE provides to ensure data authenticity, privacy, and integrity. Users have a range of choices, from no protection to full encryption for each connection, with a guarantee that no data is modified in transit.
The DCE Cell Directory Services (CDS) Native Naming component includes naming and location transparency.
DCE Integration registers Oracle Database connect descriptors in the DCE CDS, letting them be transparently accessed across the entire DCE environment. Users can connect to Oracle database servers in a DCE environment using familiar Oracle service names.
The DCE CDS offers a distributed, replicated repository service for name, address, and attributes of objects across the network. Because servers register their name and address information in the CDS, Oracle clients can make location-independent connections to Oracle Database servers. Services can be relocated without any changes to the client configuration. An Oracle utility is provided to load the Oracle service names with corresponding connect descriptors into CDS. After this is done, Oracle connect descriptors can be viewed from a central location with standard DCE tools.
For location of services across multiple cells, either of the following options can be used:
See Also:
|
Oracle Advanced Security provides flexibility in your use of DCE services. You have the following options:
The following are limitations in 10g Release 1 (10.1) of Oracle Advanced Security:
The following tasks, performed by the DCE cell administrator, assume that a DCE cell has been configured and the systems being used are part of that cell:
Use the following procedure model to add server principals:
% dce_login cell_admin password % rgy_edit Current site is: registry server at /.../cell1/subsys/dce/sec/master rgy_edit=>do p Domain changed to: principal rgy_edit=> add oracle rgy_edit=> do a Domain changed to: account rgy_edit=> add oracle -g none -o none -pw oracle_password -mp cell_admin_ password rgy_edit=> quit bye
In this example, a DCE principal named oracle is created. The principal has a corresponding account with a password set to oracle_password. The account does not belong to any DCE group or DCE profile.
|
Note: Perform this task on the server only once after DCE Integration has been installed. Do not perform this task on client systems. |
Install the key of the server into a keytab file, dcepa.key. This file contains the password of the principal under which the Oracle Net listener starts. The Oracle Net listener reads this file to authenticate itself to DCE. To generate the keytab file, enter the following:
% dce_login cell_admin password % rgy_edit Current site is: registry server at /.../cell1/subsys/dce/sec/master rgy_edit=> ktadd -p oracle -pw Oracle_password -f $ORACLE_HOME/dcepa/admin/dcepa.key rgy_edit=>quit bye
% dce_login cell_admin Enter Password:(password not displayed) $ cdscp cdscp> create dir /.:/subsys/oracle cdscp> create dir /.:/subsys/oracle/names cdscp> create dir /.:/subsys/oracle/service_registry cdscp> exit
oracle to the CDS-server group:
$ dce_login cell_admin Enter Password: (password not displayed) $ rgy_edit rgy_edit=> domain group Domain changed to: group rgy_edit=> member subsys/dce/cds-server -a oracle rgy_edit=> exit
This section describes how to configure an Oracle database server and Oracle Net Services to use Oracle DCE Integration after it has been successfully installed. It contains the following topics:
DCE addresses in the listener.ora and tnsnames.ora configuration files are defined by DCE parameters, illustrated in the following:
ADDRESS=(PROTOCOL=DCE)(SERVER_PRINCIPAL=server_name)(CELL_NAME=cell_name) (SERVICE=dce_service_name))
These parameters are described by Table 10-1:
You can specify a service as follows:
SERVICE=/.../cell_name/subsys/oracle/service_registry/dce_service_name
Alternatively, you can specify:
SERVICE=dce_service_name
if CELL_NAME=cell_name is also specified.
In this case, the cell name defaults to the local cell. However, this way of specifying service names only works if you are operating within a single cell.
To configure a server for DCE Integration, do the following:
sqlnet.ora and protocol.ora files with DCE address information.
|
Note: In this release, the configuration files |
For a database server to receive connections from Oracle Net clients in a DCE environment, there must be an Oracle Net listener active on the server platform. This process listens for connections on a network address that is defined in the listener.ora configuration file.
The SERVER_PRINCIPAL parameter designates what DCE principal the listener should be running under. In the following sample, the listener is running under principal oracle.
The following is a sample DCE address as it would appear in the listener.ora file.
LSNR_DCE= (ADDRESS= (PROTOCOL=DCE) (SERVER_PRINCIPAL=oracle) (CELL_NAME=cell1) (SERVICE=dce_svc)) SID_LIST_LSNR_DCE= (SID_DESC= (SID_NAME=ORASID) (ORACLE_HOME=/private/oracle9))
To use DCE authentication for logging on to an Oracle database, you must create database accounts that are authenticated externally. To enable secure external authentication, do the following:
|
Note: The privileges shown in this section are the minimum access privileges necessary. The actual set of privileges needed depends upon the instance or application. |
REMOTE_OS_AUTHENT=FALSE OS_AUTHENT_PREFIX=""
mts_dispatchers="(PROTOCOL=dce)(DISPATCHERS=3)"
|
Note: The |
Local Cell:
If users are connecting within a local cell, use the following format:
SQL> CREATE USER server_principal IDENTIFIED EXTERNALLY; SQL> GRANT CREATE SESSION TO server_principal;
For example:
SQL> CREATE USER oracle IDENTIFIED EXTERNALLY; SQL> GRANT CREATE SESSION TO oracle;
The entire CELL_NAME/SERVER_PRINCIPAL string must be 30 characters or less (this is an Oracle Database restriction--not a restriction of the DCE adapter).
For example:
SQL> CREATE USER "CELL1/ORACLE" IDENTIFIED EXTERNALLY; SQL> GRANT CREATE SESSION TO "CELL1/ORACLE";
Multiple Cells:
If connecting to the database across multiple cells, specify both the cell_name and the server_principal, as illustrated in the following:
SQL> CREATE USER "CELL_NAME/SERVER_PRINCIPAL" IDENTIFIED EXTERNALLY; SQL> GRANT CREATE SESSION TO "CELL_NAME/SERVER_PRINCIPAL";
You must enclose the externally-identified account name in double quotation marks, because the slash is a reserved character. Also, if the account (user) name is double-quoted, it must be capitalized.
For example:
SQL> CREATE USER "CELL1/ORACLE" IDENTIFIED EXTERNALLY; SQL> GRANT CREATE SESSION TO "CELL1/ORACLE";
When using this format, set the following parameter in the protocol.ora configuration file to FALSE:
dce.local_cell_usernames=false
References to an Oracle account created in this manner must include the schema/account in the correct format. Consider requests for access to tables from another account. When a user references the tables in another account created within a local cell, the command might appear as follows:
SQL> SELECT * FROM oracle.emp
If a user wants to access tables in another account created for connections across cells, the command might appear as follows:
SQL> SELECT * FROM "CELL1/ORACLE" .emp
| See Also:
Oracle Database Heterogeneous Connectivity Administrator's Guide, for more information about external authentication |
To set up external roles for DCE Integration, and enable connection to an Oracle database as SYSOPER or SYSDBA with DCE credentials, do the following:
OS_ROLES=TRUE
ORA_global_name_role[_[a][d]]
Table 10-2 describes the syntax components:
|
See Also: Oracle Database Administrator's Guide for more information about external roles |
dce_login klist
Sample Output:
% dce_login oracle
Enter Password:
% klist dce identity information: Warning: Identity information is not certified Global Principal: /.../ilab1/oracle Cell: 001c3f90-01f5-1f72-ba65-02608c2c84f3 /.../ilab1 Principal: 00000068-0568-2f72-bd00-02608c2c84f3 oracle Group: 0000000c-01f5-2f72-ba01-02608c2c84f3 none Local Groups: 0000000c-01f5-2f72-ba01-02608c2c84f3 none 0000006a-0204-2f72-b901-02608c2c84f3 subsys/dce/cds-server 00000078-daf4-2fe1-a201-02608c2c84f3 ora_dce222_dba 00000084-89c8-2fe8-a201-02608c2c84f3 ora_dce222_connect_d 00000087-8a13-2fe8-a201-02608c2c84f3 ora_dce222_resource_d 00000080-f681-2fe1-a201-02608c2c84f3 ora_dce222_role1_ad . . .
The following sample output lists external roles (DBA, CONNECT, RESOURCE, and ROLE1) that have been mapped to DCE groups:
SQL> SELECT * FROM session_roles; ROLE ------------------------------ CONNECT RESOURCE ROLE1 SQL> SET ROLE all; Role set. SQL> SELECT * FROM session_roles; ROLE ------------------------------ DBA EXP_FULL_DATABASE IMP_FULL_DATABASE CONNECT RESOURCE ROLE1 6 rows selected. SQL> EXIT
To configure DCE so that you can connect to an Oracle database as SYSOPER or SYSDBA with DCE credentials, do the following:
oracle as a member of the group(s).
$ dce_login cell_admin cell_admin_password $ rgy_edit rgy_edit=> domain group Domain changed to: group rgy_edit=> add ora_dce222_dba_ad rgy_edit=> add ora_dce222_operator_ad rgy_edit=> member ora_dce222_dba_ad -a oracle rgy_edit=> member ora_dce222_operator_ad -a oracle
tnsnames.ora.
ORADCE= (ADDRESS= (PROTOCOL=DCE) (SERVER_PRINCIPAL=oracle) (CELL_NAME=cell1) (SERVICE=dce_svc)) (CONNECT_DATA= (SID=ORASID) (GLOBAL_NAME=dce222)))
oracle as described by Task 2: Create and Name Externally Authenticated Accounts.$ dce_login oracle oracle_password $klist DCE Identity Information: Warning: Identity information is not certified Global Principal: /.../dce.dlsun685.us.oracle.com/oracle Cell: 00af8052-7e94-11d2-b261-9019b88baa77 /.../dce.dlsun685.us.ora cle.com Principal: 0000006d-88b9-21d2-9300-9019b88baa77 oracle Group: 0000000c-7e94-21d2-b201-9019b88baa77 none Local Groups: 0000000c-7e94-21d2-b201-9019b88baa77 none 0000006a-7e94-21d2-ad01-9019b88baa77 subsys/dce/cds-server 00000076-8b53-21d2-9301-9019b88baa77 ora_dce222_dba_ad 00000077-8b53-21d2-9301-9019b88baa77 ora_dce222_operator_ad Identity Info Expires: 1999-12-04-10:28:22 Account Expires: never Passwd Expires: never Kerberos Ticket Information: Ticket cache: /opt/dcelocal/var/security/creds/dcecred_43ae2600 Default principal: oracle@dce.dlsun685.us.oracle.com Server: krbtgt/dce.dlsun685.us.oracle.com@dce.dlsun685.us.oracle.com valid 1999-12-04-00:28:22 to 1999-12-04-10:28:22 Server: dce-rgy@dce.dlsun685.us.oracle.com valid 1999-12-04-00:28:22 to 1999-12-04-10:28:22 Server: dce-ptgt@dce.dlsun685.us.oracle.com valid 1999-12-04-00:28:26 to 1999-12-04-02:28:26 Client: dce-ptgt@dce.dlsun685.us.oracle.com Server: krbtgt/dce.dlsun685.us.o racle.com@dce.dlsun685.us.oracle.com valid 1999-12-04-00:28:26 to 1999-12-04-02:28:26 Client: dce-ptgt@dce.dlsun685.us.oracle.com Server: dce-rgy@dce.dlsun685.us. oracle.com valid 1999-12-04-00:28:27 to 1999-12-04-02:28:26
To configure a client for DCE Integration, you must configure the following Oracle Net files with DCE address and parameter information:
Typically, CDS is used for name resolution. Thus, a local naming configuration file (tnsnames.ora) is not used, except when loading names and addresses into CDS.
There are four DCE parameters located in the protocol.ora file. Each parameter begins with the prefix DCE. to distinguish it from parameters relevant to other protocols. If default values are used for these four parameters, DCE Integration does not require a protocol.ora file. The parameters and their current defaults follow:
Configuration parameters are not case-sensitive; you can enter them in either uppercase or lowercase.
The DCE.AUTHENTICATION parameter is optional. It indicates the authentication value to be used for each DCE RPC. The client DCE_AUTHENTICATION value must be the same as the server DCE_AUTHENTICATION value. If this entry is not specified, cell-wide default authentication is used. The options follow:
| Option | Description |
|---|---|
|
NONE |
No authentication |
|
DCE_SECRET |
DCE shared-secret key authentication (Kerberos) |
|
DCE_SECRET |
Default authentication level and recommended value |
|
DEFAULT |
Cell default |
DCE.PROTECTION is an optional field that specifies the data integrity protection levels for data transmission. The client DCE_PROTECTION level must be equal to or greater than the server DCE_PROTECTION level. If this entry is not specified, cell-wide default protection is used. The options follow:
DCE.TNS_ADDRESS_OID is an optional parameter that enables you to specify an alternative to the default value as follows:
DCE.TNS_ADDRESS_OID=1.3.22.1.x.x
DCE.LOCAL_CELL_USERNAMES is an optional parameter that defines the format used to specify the principal name (username), with or without the cell name. The choice you make for this parameter should be determined by whether or not users are making connections across cells--with unique names. The default for DCE.LOCAL_CELL_USERNAMES is now TRUE (it was set to FALSE in the DCE Integration 2.1.6 release).
The associated options follow:
Clients typically use Cell Directory Services (CDS) to resolve Oracle service names to addresses. Perform the following steps to configure CDS:
To use CDS for name resolution, the DCE Integration CDS Naming Adapter must be installed on all clients and servers that use CDS. Also, the CDS namespace must have been configured for use by DCE Integration.
| See Also:
DCE Integration installation instructions, and "Task 3: Configure DCE CDS for Use by Oracle DCE Integration" . |
For example, a service name such as ORADCE and its network address can be stored in DCE CDS.
Users can typically connect to Oracle services using the familiar Oracle service name if there are no domains or the database is in the user's default domain, as in the following example:
sqlplus /@ORADCE
This example assumes that DCE externally-authenticated accounts are in use.
As an alternative name resolution service, use a local naming configuration file, tnsnames.ora, when CDS is inaccessible. To do so, locate names and addresses of all Oracle servers in the local tnsnames.ora file.
On all DCE machines where CDS naming is used, add the object ID for the CDS attribute TNS_Address to the CDS attributes file. (The object ID must be the same across all machines.)
/opt/dcelocal/etc/cds_attributes file:
1.3.22.1.5.1 TNS_Address char
The first four digits of this TNS_Address attribute value, 1.3.22.1.x.y, are fixed, under DCE naming conventions. If the default TNS_Address object ID value 1.3.22.1.5.1 already exists in the cds_attributes file, you must specify a value for the object ID that is not already in use.
If you are unable to use the default value for the object ID, then you must specify the object ID in the protocol.ora file on the client.
If you had to specify a value other than the default value 1.3.22.1.5.1, then you must add the following parameter to the protocol.ora file:
DCE.TNS_ADDRESS_OID=1.3.22.1.x.y
Make sure that the object ID value in the cds_attributes file matches the value specified in the DCE.TNS_ADDRESS_OID parameter in the protocol.ora file.
The command to restart CDS varies between different operating systems. On the Solaris platform, for example, you can use the following command to restart CDS:
/opt/dcelocal/etc/rc.dce restart
To load the Oracle service names and addresses into CDS, create or modify a local naming configuration file, tnsnames.ora. This file is used to map service names to addresses for use by Oracle Net.
This section describes the parameters that must be included in the tnsnames.ora file. The file contains a list of Oracle service names mapped to connect descriptors of destinations or endpoints in the network. The sample DCE address in the following section shows a network address for an Oracle server with the Oracle service name ORADCE. It is used to connect to the service registered as DCE_SVC in the CDS directory
/.../cell_name/subsys/oracle/names. ORADCE=(DESCRIPTION=(ADDRESS=(PROTOCOL=DCE)(SERVER_PRINCIPAL=oracle)(CELL_ NAME=cell1)(SERVICE=DCE_SVC))(CONNECT_DATA=(SID=ORASID)))
|
Note: In this example, the Oracle service name and the DCE service name are different, although they are frequently the same. |
| See Also:
Oracle Net Services Administrator's Guide, for information about |
A separate utility called tnnfg is provided with Oracle DCE Integration to load connect descriptors into CDS. If you configure a new service name and address in tnsnames.ora, tnnfg adds the new service name and address to CDS. If you change the address for a particular service name, tnnfg updates the address for a particular service name.
To load the Oracle service names or aliases from tnsnames.ora into CDS, enter the following at the system prompt:
% dce_login cell_admin % tnnfg dceload full_pathname_to_tnsnames.ora % Enter Password:(password will not display)
Be sure to enter the full path name of the tnsnames.ora file, and ensure that the sqlnet.ora file exists in the same directory as the tnsnames.ora file.
You can keep tnsnames.ora available as a backup in case CDS becomes unavailable. To assure that CDS is routinely searched instead of tnsnames.ora, configure the NAMES.DIRECTORY_PATH parameter in a profile (sqlnet.ora), as described by "Step 6: Modify the sqlnet.ora File to Resolve Names in CDS" (the next section).
The parameters required in a profile (sqlnet.ora) depend upon the version of SQL*Net or Oracle Net Services you are using.
For a client or server to use DCE CDS Naming, the administrator must do the following:
sqlnet.ora file:
NAMES.DIRECTORY_PATH=(cds, tnsnames, onames)
The first name resolution service listed as a value for this parameter is used. If it is unavailable for any reason, the next name resolution service is used, and so forth.
This section describes how to connect to an Oracle database after installing Oracle DCE Integration, and configuring both DCE and Oracle to use Oracle DCE Integration in the following topics:
To start the listener, do the following:
% dce_login principal_name password % lsnrctl start listener_name
For example, if the listener name is LSNR_DCE in the listener.ora file, enter the following:
% dce_login oracle orapwd % lsnrctl start LSNR_DCE
% rpccp show mapping
Look for the line that includes the dce_service_name that is part of the listener address.
dce_service_name as follows:
% cdscp show object "/.:/subsys/oracle/service_registry/dce_service_name"
For example:
The following command shows you the mapping in the CDS namespace that the listener has chosen for the endpoint:
% cdscp show object "/.:/subsys/oracle/service_registry/dce_svc" SHOW OBJECT /.../subsys/oracle/service_registry/dce_svc AT 1999-05-15-17:10:52 RPC_ClassVersion = 0100 CDS_CTS = 1999-05-16-00:05:01.221106100/aa-00-04-00-3e-8c CDS_UTS = 1999-05-16-00:05:01.443343100/aa-00-04-00-3e-8c CDS_Class = RPC_Server CDS_ClassVersion = 1.0 CDS_Towers = : Tower = ncacn_ip_tcp:144.25.23.57[]
After externally-identified accounts have been set up, you can take advantage of DCE authentication to log in to Oracle without providing any username or password information. To use this single sign-on capability, just log in to DCE using a command like the following:
% dce_login principal_name password
For example:
% dce_login oracle orapwd
|
Note: You only need to enter the |
You can now connect to an Oracle server without using a username or password. Enter a command like the following:
% sqlplus /@net_service_name
where net_service_name is the database service name.
For example:
% sqlplus /@ORADCE
From a client, you can still connect with a user name and password:
% sqlplus username/password@net_service_name
where net_service_name is the Oracle Net service name.
For example:
% sqlplus scott/tiger@ORADCE
Clients without access to DCE and CDS can still connect to Oracle servers in DCE using TCP/IP or some other protocol if a listener is configured to do this. If a listener has been configured in the listener.ora file on the server, non-DCE clients can use normal Oracle Database and Oracle Net Services procedures to connect to an Oracle server in DCE.
|
Note: In this case, DCE security is not available to clients. Also, service names are resolved to network addresses and located in a |
The following section contains these topics, which include samples of listener.ora and tnsnames.ora files as they would be configured if a client from outside of DCE wanted to connect to Oracle database servers in a DCE environment:
At least the following two Oracle parameter files are needed for successful client/server communications; create and modify these files using a text editor:
The parameter files are described in the following sections:
The listener.ora file resides on the listener node. It defines listener characteristics and the addresses at which the listener listens.
In the following example, each element is displayed on a separate line, to show the file's structure. This is the recommended format, but you do not have to put each element on a separate line. Be sure to include all the appropriate parentheses, and to indent if you must continue an element on the next line.
This example assumes the UNIX operating system and the TCP/IP protocol for one listener, and the DCE protocol for another listener. A single listener can have multiple addresses. For example, instead of having two separate listeners for different database instances on a server node, you could have one listener for both, listening on both TCP/IP and on DCE. However, performance is improved with separate listeners.
LSNR_TCP= (ADDRESS_LIST= (ADDRESS= (PROTOCOL=IPC) (KEY=DB1) ) (ADDRESS= (PROTOCOL=tcp) (HOST=rose) (PORT=1521) )) SID_LIST_LSNR_TCP= (SID_DESC= (SID_NAME=ORASID) (ORACLE_HOME=/usr/jprod/Oracle Database) ) LSNR_DCE= (ADDRESS= (PROTOCOL=DCE) (SERVER_PRINCIPAL=oracle) (CELL_NAME=cell1) (SERVICE=dce_svc)) SID_LIST_LSNR_DCE= (SID_DESC= (SID_NAME=ORASID) (ORACLE_HOME=/usr/prod/oracle8)) #For all listeners, the following parameters list sample #default values. PASSWORDS_LISTENER= STARTUP_WAIT_TIME_LISTENER=0 CONNECT_TIMEOUT_LISTENER=10 TRACE_LEVEL_LISTENER=OFF TRACE_DIRECTORY_LISTENER=/usr/prod/Oracle Database/network/trace TRACE File_LISTENER=listener.trc LOG_DIRECTORY_LISTENER=/usr/prod/Oracle Database/network/log LOG_FILE_LISTENER=listener.log
This file resides on both the client and the server nodes. It lists the service names and addresses of all services on the network.
The following sample tnsnames.ora file maps the service name ORATCP to the connect descriptor that includes a TCP/IP address and the service name ORADCE to a connect descriptor that includes a DCE address.
ORATCP = (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=rose) (PORT=1521) ) (CONNECT_DATA= (SID=DB1) ) ) ORADCE=(DESCRIPTION= (ADDRESS= (PROTOCOL=DCE) (SERVER_PRINCIPAL=oracle) (CELL_NAME=cell1) (SERVICE=dce_svc) ) (CONNECT_DATA= (SID=ORASID) ) )
To access the DB1 database, a user can use ORATCP to identify the appropriate connect descriptor.
For example:
sqlplus scott/tiger@oratcp
Typically, names are resolved into network addresses by CDS. Although the main purpose of the tnsnames.ora file (in the context of native naming adapters) is to load Oracle service names and network addresses into CDS, it could be used temporarily as a backup name resolution service if CDS is inaccessible.
To use the tnsnames.ora file for name lookup and resolution, remove (or comment out) the "native name" parameters from the sqlnet.ora file on the client. To comment out the lines, add a pound sign (#) at the beginning of each line.
For example:
#native_names.use_native=true #native_names.directory_path=(dce)
You can use tnsnames.ora for name lookup and resolution when DCE CDS is unavailable if you have TNSNAMES listed as a value for the NAMES.DIRECTORY_PATH parameter in the sqlnet.ora file on the client.
For example:
names.directory_path=(dce, tnsnames)
This parameter enables you to list more than one names resolution method. The methods are tried in order. In this example, DCE is attempted first. If it is unsuccessful, TNSNAMES is tried next.
|
 Copyright © 1996, 2003 Oracle Corporation All Rights Reserved. |
|