| Understanding SQL*Net |  Library |
 Product |
 Contents |
 Index |
| Understanding SQL*Net | Library |
Product |
Contents |
Index |
This appendix provides a brief overview of all the configuration files for the Oracle network products, then describes the files for SQL*Net in detail. These files are:
Configuration files for the related Oracle networking products, the MultiProtocol Interchange and Oracle Names, are not described in detail here. They are discussed in detail in the Oracle MultiProtocol Interchange Administrator's Guide and the Oracle Names Administrator's Guide, respectively.
Configuration files for the Oracle Server, such as INIT.ORA, are described in detail in the Oracle7 Server Administrator's Guide.
This file contains a list of the service names and addresses of network destinations. A client (or a server that is part of a distributed database) needs this file to tell it where it can make connections.
Note: This file is not necessary if Oracle Names is used.
Note: This file should be generated and modified by Oracle Network Manager. Do not edit it manually.
TNSNAV.ORA
This file is used only in a network that includes one or more Oracle MultiProtocol Interchanges. It lists the communities of which the client (or server) is a member and includes the names and addresses of the Interchanges available in local communities as a first hop toward destinations in other communities.
Note: This file should be generated and modified by the Oracle Network Manager. Do not edit it manually.
SQLNET.ORA
This file contains optional diagnostic parameters, client information about Oracle Names, and may contain other optional parameters such as native naming or security (encryption and checksumming) parameters.
Note: SQLNET.ORA may contain node-specific parameters. Unless you are using Oracle Names and the Dynamic Discovery Option, you should create it with Network Manager. You may edit the SQLNET.ORA file for an individual client by using the SQLNET.ORA Editor, which is described in the Oracle Network Products Troubleshooting Guide.
In addition, clients and servers on some protocols may require PROTOCOL.ORA, which you must create manually.
PROTOCOL.ORA
This file contains protocol- and platform-specific options for protocols that require them, such as Async and APPC/LU6.2.
In addition to the client configuration files described above, each server machine needs a LISTENER.ORA file to identify and control the behavior of the listeners that listen for the databases on the machine.
LISTENER.ORA
This file includes service names and addresses of all listeners on a machine, the system identifiers (SIDs) of the databases they listen for, and various control parameters used by the Listener Control Utility.
Note:
Unless you are using Oracle Names and the Dynamic Discovery Option, this file should be generated and modified by the Oracle Network Manager. You should not edit it manually.
Note: LISTENER.ORA and TNSNAMES.ORA contain some similar information. 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. Figure A - 1 shows the similarities between these files for a single server.
Figure A - 1. Similarities Between TNSNAMES.ORA and LISTENER.ORA
This file contains a list of the communities in the network and the relative cost of traversing them, and the names and addresses of all the Interchanges in the network. This file provides an overview of the layout of the network for all the Interchanges.
TNSNAV.ORA
This file describes the communities of each individual Interchange on the network.
INTCHG.ORA
This file provides both required and optional parameters that control the behavior of each Interchange.
Note: These files should be generated and modified through Oracle Network Manager. They should not be edited by hand.
For detailed information about the configuration files for the Interchange, see the Oracle MultiProtocol Interchange Administrator's Guide.
For more information about the NAMES.ORA file for the Names Server, see Chapter 6 in the Oracle Names Administrator's Guide.
NAMES.ORA
Unless you are using the Dynamic Discovery Option, every node running a Names Server must have a NAMES.ORA file. NAMES.ORA contains control parameters for the Names Server and points the Names Server to the database where the network definition is stored.
Note: This file should be generated and modified by Oracle Network Manager. Do not edit it manually.
SQLNET.ORA
This file contains client information about Oracle Names such as the default domain for service names stored in Oracle Names, and lists preferred Oracle Names Servers. It may also contain optional logging and tracing (diagnostic), native naming, and security (encryption, checksumming, and authentication) parameters.
Note: You must generate the SNMP.ORA file with Network Manager.
For detailed information about the Oracle SNMP Support feature and a description of its Management Information Base (MIB) variables, see the Oracle SNMP Support Reference Guide.
The listener name must be unique to the machine. If you have more than one listener on a machine, each must have a unique name. The TURTLE node, for example, might have three listeners with the names LSNR1_TURTLE.WORLD, LSNR2_TURTLE.WORLD, and LSNR3_TURTLE.WORLD.
The IPC address format, which is the same across platforms, is as follows:
(ADDRESS= (PROTOCOL=IPC) (KEY=string))
Network Manager creates two IPC addresses for each database for which a listener listens. In one, the key value is equal to the service name. This IPC address is used for connections from other applications on the same node. Service names are described later in this chapter, in the section "TNSNAMES.ORA." In the other IPC address, the key value is equal to the database system identifier (SID), which is described in the next section. This IPC address is used by the database dispatcher to identify the listener.
Note: If the service name is the same as the SID, only one IPC address is needed, and only one is generated by Network Manager.
If the network includes Oracle Names, and if you create an alias (a second service name) for the address using Network Manager, an IPC address using the alias as a key is included in LISTENER.ORA.
The Network Manager automatically provides the correct protocol specific parameters for any protocol you use, but you must provide the appropriate values. For information about the values for the parameters for a given protocol, see the Oracle operating system specific documentation for your platform.
LISTENER_mike.world=(ADDRESS_LIST= (ADDRESS= (PROTOCOL=IPC) (KEY=prod.world) ) (ADDRESS= (PROTOCOL=IPC) (KEY=db1) ) (ADDRESS= (PROTOCOL=tcp) (HOST=mike.world) (PORT=1521) ) )
SID_LIST_listener_name=[(SID_LIST=] (SID_DESC (GLOBAL_DBNAME=global_dbname) (SID_NAME=SID) (OS_Oracle_ environment=db_location) ) [(SID_DESC= (GLOBAL_DBNAME=global_dbname) (SID_NAME=SID) (OS_Oracle_environment=db_location) )] [)]
The GLOBAL_DBNAME is the name and domain of the database as given in the database initialization parameter file. The SID is the Oracle system ID of the database server. In the next keyword-value pair, the keyword is operating system specific: it is indicated here as the variable OS Oracle environment. Its value, indicated here as db_location, is the specific location of the database executables.
An example typical of the UNIX operating system follows:
(ORACLE_HOME=/usr/oracle)
An example from a VMS environment follows:
(PROGRAM='disk$:[oracle.rdbms]orasrv.com')
An example for OS/2 might be:
(PROGRAM=ORACLE7)
An example of a complete SID_LIST_listener_name section on a UNIX operating system follows:
SID_LIST_LISTENER=(SID_LIST= (SID_DESC= (GLOBAL_DBNAME=hr) (SID_NAME=db1) (ORACLE_HOME=/usr/oracle) ) (SID_DESC= (GLOBAL_DBNAME=prod) (SID_NAME=db3) (ORACLE_HOME=/usr/oracle) ) )
Note that a listener can listen for more than one database on a machine. However, you may create different listeners for the databases if you wish. All the listeners on a single machine share one LISTENER.ORA file.
PRESPAWN_ MAX
The maximum number of prespawned dedicated server processes the listener will create. This number must be at least as many as the sum of the pool size for each protocol. For greatest efficiency, Oracle Corporation recommends a large value, so that prespawned dedicated server processes are always available for new connection requests.
The protocol on which the listener creates prespawned dedicated server processes. If a listener listens on more than one community, you can choose whether to have pre-spawned servers on any or all of them.
The number of unused prespawned dedicated server processes for the listener to maintain on the selected protocol. Choose a number that is greater than 0 but no greater than the PRESPAWN_MAXIMUM value. The value should be about what you expect the average number of connections to be at any given time.
Time in minutes that an inactive prespawned dedicated server process waits for the next connection. The value should be greater than 0. (A value of 0 will allow an inactive shadow process to continue indefinitely, thus wasting machine resources.) For greatest efficiency, Oracle Corporation recommends a short Time Out value. The time out is activated only after a prespawned dedicated server process has carried a connection and been disconnected. In other words, prespawned dedicated server processes that are waiting for their first connection do not time out.
Here is an example of a SID_DESC section of LISTENER.ORA that includes information about prespawned dedicated server processes:
(SID_LIST = (SID_DESC = (GLOBAL_DBNAME = sales.acme.com (SID_NAME = DB1) (ORACLE_HOME = /usr/bin/oracle) (PRESPAWN_MAX = 99) (PRESPAWN_LIST= (PRESPAWN_DESC= (PROTOCOL=TCP) (POOL_SIZE=10) (TIMEOUT = 2) ) ) ) )
PASSWORDS_listener_name=(password[,...password])
This optional parameter allows one or more passwords. If this parameter is specified with one or more passwords, then the use of one of these passwords is required to perform certain DBA tasks against the listener using the Listener Control Utility. See "Using the Listener Control Utility"![[*]](jump.gif)
If this parameter is not included in the file, then anyone can access the Listener Control Utility to stop or alter the listener.
You may choose to have Network Manager encrypt the password in this file. If you choose to have the password encrypted, unauthorized people cannot see it in the LISTENER.ORA file and use it to manipulate the listener. However, if you want the password to be encrypted, you can enter only one password. The default is to encrypt the password.
If you do not care about password encryption, you can enter more than one password. If more than one password is entered, all of them must be surrounded by parentheses. For example:
PASSWORDS_LISTENER=(super32, sly51)
Network Manager creates the parentheses automatically.
STARTUP_WAIT_TIME_listener_name=number
This parameter sets the number of seconds that the listener sleeps before responding to the first listener control status command. This feature assures that a listener with a slow protocol will have had time to start up before responding to a status request. Default is 0.
For example, in the case of SPX, if you use the Listener Control Utility to request a STATUS immediately after the START command, and if this parameter is set to 0, you will get an error stack indicating that the listener is not available. If this parameter is set to 2, however, the Listener Control Utility will wait briefly, and the STATUS command will return a message showing that the listener is available and listening. (For information about using the Listener Control Utility, see Chapter 5.)
CONNECT_TIMEOUT_listener_name=number
This parameter sets the number of seconds that the listener waits to get a valid SQL*Net version 2 connection request after a connection has been started. The listener drops the connection if the timeout is reached. Default is 10; if set to 0, it will wait forever.
TRACE_LEVEL_listener_name=OFF|USER|ADMIN
This parameter indicates the level of detail the trace facility records for listener events. Choices are OFF, USER,or ADMIN. Default is OFF. USER provides a limited level of tracing; ADMIN provides a more detailed trace.
TRACE_DIRECTORY_listener_name=path_to_trace_directory
This parameter sets the directory where the trace file is placed. Default is operating system specific. On UNIX, for example, it is $ORACLE_HOME/network/trace.
TRACE_FILE_listener_name=trace_filename
This parameter establishes the name of the file to which trace information is written. Default is listener_name.trc on most platforms.
LOG_DIRECTORY_listener_name=path_to_log_directory
This parameter indicates the directory in which to find the log file that is automatically generated for listener events. Default is operating system specific. On UNIX, for example, it is $ORACLE_HOME/network/log.
LOG_FILE_listener_name=log_filename
This parameter sets the name of the log file for the listener. Default is listener_name.log on most platforms.
LISTENER_mike.world=(ADDRESS_LIST= (ADDRESS= (PROTOCOL=IPC) (KEY=prod.world) ) (ADDRESS= (PROTOCOL=IPC) (KEY=db1) ) (ADDRESS= (PROTOCOL=tcp) (HOST=mike.world) (PORT=1521) ) ) SID_LIST_LISTENER= (SID_DESC= GLOBAL_DBNAME=sales.acme.com) (SID_NAME=db1) (ORACLE_HOME=/usr/oracle7) ) #The following parameters have default values PASSWORDS_LISTENER= STARTUP_WAIT_TIME_LISTENER=0 CONNECT_TIMEOUT_LISTENER=10 TRACE_LEVEL_LISTENER=OFF TRACE_DIRECTORY_LISTENER=/usr/prod/oracle7/network/trace TRACE FILE_LISTENER=listener.trc LOG_DIRECTORY_LISTENER=/usr/prod/oracle7/network/log LOG_FILE_LISTENER=listener.log
Note that if the listener were on a different operating system, the default file and path names for tracing and logging might be different. See your Oracle operating system-specific documentation for further information.
The parameters are:
names.default_domain = default_domain
names.preferred_servers =
(ADDRESS_LIST =
(ADDRESS =
( names_server_address)
)
)An example follows:
names.default_domain = world
names.preferred_servers =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = tcpcom)
(PROTOCOL = TCP)
(Host = vance.world)
(Port = 1522)
)
)For more information about using Oracle Names with the Dynamic Discovery Option, see the Oracle Names Administrator's Guide.
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. See "Global Naming Issues" in Chapter 2 of Oracle7 Server Distributed Systems, Volume I for more information on creating a global database name.
The service name for an Interchange is the name of the Interchange or its Connection Manager component. Typically, the Interchange and the Connection Manager are referred to by the same name.
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=V7PROD) )
CONNECT_DATA is a protocol independent keyword indicating that application-specific data will be supplied at connect time, and SID specifies the Oracle System ID of the database server. You must specify the SID in the CONNECT DATA section of the connect descriptor.
With this release of SQL*Net, the CONNECT_DATA section must also include the global database name of the database. In most instances the global database name is the same as the service name. However, if you have a replicated database, you may have assigned a single service name that maps to more than one database name.
There is no CONNECT_DATA section in the connect descriptor of an Interchange.
Figure A - 2. SQL*Net Connect Descriptor
The following TNSNAMES.ORA entry maps the service name NY_FIN to the connect descriptor:
NY_FIN.FIN.HQ.ACME = (DESCRIPTION= (ADDRESS= (COMMUNITY=DECCOM.FIN.HQ.ACME) (PROTOCOL=DECNET) (NODE=NY_VAX.FIN.HQ.ACME) (OBJECT=LSNR) ) (CONNECT_DATA= (SID=DB1) (GLOBAL_NAME=NY_FIN.FIN.HQ.ACME) ) )
A user who wished to access the database would use NY_FIN to identify the appropriate connect descriptor. For example:
SQLPLUS SCOTT/TIGER@NY_FIN
This example assumes that NY_FIN is in the user's default domain. If it is not, the whole service name (NY_FIN.FIN.HQ.ACME) would need to be used.
A local TNSNAMES.ORA file does not replace the system file, but exists in addition to it. For example, if a developer creates a database which is not generally accessible to other users, he might want to create a private TNSNAMES.ORA file with a simple service name mapped to its connect descriptor. By creating his own TNSNAMES.ORA file, the developer can have the convenience of using a service name without having to go through the system administrator.
Note: For more specific information about the name, location, and use of the TNSNAMES.ORA file on your operating system, refer to your Oracle operating system-specific manual.
Note: The administrator does not need to add or change any parameters in the database parameter file for dedicated servers.
MTS_MULTIPLE_LISTENERS=TRUE
Note: Unless MTS_MULTIPLE_LISTENERS=TRUE is included, listener load balancing is not enabled.
If there is a single listener for each multi-threaded server, each address of the single listener is listed on a separate line, as follows:
MTS_LISTENER_ADDRESS= address
MTS_LISTENER_ADDRESS= address
[MTS_LISTENER_ADDRESS= address]
...
If multiple listeners are enabled, each listener must be on a separate line. If a listener has multiple addresses, each one is listed within an address list, as follows:
MTS_LISTENER_ADDRESS=(ADDRESS_LIST=(ADDRESS=(address) (ADDRESS=(address)))
MTS_LISTENER_ADDRESS=(ADDRESS_LIST=(ADDRESS=(address) (ADDRESS=(address)))
Note: If you decide to change back so that each dispatcher registers with only one listener, you must remove the ADDRESS_LIST keyword and place alternative addresses for the same listener on separate lines:
MTS_LISTENER_ADDRESS=address MTS_LISTENER_ADDRESS=address
service_name =
(DESCRIPTION_LIST=
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=address)
(ADDRESS=address))
(CONNECT_DATA=(SID=sid)
(GLOBAL_NAME=global_dbname)))
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=address)
(ADDRESS=address))
(CONNECT_DATA=(SID=sid)
(GLOBAL_NAME=global_dbname)))
[(CONNECT_DATA =(SID=sid)(GLOBAL_NAME=global_dbname))])The global name is a concatenation of the db_name and the db_domain from the INIT.ORA file.
Note: The old format for TNSNAMES.ORA entries continues to work only for those databases that have only one listener.
emp=(DESCRIPTION_LIST=
(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(COMMUNITY=DECCOM.WORLD)(PROTOCOL=DECNET)
(NODE=NY_VAX)(OBJECT=LSNR))
(ADDRESS=(COMMUNITY=TCPCOM.WORLD)(PROTOCOL=TCP)
(HOST=NY_VAX)(PORT=1526))))
(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(COMMUNITY=DECCOM.WORLD)(PROTOCOL=DECNET)
(NODE=NY_SEQ)(OBJECT=LSNR))
(ADDRESS=(COMMUNITY=TCPCOM.WORLD)(PROTOCOL=TCP)
(HOST=NY_SEQ)(PORT=1526))))
(CONNECT_DATA=(SID=db1)(GLOBAL_NAME=emp.world)))In this example, there are two listeners for the database, on two different nodes, each listening on two different protocols. This example matches the example illustrated in Figure 2 - 4.
If there are replicated databases that are equivalent, create a service name that maps to more than one SID and global database name. For example, the following portion of a TNSNAMES.ORA file is for a replicated server with two listeners. The example matches that shown in Figure 2 - 5.
TNSNAMES.ORA Example for Equivalent Databases
twinemp=(DESCRIPTION_LIST=
(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(COMMUNITY=DECCOM.WORLD)
(PROTOCOL=DECNET)
(NODE=NY_VAX)(OBJECT=LSNR))
(ADDRESS=(COMMUNITY=TCPCOM.WORLD)
(PROTOCOL=TCP)
(HOST=NY_VAX)(PORT=1526)))
(CONNECT_DATA=(SID=db1)(GLOBAL_NAME=emp.world)))
(DESCRIPTION=(ADDRESS_LIST=
(ADDRESS=(COMMUNITY=DECCOM.WORLD)
(PROTOCOL=DECNET)(NODE=NY_SEQ)
(OBJECT=LSNR))
(ADDRESS=(COMMUNITY=TCPCOM.WORLD)
(PROTOCOL=TCP)(HOST=NY_SEQ)
(PORT=1526)))
(CONNECT_DATA=(SID=db2)(GLOBAL_NAME=hr.world))))
Note: The time set in this parameter is not necessarily the amount of time a dead connection will remain. This parameter sets the time between probes for dead connections. Depending on the underlying protocol, it may be somewhat longer before a dead process is shut down.
Dead connection detection has some costs associated with it.
You can add the following optional tracing parameters for the TNSPING utility to SQLNET.ORA using the SQLNET.ORA Editor. (They produce messages similar to the SQL*Net trace parameters mentioned above.)
NAMES.DIRECTORY_PATH = (TNSNAMES, ONAMES)
AUTOMATIC_IPC=OFF
Without this parameter, the default is for a connection to look for an IPC address.
USE_DEDICATED_SERVER=ON
The default is OFF.
Note: For further information about dedicated server processes and the multi-threaded server, see Chapter 2 in the Oracle7 Server Distributed Systems, Volume I.
It is important that any manually-edited entries be made in SQLNET.ORA after the file is distributed to the destination. Because this file is generated to be common to all clients with the same client profile, changing it for specific nodes or a specific operating system's file structure before moving it to other nodes may have unintended results.
DISABLE_OOB=OFF|ON
Currently, you need to add this parameter manually to SQLNET.ORA; you cannot configure it through Network Manager.
TRACE_LEVEL_CLIENT = OFF sqlnet.expire_time = names.default_domain = world name.default_zone = world
The NAMES.DEFAULT_DOMAIN parameter is created whether or not Oracle Names is part of the network. Oracle Network Manager puts a comparable parameter, NAME.DEFAULT_ZONE, into the file for backward compatibility with an earlier version of SQL*Net.
The following SQLNET.ORA file is for a client in a network that includes Oracle Names. A value has been included for SQLNET.EXPIRE_TIME.
TRACE_LEVEL_CLIENT = OFF
sqlnet.expire_time = 10
names.default_domain = world
name.default_zone = world
names.preferred_servers =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = tcpcom)
(PROTOCOL = TCP)
(Host = vance.world)
(Port = 1522)
)
)
name.preferred_servers =
(ADDRESS_LIST =
(ADDRESS =
(COMMUNITY = tcpcom)
(PROTOCOL = TCP)
(Host = vance.world)
(Port = 1522)
)
)
This file includes a parameter that shows the client's preferred Names Server. As in the previous sample, there are two different versions of this parameter to provide backward compatibility with an earlier version of the product. Oracle Network Manager creates these parameters automatically.
For example, consider the partial TNSNAMES.ORA, LISTENER.ORA, and PROTOCOL.ORA files for LU6.2 shown in Figure A - 3.
Figure A - 3. LOCAL_LOOKUP and PROTOCOL.ORA
The global information address information for the server HORNET.WORLD is contained in the TNSNAMES.ORA and LISTENER.ORA files. This information can be used by any client in the network. The PROTOCOL.ORA entry contains additional address parameters needed for a specific node to reach HORNET.WORLD.
See the Oracle operating system specific documentation for your platform for further information.
To activate Validnode checking, the following parameter must be entered in PROTOCOL.ORA:
protocol.validnode_checking = yes
For example, for the TCP/IP protocol, the parameter would be:
tcp.validnode_checking = yes
The default is for Validnode checking to be off.
Note: The DECnet protocol does not currently support Validnode checking.
The access list for Validnode checking can take two forms: an INVITED_NODES list and an EXCLUDED_NODES list. The two lists are mutually exclusive. If both are present, the INVITED_NODES list takes precedence over the EXCLUDED_NODES list.
Sample Access List
The following is a sample access list in PROTOCOL.ORA for the TCP/IP protocol:
tcp.invited_nodes = (drummer.us.com, 139.185.5.73 139.185.5.111)
This list grants access to the three nodes listed, and excludes all others.
An alternative way of limiting connection requests is to exclude specific nodes. The following list provides access to all nodes except those listed:
tcp.excluded_nodes = (drummer.us.com, 139.185.5.73 139.185.5.111)
Note: Not all protocols and operating systems support Validnode verification. See the operating system-specific documentation for your platform for further details.
If a node has more than one service, the SNMP.ORA file includes information for all of them. For example, the SNMP.ORA file for a particular node might contain information so that an Interchange and a Names Server can respond to SNMP queries from an SNMP-based network management system. Or, an SNMP.ORA file on a particular node might include parameters for a listener and a database only.
The sample SNMP.ORA file in this section enables SNMP support for five services including a listener, two databases (HR.WORLD and SALES.WORLD), an Interchange and a Names Server. These five services are configured to respond to queries from an SNMP-based network management system.
SNMP.VISIBLESERVICES=(svc-name-x, svc-name-y, svc-name-z...)
This parameter specifies a list of SNMP-managed services. For each database or Oracle network service for which SNMP support is enabled, the name of that service must in the SNMP.VISIBLESERVICES list. The other SNMP.ORA parameters refer to these service names.
You must specify service names for database names in the SNMP.VISIBLESERVICES list, for example, HR or SALES. The service name can be an alias to a SQL*Net V1 connect string or the SQL*Net version 2 service name.
SNMP.INDEX.SERVICE_NAME=unique-integer
Each service listed in the SNMP.VISIBLESERVICES line must have an index entry of an integer 1 or greater.
Note: The integer must be unique on the host.
The integer is used as the value of applIndex, which indexes the applTable of the Network Services MIB, and almost all of the tables in the RDBMS MIB and private MIB.
Attention: The selected integer must not conflict with those assigned to other applications implementing the Network Services MIB on this host such as other databases, mail, or directory servers.
SNMP.SID.SERVICE_NAME=SID
This parameter specifies the ORACLE_SID associated with the database. ORACLE_SID is used by the database subagent as the value of applName for this database.
The subagent uses the SID in the following ways:
· Returns the SID as rdbmsSrvName
· Assumes that services with SIDs are databases
· Assumes that services without SIDs are other types of services
Note: If you do not include a SID for a database, the Subagent assumes that it is a non-database service, and will not connect to it or register any MIB variables for it.
SNMP.CONNECT.SERVICE_NAME=username
This parameter overrides the default username created for the database Subagent.
Note: This optional parameter is only for databases.
SNMP.CONNECT.SERVICE_NAME.PASSWORD=password
This parameter overrides the default username created for the database Subagent.
SNMP.CONTACT.SERVICE_NAME="Contact Name, Phone Number, etc.
Note: This parameter is optional; however, a name and phone number are recommended. Network Manager automatically creates the quotation marks (") around the value for this parameter.
This parameter can be used for any SNMP-managed service and answers queries for the following:
rdbmsDbContact
rdbmsSrvContact
oraNamesTnsContact
oraInterchgContactInfo
oraListnerContact
If this parameter is not used for SNMP service, then either noSuchName is returned for SNMPv1 or noSuchIndex for SNMPv2.
Note: You cannot configure the following seven parameters from Network Manager. After you have generated configuration files with Network Manager, you must add them manually using a file editor of your choice.
DBSNMP.POLLTIME=integer
The integer signifies the interval (in seconds) to be used as a polling interval for the status of each SNMP-managed database. Default is 30 seconds.
The Subagent tries every 30 seconds to connect to SNMP-managed databases that are down.
DBSNMP.TRACE_LEVEL=OFF|USER|ADMIN
This parameter indicates the level of detail the trace facility records for database subagent events. Choices are OFF, USER, or ADMIN. Default is OFF. Selecting USER provides a limited level of tracing; ADMIN provides a more detailed trace.
DBSNMP.TRACE_DIRECTORY=path_to_trace_directory
This parameter sets the directory where the trace file is placed. Default is operating system specific. On UNIX, for example, it is $ORACLE_HOME/network/trace.
DBSNMP.TRACE_FILE=trace_filename
This parameter establishes the name of the file to which trace information is written. Default is DBSNMP.TRC on most platforms.
DBSNMP.TRACE_UNIQUE=ON|OFF
If the value is set to ON, a process identifier is appended to the name of each trace file generated so that several can coexist. The default is OFF.
DBSNMP.LOG_DIRECTORY=path_to_log_directory
This parameter indicates the directory in which to find the log file that is automatically generated for SNMP events. Default is operating system specific. On UNIX, for example, it is $ORACLE_HOME/network/log.
DBSNMP.LOG_FILE=log_filename
This parameter sets the name of the log file for Oracle SNMP support. Default is DBSNMP.LOG on most platforms.
Note: Currently, you need to add this parameter manually to LISTENER.ORA, TNSNET.ORA, and NAMES.ORA--you cannot set it through Network Manager.
Note: Currently, you can configure the QUEUESIZE parameter for listeners on DECnet and TCP/IP protocols only. Also, if the QUEUESIZE parameter is not present in the appropriate configuration file (TNSNET.ORA, LISTENER.ORA, or NAMES.ORA), TCP/IP defaults to 17.
LISTENER_mike.world=(ADDRESS_LIST= (ADDRESS= (PROTOCOL=IPC) (KEY=prod.world) ) (ADDRESS= (PROTOCOL=IPC) (KEY=db1) ) (ADDRESS= (PROTOCOL=tcp) (HOST=mike.world) (PORT=1521) (QUEUESIZE=20) ) )
names.server_name = NameServer.us.oracle.com
names.admin_region = (REGION=
(NAME= LOCAL_REGION.world)
(TYPE= ROSDB)
(USERID= NETADMIN)
(PASSWORD= netadmin)
DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(COMMUNITY=TCPCOM.us.oracle.com)
(PROTOCOL=TCP)
(Host=deer.us.oracle.com)
(Port=1521) (QUEUESIZE=20)
)
)
(CONNECT_DATA=(SID=ds)
)
)
(DOCNAME=deer)
(VERSION= 34611200)
(RETRY = 600))
names.config_checkpoint_file= cfg00406
names.trace_level= OFF
names.trace_unique= FALSE
|
Prev Next |
 Copyright © 1996 Oracle Corporation. All Rights Reserved. |
Library |
Product |
Contents |
Index |