Configuration Files
This appendix describes the following:
| Note:
Oracle only supports configuration files created
by Oracle Network Manager or SQL*Net Easy Configuration. The TNSNAMES.ORA
file does not exist if Oracle Names is configured with Oracle Network Manager. |
Understanding the Configuration Files
Oracle Network Products use the following configuration
files:
| On Your Server |
On Your Client |
| LISTENER.ORA |
SQLNET.ORA |
| NAMES.ORA |
TNSNAMES.ORA |
| SQLNET.ORA |
TNSNAV.ORA |
| TNSNAMES.ORA |
|
Below is a description of the configuration files:
| Configuration File |
Description |
| LISTENER.ORA |
Includes service names and addresses of all listeners
on a machine, the system identifiers (SIDs) of the databases for which
they listen, and various control parameters used by the listener. |
| NAMES.ORA |
Contains control parameters for Oracle Names Servers
that do not use Dynamic Discovery Option (DDO).
This file is not needed for DDO. |
| SQLNET.ORA |
Includes optional diagnostic parameters, client
information about Oracle Names Servers, and can contain other optional
parameters. |
| TNSNAMES.ORA |
Includes a list of service names of network databases
mapped to connect descriptors. |
| TNSNAV.ORA |
Lists the local communities of the client profile
or node.
This file is not needed and used for single community
networks. It is used only when working with MultiProtocol Interchange.
Additional Information: See Understanding
SQL*Net for further information about this file. |
| Note:
It is possible to have system and local versions
of TNSNAMES.ORA and SQLNET.ORA files. Any service name or parameter is
first searched in the local version of the configuration file. If the service
name or parameters is not found in the local version, it is searched in
the system version.
The system version is located in the ORACLE_HOME\NETWORK\ADMIN
directory. A local version can exist in the current working directory where
the application is running. For example, if you start SQL*Plus in ORACLE_HOME\BIN,
then SQL*Net looks for a local TNSNAMES.ORA in ORAWIN\BIN. If you start
SQL*Plus in \PLUS, then SQL*Net looks for a local TNSNAMES.ORA in \PLUS.
A consequence of this is that you can have multiple
local files in the various directories from which you start applications.
In most cases, it is recommended that only one TNSNAMES.ORA file exist
and that it be located in the default ORACLE_HOME\NETWORK\ADMIN
directory. |
A description of how the files are created is described
below:
| This File... |
Is... |
| LISTENER.ORA |
created during installation |
| NAMES.ORA |
created on the server by Oracle Network Manager
when configuring without DDO |
| SQLNET.ORA |
created during installation on the clients and
server, and regenerated on the client by SQL*Net Easy Configuration or
Oracle Network Manager |
| TNSNAMES.ORA |
created on the clients and server by SQL*Net Easy
Configuration or Oracle Network Manager |
| TNSNAV.ORA |
created on the clients and server by Oracle Network
Manager |
Understanding the TNSNAMES.ORA File
The TNSNAMES.ORA file is used by clients and distributed
database servers to identify potential server destinations.
A sample file is shown in Figure
E-1:
Figure E-1 TNSNAMES.ORA Configuration File
################
# Filename......: tnsnames.ora
# Name..........: LOCAL_REGION.world
# Date..........: 04-DEC-96 13:50:40
################
service_name.world = <---world is the domain name
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = <---listener address
(COMMUNITY = TCP.world)
(PROTOCOL = TCP)
(HOST = server_name) <---or, use IP address of NT server
(PORT = 1521) <---must match port in LISTENER.ORA file )
)
(CONNECT_DATA =
(SID = SID))<---database name, default is ORCL
)
)
The address of the server in TNSNAMES.ORA is the same
as the address of the listener for a server in LISTENER.ORA. Similarly,
the address in the TNSNAMES.ORA file includes the SID which is required
(as SID_NAME) in the LISTENER.ORA file.
TNSNAMES.ORA is comprised of two parts:
These elements are described in the following sections.
Specifying Connect Descriptors
Every service requires a connect descriptor. For a
database, a connect descriptor describes the location of the network listener
and the SID of the database to which to connect. The TNSNAMES.ORA file
is installed in the Oracle7 home directory under ORACLE_HOME\NETWORK\ADMIN.
Database connect descriptors typically consist of two sections:
-
ADDRESS
-
CONNECT_DATA SID keyword
ADDRESS
The application address is the information required
to reach the application within a given protocol environment. It includes
the:
-
community in which the destination resides
-
protocol it uses
-
protocol-specific parameters
SQL*Net Easy Configuration and Oracle Network Manager
automatically provide the correct protocol specific parameters for any
protocol you use, but you must provide the appropriate values. For information
about the parameter values of a given protocol, see the section "Configuring
Addresses for Oracle Protocol Adapters" in this appendix.
| Note:
If you specify a TCP/IP address prefixed with a
0, it is assumed to be an octal number, not a decimal number. For
example, 39.223.72.44 is a decimal number, but 039.223.72.44 is an octal
number. |
CONNECT_DATA SID Keyword
SQL*Net uses the CONNECT_DATA keyword to denote the
SID of the remote database. When SQL*Net on the server side receives the
connection request, the transparent network substrate (TNS) passes the
CONNECT_DATA contents to the network listener, which identifies the desired
database.
For SQL*Net use, sample CONNECT_DATA contents can
look like:
(CONNECT_DATA =
(SID = ORCL)
| Parameter |
Description |
| CONNECT_DATA |
Indicates that application-specific data is supplied
at connect time. |
| SID |
Specifies the SID of the database server. You
must specify the SID in the CONNECT_DATA section of the connect descriptor |
Connect Descriptor Syntax
Below is the connect descriptor syntax of the TNSNAMES.ORA
file.
service_name.world =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = community_name)
(protocol adapter information)
)
)
(CONNECT_DATA =
(SID = SID)
)
)
See Table E-1, "Oracle Protocol
Adapter Parameters" in this appendix for a description of the keywords.
Specifying Service Names
All connect descriptors are assigned service
names in the TNSNAMES.ORA file. The user specifies the service name--a
single word rather than the lengthier connect descriptor--to identify the
database to which to connect. The TNSNAMES.ORA file consists of a series
of service names mapped to TNS connect descriptors.
If you are using Oracle Names, the service name
for a database must be exactly the same as the global database name defined
by the system administrator. SQL*Net limits the total length of a global
database name to 64 characters. Of these, up to eight are the DB_NAME as
defined by the database administrator, and the remainder show the service's
place in the domain hierarchy (DB_DOMAIN). The name part of the service
name can be longer than eight characters only if the DBA changes the name
of the database with a RENAME GLOBAL_NAME parameter. The total global database
name, or service name, must remain at or below 64 characters.
Alternate service names can be assigned to a database
service through the TNSNAMES.ORA file. The alternate service names can
be names you choose because you find them convenient and easy to remember.
For example, if a database is used by two different divisions of a company,
Human Resources and Finance, you can map two different service names, hr
and finance, to the database. The TNSNAMES.ORA file has three separate
entries:
-
service name that is the same as the global database name
-
two service names, mapped to the same connect descriptor
Configuring Addresses for Oracle Protocol Adapters
This section describes:
Table E-1 describes the
parameters used by the Oracle Protocol Adapters. Refer to this table for
definitions as you review the syntax examples provided throughout this
section.
Table E-1 Oracle Protocol Adapter Parameters
| Oracle Protocol Adapter |
Parameter |
Description |
| All |
COMMUNITY |
Specifies the network community of the TNS-based
application. The COMMUNITY keyword is included by Oracle Network Manager,
but its use is optional. A COMMUNITY is a group of computers using the
same protocol, such as SPX or TCP/IP. |
| All |
PROTOCOL |
Indicates the type of network on which the TNS-based
application resides. |
| All |
SID |
The name for the Oracle SID of the database server
to which to connect. The TNSNAMES.ORA file uses the same SID defined in
the server's LISTENER.ORA file. The SID for the LU6.2 protocol is not defined
in any LISTENER.ORA file. |
| Bequeath |
PROGRAM |
Identifies the Oracle7 executable. |
| Bequeath |
ARGV0 |
Identifies the Oracle SID. |
| Bequeath |
ARGS |
Identifies the source of the connection (local
client). |
| TCP/IP |
HOST and PORT |
Identifies the server and its listener port number
for TNS-based applications on the network. Ask your network administrator
for the host names and port numbers of TNS-based applications on your TCP/IP
network. |
| SPX |
SERVICE |
Defines the name of the TNS-based application
on the network. (Mandatory for server and client.) Ask your network administrator
for the service names of TNS-based applications on your network. |
| Named Pipes |
SERVER |
Indicates the name of your Oracle7 Server computer. |
| Named Pipes |
PIPE |
Indicates the pipe name by the Oracle7 Server. |
| DECnet |
NODE |
Defines the DECnet node name of the Oracle7 Server
as defined in the DECnet node database. Ask your network administrator
for the node name. |
| DECnet |
OBJECT |
Identifies the DECnet database listener as specified
in the LISTENER.ORA file. |
| NetBIOS |
NTBNAME |
Defines the name of the TNS-based application
on the network. In the case of SQL*Net, NTBNAME always identifies the name
of an Oracle7 Server listener with NetBIOS. |
| LU6.2 |
LU_NAME |
Identifies the Oracle7 Server; must be a fully
qualified name.
Available for Windows 3.1x. |
| LU6.2 |
LLU or LOCAL_LU
|
Identifies the local LU alias. This parameter
cannot be used with LLU_NAME.
Not available for Windows 3.1x. |
| LU6.2 |
LLU_NAME or LOCAL_LU_NAME |
Specifies the local LU name; must be a fully qualified
name. This parameter cannot be used with LLU. |
| LU6.2 |
MODE or MDN |
Identifies the log mode entry of the LU6.2 session;
the value is typically ORAPLU62. |
| LU6.2 |
PLU or PARTNER_LU_NAME |
Identifies the Oracle7 Server; must be a fully
qualified name.This parameter cannot be used with PLU_LA. |
| LU6.2 |
PLU_LA or PARTNER_LU_LOCAL_ALIAS |
Identifies the partner LU alias of the Oracle7
Server. This parameter cannot be used with PLU. |
| LU6.2 |
TP_NAME or TPN |
Identifies the transaction program name of the
host machine. This parameter is not required for a connection to an MVS
host. |
Specifying TCP/IP Addresses
When using the Oracle TCP/IP Protocol Adapter, specify
the address of a TNS-based application in the following format:
(ADDRESS =
(COMMUNITY = TCP.world)
(PROTOCOL = TCP)
(HOST = server_name)
(PORT = port_number)
SQL*Net Example on a TCP/IP Network
The entry below is taken from a client machine that
connects to a single Oracle7 Server named GREENWOOD on a TCP/IP network.
GREEN.world =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = TCP.world)
(PROTOCOL = TCP)
(HOST = GREENWOOD)
(PORT = 1521)
)
)
(CONNECT_DATA =
(SID = ORCL)
)
)
Specifying SPX Addresses
When using the Oracle SPX Protocol Adapter, specify
the address as follows:
(ADDRESS =
(COMMUNITY = SPX.world)
(PROTOCOL = SPX)
(SERVICE = tns_application)
SQL*Net Example on a SPX/IPX Network
The entry below is taken from a client machine that
connects to a single Oracle7 Server named GREENWOOD on an SPX/IPX network.
GREEN.world =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = SPX.world)
(PROTOCOL = SPX)
(SERVICE = ORCL_LSNR)
)
)
(CONNECT_DATA =
(SID = ORCL)
)
)
Specifying Named Pipes Addresses
When using the Oracle Named Pipes Protocol Adapter,
specify the address of a TNS-based application as follows:
(ADDRESS =
(COMMUNITY = NMP.world)
(PROTOCOL = NMP)
(SERVER = server_name)
(PIPE = pipe _name)
SQL*Net Example on a Named Pipes Network
The entry below is taken from a client machine that
connects to a single Oracle7 Server named GREENWOOD on a Named Pipes network.
GREEN.world =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = NMP.WORLD)
(PROTOCOL = NMP)
(SERVER = GREENWOOD)
(PIPE = dbpipe0)
)
)
(CONNECT_DATA =
(SID = ORCL)
)
)
Specifying DECnet Addresses
When using the Oracle DECnet Protocol Adapter, specify
the address of a TNS-based application as follows:
(ADDRESS =
(COMMUNITY = NTB.world)
(PROTOCOL = DECNet)
(NODE = DecNet_node_name)
(OBJECT = database_alias)
SQL*Net Example on a DECnet Network
The entry below is taken from a client machine that
connects to a single Oracle7 Server named ORACLE7 on a DECnet node named
ORACLE.
testdnt.sample =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = desktopdecnet.sample)
(PROTOCOL = DECnet)
(NODE = ORACLE)
(OBJECT = ORACLE733)
)
(CONNECT_DATA =
(SID = ORACLE7)
)
)
)
Specifying NetBIOS Addresses
When using the Oracle NetBIOS Protocol Adapter for
Windows 3.1x, specify the address of a TNS-based application as
follows:
(ADDRESS =
(COMMUNITY = NTB.world)
(PROTOCOL = NTB)
(NTBNAME = tb_name)
SQL*Net Example on a NetBIOS Network
The entry below is taken from a client machine that
connects to a single Oracle7 Server named GREENWOOD on a NetBIOS network.
GREEN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = NTB.world)
(PROTOCOL = NTB)
(NTBNAME = GREENWOOD)
)
)
(CONNECT_DATA =
(SID = ORCL)
)
)
Specifying LU6.2 Addresses
| Note:
LU6.2 Protocol Adapter for Windows must be configured
by using Oracle Network Manager to create the TNSNAMES.ORA file or editing
the NSD.INI file. LU6.2 Protocol Adapter for Windows NT must be configured
manually using a text editor to edit the TNSNAMES.ORA and the LISTENER.ORA
files. |
LU6.2 for Windows NT
When using the Oracle LU6.2 Protocol Adapter for Windows
NT, specify the address of a TNS-based application as follows:
(ADDRESS =
(COMMUNITY= LU62.world)
(PROTOCOL=LU62)
(TPN= tpn_name)
(MODE=ORAPLU62)
(PARTNER_LU_NAME = "partner_lu_name")
(LLU_NAME = local_lu_name)
| Note: LLU and
PARTNER_LU_LOCAL_ALIAS can be used in place of LLU_NAME and PARTNER_LU_NAME. |
| Additional Information:
See the Administrator's Guide in the Microsoft
SNA Server Documentation folder for LU6.2 setup information. |
SQL*Net Examples on an LU6.2 Network
Example to connect to an IBM MVS instance:
mvs.world = (DESCRIPTION =
(ADDRESS =
(COMMUNITY= LU62.world)
(PROTOCOL=LU62)
(TPN=RECVTP)
(MODE=ORAPLU62)
(PARTNER_LU_NAME = "ORACLE.TNSORAK")
(LLU = SENDLU)
)
(CONNECT_DATA=(SID=ORCL)
)
)
Example to connect to a Windows NT listener:
nt.world = (DESCRIPTION =
(ADDRESS =
(COMMUNITY= LU62.world)
(PROTOCOL=LU62)
(TPN=RECVTP)
(MODE=ORAPLU62)
(PARTNER_LU_NAME = "ORACLE.HQEW001")
(LLU = SENDLU)
)
(CONNECT_DATA=(SID=ORCL)
)
)
LU6.2 for Windows
LU6.2 can be specified in the TNSNAMES.ORA file or
in the NSD.INI file.
To contact an Oracle7 server using the LU6.2 protocol,
the following parameters are needed:
| Parameter |
Description |
| PLU_LA |
-
Set only if specifying an entry in the NSD.INI file.
-
Replace the LU_NAME, TP_NAME, and MODE parameters with this parameter.
|
| Logical unit (LU) partner name, LU_NAME |
-
Set when the network is configured.
-
Named automatically.
-
Specifies network location of the desired Oracle7 Server.
|
| Transaction program (TP) name, TP_NAME |
-
Set when the Oracle7 Server is configured.
-
Named automatically.
-
Specifies the executable (at the location specified by the LU name) to
establish communication;
|
| MODE |
-
Set when NS/WIN is configured on the client.
-
Named by the network administrator.
-
Specifies the quality of service.
|
When using the Oracle LU6.2 Protocol Adapter for Windows
3.1x, specify the address of a TNS-based application as follows:
(ADDRESS =
(COMMUNITY= LU62.world)
(PROTOCOL = LU62)
(LU_NAME = lu_name)
(TP_NAME = tpn_name)
(MODE = mode_name)
When using the NSD.INI file (for NS/WIN), specify
the TNS-based application as follows:
If you choose the NSD.INI file (for NS/WIN), the
TP_NAME, LU_NAME, and MODE are taken from the PLU_LA alias, and your TNSNAMES.ORA
entry is simpler:
(ADDRESS =
(COMMUNITY= LU62.world)
(PROTOCOL = LU6.2)
(PLU_LA = partner_lu_alias)
TP_NAME, LU_NAME, and MODE are specified in the NSD.INI
file.
Specifying Bequeath Addresses
When you configure TNSNAMES.ORA and specify the Oracle
Bequeath Protocol Adapter, the following address appears in TNSNAMES.ORA:
(ADDRESS =
(COMMUNITY = beq.world)
(PROTOCOL = BEQ)
(PROGRAM = oracle73)
(ARGV0 = oracle73SID)
(ARGS = `(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))')
| Note:
When connecting with the Bequeath Protocol Adapter
on a local Windows NT server, you only need to specify the SID. Use the
default entry of local host for the service name, since the Windows NT
server is a local machine. |
SQL*Net Example on a Bequeath Network
The entry below is taken from a server machine that
connects to a single Oracle7 Server named GREENWOOD on a Bequeath network.
GREEN.world =
(DESCRIPTION =
(ADDRESS_LIST =
(COMMUNITY = beq.world)
(PROTOCOL = BEQ)
(PROGRAM = oracle73)
(ARGV0 = oracle73SID)
(ARGS = `(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))')
)
)
(CONNECT_DATA =
(SID = ORCL)
)
)
Understanding the SQLNET.ORA File
The SQLNET.ORA file is used by all clients and the
server on the network. The SQLNET.ORA file contains information about Oracle
Names such as the:
-
default domain for service names stored in Oracle Names
-
list of preferred Names Servers
It can also contain optional logging, tracing, and
security parameters.
| Note: The SQLNET.ORA
file is automatically installed on the server and the clients in ORACLE_HOME\NETWORK\ADMIN. |
A sample file is shown in Figure
E-2:
Figure E-2 SQLNET.ORA Configuration File
################
# Filename......: sqlnet.ora
# Name..........: TCP.world
# Date..........: 04-DEC-96 13:50:40
################
AUTOMATIC_IPC = OFF <---set this to OFF if you do not want to use IPC
TRACE_LEVEL_CLIENT = OFF <---set this to 16 if tracing is required
names.directory_path = (TNSNAMES)
names.default_domain = world
name.default_zone = world
This section covers the following SQLNET.ORA configuration
issues:
Specifying Dead Connection Detection
The optional server parameter, SQLNET.EXPIRE_TIME,
determines how often the listener sends a probe to verify that a client-server
connection is still active. If a client is abnormally terminated, a connection
remains open indefinitely unless identified and closed by the system. If
you specify this parameter, the listener sends a probe periodically to
determine whether there is an invalid connection to terminate. If the listener
finds a dead connection, or a connection no longer in use, it returns an
error, causing the server process to exit. This parameter must be set in
the SQLNET.ORA file on the server.
Specify this parameter in the Connection Expire
Time field of the Client Profile property sheet of Oracle Network Manager.
Enter the time, in minutes, between probes for a dead connection. The range
of possible values is from one to a very large number. However, a value
of approximately 10 is recommended.
| Note:
The time set in this parameter is not necessarily
the amount of time a dead connection remains. This parameter sets the time
between probes for dead connections. Depending on the underlying protocol,
shutting down a dead process can take longer. |
Dead connection detection has costs associated with
it:
-
Additional network traffic is generated to probe for dead connections.
A probe packet is very small, but one is sent on each connection at the
interval specified in the SQLNET.EXPIRE_TIME parameter in the SQLNET.ORA
file.
-
When dead connection detection is enabled, the Oracle7 Server needs to
do additional processing to distinguish the connection probing event from
other events. You can test the performance of your application with or
without the dead connection detection feature enabled.
-
For some protocols, the generic SQL*Net dead connection detection feature
is no better than the native mechanism available in the underlying transport
protocol. In that case, it is not necessary to enable it. For example,
the native keep alive mechanism provided by the TCP/IP stack is enabled
by default, and it can be tuned by changing registry values, as explained
in operating system documentation.
In short, evaluate carefully whether you benefit from
enabling the dead connection detection feature. Turn it on only if necessary.
Using SQLNET.ORA Logging and Tracing Parameters
The following SQLNET.ORA logging and tracing parameters
are available:
| Parameter |
Description |
| LOG_FILE_CLIENT
LOG_FILE_SERVER |
Sets the name of the log file. By default the
log name is SQLNET.LOG. |
| LOG_DIRECTORY_CLIENT
LOG_DIRECTORY_SERVER |
Establishes the destination directory for log
files. By default, the client directory is the current working directory.
By default the server directory is ORACLE_HOME\NETWORK\LOG. |
| TRACE_LEVEL_CLIENT
TRACE_LEVEL_SERVER |
Indicates the level of detail the trace facility
records. The trace level value can either be a value within the range of
0 to 16 (where 0 is no tracing and 16 represents the maximum amount of
tracing) or a value of OFF, ADMIN, USER, or SUPPORT.
-
OFF (equivalent to 0) provides no tracing.
-
USER (equivalent to 4) traces to identify user-induced error conditions.
-
ADMIN (equivalent to 6) traces to identify installation-specific problems.
-
SUPPORT (equivalent to 16) provides trace information for troubleshooting
information for support.
|
| TRACE_FILE_CLIENT
TRACE_FILE_SERVER |
Establishes the name of the file to which trace
information is written. By default, the client trace file name is SQLNET.TRC.
By default the server trace file is SERVERthread_id.TRC. |
| TRACE_DIRECTORY_CLIENT
TRACE_DIRECTORY_SERVER |
Sets the directory where the trace file is placed.
By default, the client directory is the current working directory. By default,
the server directory is ORACLE_HOME\NETWORK\TRACE. |
| TRACE_UNIQUE_CLIENT |
This parameter determines whether or not a unique
trace file is created for each client. By default, the value is OFF. The
same trace file name is used for every client. If the value is OFF, when
a new trace file is created for a client, it overwrites the existing file.
If the value is set to ON, a thread identifier is appended to the name
of each trace file generated so that several can coexist.
This parameter creates unique trace files named
SQLNETthread_id.TRC. |
All errors that occur in SQL*Net are written to log
files, while detailed sequences of events as they happen are written to
trace files. Trace files provide more information than log files.
You can also manually add the following optional
tracing parameters for the TNSPING utility to SQLNET.ORA. TNSPING determines
whether or not a service (such as a database, an Oracle Names Server, or
other TNS services) on a SQL*Net network can be successfully reached.
-
TNSPING.TRACE_LEVEL
-
TNSPING.TRACE_DIRECTORY
Understanding Default Domains
The NAMES.DEFAULT_DOMAIN parameter indicates the domain
from which the client most often requests names. When this parameter is
set, the domain name is automatically appended to the service name.
Understanding Client Parameters for Use with Oracle Names Server
If you use Oracle Names Server without DDO, another
parameter, NAMES.PREFERRED_SERVERS, is required. This parameter includes
one or more addresses of the Names servers in the order the client prefers
to use them.
| Additional Information:
Several optional Oracle Names Server tracing parameters
can also appear; they are described in the Oracle
Names Administrator's Guide. Use Oracle Network Manager to create
these parameters. |
Understanding the IPC Parameter
The IPC interprocess communication parameter, AUTOMATIC_IPC,
determines if SQL*Net attempts to connect to a database using IPC or through
the network first. If the parameter is set to ON, SQL*Net tries to connect
using a service name as an IPC key. If it fails, it resolves the service
name (using the TNSNAMES.ORA file or an Oracle Names Server) and uses it
for connection. If the parameter is set to OFF, SQL*Net does not look for
an IPC address and goes directly to the network.
To modify this parameter, use Oracle Network Manager
(if SQLNET.ORA was originally configured with it), an ASCII editor (such
as Notepad), or the SQLNET.ORA Editor for Windows 3.1x.
Understanding Authentication, Encryption, and Checksumming Parameters
Authentication, data encryption, and checksumming
parameters ensure secure transmission of data over networks. Authentication
is available with or without ANO. Encryption and checksumming parameters
are only available with ANO.
Understanding the LISTENER.ORA File
The LISTENER.ORA file is the configuration file for
the listener. It resides on the server and defines:
-
the listener address
-
the SID of the database for which it listened
-
parameters that influence the listener's behavior, including tracing and
logging
A sample file is shown in Figure
E-3:
| Note: The LISTENER.ORA
file is automatically installed on the server in ORACLE_HOME\NETWORK\ADMIN. |
Figure E-3 LISTENER.ORA Configuration File
###########
# FILENAME: listener.ora
# NAME....: Sever name
# Date..........: 04-DEC-96 13:50:40
###########
LISTENER =
(ADDRESS_LIST =
(ADDRESS=
(PROTOCOL=IPC) <---IPC is the internal protocol
(KEY= service_name) <---automatically added, but not necessary
)
(ADDRESS=
(PROTOCOL=IPC)
(KEY =SID)
)
(ADDRESS =
(COMMUNITY = TCP.world)
(PROTOCOL = TCP)
(HOST = host_name) <---or, use the IP address of server
(PORT = 1521)
)
)
STARTUP_WAIT_TIME_LISTENER = 0
CONNECT_TIMEOUT_LISTENER = 10
TRACE_LEVEL_LISTENER = ADMIN
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = SID) <---Database system identifier, default is ORCL
)
)
PASSWORDS_LISTENER = (oracle)
This section covers the following LISTENER.ORA configuration
issues:
Defining the Listener Name
You can create connections to multiple databases in
two ways, using one or multiple network listeners:
-
you specifically configure one network listener to multiple databases
-
you configure multiple network listeners, each for a specific database.
All the listeners on a single machine share one LISTENER.ORA file.
The listener name can be any easy-to-use name. The
default listener name is LISTENER, which is the recommended name in a standard
installation that requires only one listener on a machine. The listener
name must be unique on the machine running Oracle7. If you have more than
one listener on a machine, each requires a unique name. The TURTLE node,
for example, might have three listeners with the names:
-
LSNR1_TURTLE
-
LSNR2_TURTLE
-
LSNR3_TURTLE
Defining the Listener Address
The listener usually listens both for internal connection
requests and for connection requests from across the network.
IPC Addresses for the Listener (Windows NT Only)
The listener listens for IPC calls if IPC addresses
are in the LISTENER.ORA file. Oracle Network Manager generates the IPC
entries automatically, without your input.
The IPC address format, which is the same across
platforms, is as follows:
(ADDRESS=
(PROTOCOL=IPC)
(KEY=string)
Oracle Network Manager and SQL*Net Easy Configuration
create two IPC addresses for each database for which a listener queries.
In one, the key value is equal to the service name. This IPC address is
used for connections from applications on the same node. Service names
are described in the section "Understanding the
Configuration Files" in this appendix. In the other IPC address, the
key value is equal to the database SID.
| Note:
If the service name is the same as the SID, only
one IPC address is needed, and Oracle Network Manager generates only one
IPC address. |
LU6.2 Addresses
The listener must have a fully qualified local LU
name rather than a partner LU name (that may be specified in the TNSNAMES.ORA).
Below is a sample LU6.2 address:
(ADDRESS=
(PROTOCOL= LU62)
(TPN = RECVTP)
(LLU_NAME = "ORACLE.HQEW001")
(MODE = ORAPLU62)
)
Describing the Databases on the Listener
The LISTENER.ORA file describes the database SIDs
for which the listener queries. These are the same SIDs listed in the client's
TNSNAMES.ORA file. LISTENER.ORA is made up of keyword-value pairs.
SID_LIST_listener_name=
(SID_LIST =
(SID_DESC =
(SID_NAME = SID)
)
)
The SID is the Oracle SID of the database server.
(SID_NAME = db2)
)
)
Defining Listener Prespawned Dedicated Server Processes
This release does not support prespawned dedicated
server processes by the listener. Do not include the following parameters
in each SID_DESC of the LISTENER.ORA file:
-
PRESPAWN_MAX
-
PROTOCOL
-
POOL_SIZE
-
TIMEOUT
Using LISTENER.ORA Control Parameters
The following parameters control the behavior of the
listener:
| Parameter |
Description |
| LOG_FILE_listener_name |
Sets the name of the log file for the listener.
By default, the log name is SQLNET.LOG. |
| LOG_DIRECTORY_listener_name |
Establishes the destination directory for the
log file that is automatically generated for listener events. By default,
the directory is ORACLE_HOME\NETWORK\ADMIN\LOG. |
| PASSWORDS-_listener_name |
Allows one or more passwords. If this optional
parameter specifies one or more passwords, then the use of one of these
passwords is required to perform DBA tasks against the listener using the
Listener Control Utility. |
| STARTUP_WAITTIME_--listener_name |
Sets the number of seconds that the listener sleeps
before responding to the first listener control status command. |
| TRACE_LEVEL_listener_name |
Indicates the level of detail the trace facility
records. The trace level value can either be a value within the range of
0 to 16 (where 0 is no tracing and 16 represents the maximum amount of
tracing) or a value of OFF, ADMIN, USER, or SUPPORT.
-
OFF (equivalent to 0) provides no tracing.
-
USER (equivalent to 4) traces to identify user-induced error conditions.
-
ADMIN (equivalent to 6) traces to identify installation-specific problems.
-
SUPPORT (equivalent to 16) provides trace information for troubleshooting
information for support.
|
| TRACE_FILE__--<listener_name> |
Establishes the name of the file to which trace
information is written. |
| TRACE_DIRECTORY__--<listener_name> |
Sets the directory where the trace file is placed. |
| Additional Information: See
the Oracle Network Products Messages Manual for valid log and trace
parameters values. |
Using Oracle Names
Clients do no need a TNSNAMES.ORA file if an Oracle
Names Server is used. If the TNSNAMES.ORA is created, the client may use
it to resolve the service name before resolving it through the Names Servers.
A SQL*Net server requires the following entries in the LISTENER.ORA file
for a listener to register itself as a service to a well-known Oracle Names
Server:
SID_LIST_listener_name=
(SID_LIST =
(SID_DESC =
(SID_NAME = ORCL)
(GLOBAL_DBNAME = ORCL.world)
)
)
where listener_name is the name of the listener.
LISTENER is the name of the default listener.
Additionally, the Dynamic Discover Option (DDO)
allows databases to automatically register with Oracle Names Servers and
allows clients to automatically find Oracle Names Servers. DDO requires
the following entry in the LISTENER.ORA file:
USE_PLUG_AND_PLAY_listener_name=ON
| GLOBAL_DBNAME |
This is the name with which the listener registers
the database instance with an Oracle Names Server and the name by which
the Oracle Names Server identifies a database.
When clients request the connect information for
a database from an Oracle Names Server, this is the alias they use.
The domain is defined in the SQLNET.ORA
file by the NAMES.DEFAULT_DOMAIN parameter. The default is set to WORLD. |
| USE_PLUG_AND_PLAY |
Instructs the listener to find and register with
a well-known Oracle Names Server.
When the listener starts, it looks for hosts with
the well-known host names, tries to gather connection information from
the Oracle Names Server, and registers its SID(s) with it. |
