Tải bản đầy đủ (.pdf) (40 trang)

Tài liệu ORACLE8i- P11 pptx

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (451.15 KB, 40 trang )

393
You may optionally specify the service name of an Oracle instance by setting the
SERVICE_NAMES parameter in the init.ora file. I recommend setting the service
name in this manner as good practice, to eliminate guesswork. The following example
illustrates setting the service name of an Oracle instance. In this example, two service
names are specified for a single instance.
service_names = toffee.cafecandy.com, orange.cafecandy.com
Naming Methods
The Net8 client resolves net service names through one of five known naming methods:
Local naming Local naming is specific to each Oracle client and requires
extensive administration. With local naming, net service names are stored in the
tnsnames.ora file residing in $ORACLE_HOME/network/admin on a Unix system or
in %ORACLE_HOME%\network\admin on a Windows NT system. Local naming is
most appropriate for small networks with a limited number of services and clients.
Oracle Names Oracle Names is an Oracle directory service comprised of a
system of Oracle Names servers, which can be centrally managed by the DBA.
Oracle Names is a good solution for a high-volume, dynamic, and complex
environment.
NOTE Oracle Names will be deprecated in Oracle9i. Because of this, if you need a cen-
tralized naming resolution solution, it is recommended that you use Oracle Directory Nam-
ing rather than Oracle Names.
Oracle Directory Naming Oracle Directory Naming uses an LDAP
(Lightweight Directory Access Protocol)–compliant directory server to store net
service names and connect descriptors. The network directory becomes the cen-
tral repository for all data on databases, network components, and user and cor-
porate policies and preferences, replacing client-side and server-side localized files.
Administrators can centrally manage these objects, and all systems on the hetero-
geneous network can refer to the directory for information. Net8 supports Oracle
Internet Directory, Microsoft Active Directory, and Novell Directory Services (NDS).
Host naming Host naming uses a known name resolution service in a
TCP/IP environment, such as Domain Name System (DNS) or Network


Information Services (NIS).
INTRODUCING NET8
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
394
External naming External naming support allows sites to resolve Oracle
service names using industry-standard name services, including Sun NIS+, NDS,
and the Open Software Foundation/Distributed Computing Environment
(OSF/DCE) Cell Directory Service (CDS).
Local naming and host naming fall under the localized management network con-
figuration model. Localized management involves configuring name resolution on
each Oracle client in a tnsnames.ora file. Oracle Names, Oracle Directory Naming,
and external naming fall under the centralized management network configuration
model. Centralized management eases management of Oracle clients, because you do
not need to reconfigure each client every time a new Oracle service is added to the
network.
Configuring Net8
Net8 is typically installed along with other Oracle8i products. For example, when you
install the database server or SQL*Plus, Net8 will be installed at the same time. You
can choose to install Net8 without any other client software (though some dependent
libraries will still be installed). If you need to install Net8, simply insert your server
installation CD (or SQL*Plus installation CD), start the Universal Installer, and choose
to do a Custom Install. From the Available Product Components window, choose Net8.
(See Chapter 2 for details on the Oracle Universal Installer and installing Oracle8i

components.)
NOTE In addition to installing Net8 you will need to install one or more protocol
adapters, to allow Net8 to communicate using the protocol you wish to use. By default,
Oracle will try to install the correct protocol adapter, but it’s always a good idea to make
sure that the correct one is being installed.
Net8 is configured using configuration files located on the client and network
server hosts. The following configuration files contain information about where ser-
vices are located and how to establish connections between the application client and
an Oracle service:
• listener.ora, located on the server, contains configuration information about
listeners on a server.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
395
• tnsnames.ora, located on the client, contains information about net service
names and connection data.
• sqlnet.ora, located on the client and/or server, contains information about the
net service name resolution method and Net8 configuration options.
• names.ora, located on the client, contains information about an Oracle Names
server.
These configuration files are typically found in $ORACLE_HOME/network/admin on a
Unix system, in %ORACLE_HOME%\network\admin on Windows NT system, or in the
location specified by the TNS_ADMIN environment variable or registry entry.
The listener.ora and tnsnames.ora files are covered in the following discussions
of configuring the listener and client. The sqlnet.ora and names.ora files are dis-
cussed later in this chapter, in the “Using Oracle Names” section.
Configuring and Managing the Listener
You must employ a listener on each host where an Oracle service resides. The Net8

listener process monitors for and processes incoming database connection requests
from client applications. The listener process runs independently of any Oracle
instances running on the host. In fact, one listener process can service connections
for any instance running on the host. The Net8 listener verifies the connection data
passed to it by matching this information to the services that have been registered
with the listener.
The listener has a default name of LISTENER and will be automatically configured
to listen on the TCP/IP protocol on port 1521, or on the IPC protocol for external
procedures.
Just as you can run multiple Oracle instances on a single node, you can also config-
ure multiple listeners for that node. If you configure multiple listeners, each listener
will have the name you specify in the listener.ora configuration file. A single lis-
tener can service multiple service names, and multiple listeners can service a single
service name.
Registering Service Names
A service name can be registered with the listener either through configuration infor-
mation saved in the listener.ora file or through automatic registration at instance
startup. Beginning with Oracle8i, the PMON process will register the service names
for that instance with the listener through a feature known as service registration. Ser-
vice registration is automatic at instance startup if the listener is already running. If
the listener is not already running at instance startup, Oracle will periodically check
CONFIGURING NET8
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING

396
to see if the listener has started. When the listener is started, the Oracle instance will
register its service names with the listener.
NOTE If you are running an Oracle instance under a version of Oracle prior to Oracle8i,
you must manually configure the listener for those services. Listener configuration is also
required when using certain products such as Oracle Enterprise Manager (OEM).
You can control service name registration by specifying the name of the listener in
the init.ora file using the LOCAL_LISTENER parameter. Set this parameter to a lis-
tener name alias that is resolved either through tnsnames.ora or an Oracle Names
server. In the following example, the Oracle instance is configured to register its ser-
vice names with the listener brewlist.
local_listener=brewlist
The listener alias is then resolved through a known naming method. In this
example, the resolution is through local naming in the tnsnames.ora file:
brewlist=
(address=(protocol=tcp)(host=oregano)(port=1521))
Following instance startup, the PMON process will then register the service names
for that instance with the brewlist listener running on host oregano and listening on
port 1521.
Configuring the listener.ora File
Listing 9.1 shows a sample listener.ora file with a Net8 listener configuration.
Listing 9.1: A listener.ora File with a Net8 Listener Configuration
# Listener Address Section
listener=
(description=
(address_list=
(address=(protocol=tcp)(host=oregano)(port=1521))
(address=(protocol=ipc)(key=toffee.cafecandy.com))
)
)

# Static Service Section
sid_list_listener=
(sid_list=
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
397
(sid_desc=
(global_dbname=toffee.cafecandy.com)
(oracle_home=/u01/app/oracle/product/8.1.7)
(sid_name=toffee)
)
)
# Listener Control Options
connect_timeout_listener=5
logging_listener=off
NOTE You can use the formatting style you prefer for the listener.ora file, but you
should try to be consistent. Note that some versions of the Net8 software will generate an
error if parentheses are written in the first column.
There are three sections within the listener.ora file for each listener configured:
the listener address section, the static service section, and the control parameters sec-
tion. Let’s look at these sections in a bit more detail.
The Listener Address Section
The listener address section defines the protocol addresses for the listener. In other
words, this section tells the listener where to listen for incoming connection requests.
This section starts with the name of the listener, such as LISTENER, followed by a
description that is a list of protocol addresses.
# Listener Addresses
listener=

(description=
(address_list=
(address=(protocol=tcp)(host=oregano)(port=1521))
(address=(protocol=ipc)(key=toffee.cafecandy.com))
)
)
The address in this example is a TCP/IP protocol address that specifies the name of
the destination host and the port that the listener is monitoring. The host can be the
current host or another host to which the listener will forward the connection
request. The second protocol address in this listing is an IPC address. In this address
definition, the key parameter specifies the name of the service that receives the IPC
protocol communications.
CONFIGURING NET8
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
398
For systems that handle many connection requests, you may want to configure a
queue for the listener process. This feature enables the listener to dynamically handle
a larger volume of connection requests. Check your platform-specific documentation
for availability of listener queues and default queue sizes. To configure a queue for a
protocol address, specify the QUEUESIZE parameter at the end of the address defini-
tion. The following example demonstrates how to configure a queue size of 20 for the
first listener address only.
# Listener Addresses

listener=
(description=
(address_list=
(address=(protocol=tcp)(host=oregano)(port=1521)
(queuesize=20)
)
(address=(protocol=ipc)(key=toffee.cafecandy.com))
)
)
The Static Service Section
The static service section includes the static service name configurations for the lis-
tener. This section also supports backward compatibility for instances running ver-
sions prior to Oracle8i, as well as for certain add-ons such as OEM. This section starts
with the parameter SID_LIST_<listener name>, such as SID_LIST_LISTENER, followed
by a list of SIDs.
# Static Service Section
sid_list_listener=
(sid_list=
(sid_desc=
(global_dbname=toffee.cafecandy.com)
(oracle_home=/u1/app/oracle/product/8.1.7)
(sid_name=toffee)
)
)
In this example, the GLOBAL_DBNAME parameter specifies the service name for
which the listener is receiving requests. The ORACLE_HOME parameter should match
the definition of the ORACLE_HOME parameter for the instance. SID_NAME is the
SID of the instance.
C
opyright ©2002 SYBEX, Inc., Alameda, CA

www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
399
Listener Control Parameters
The control parameters are optional and control the operation of certain features of
the listener, such as listener tracing and connection time-outs. Each parameter in this
section is suffixed with the name of the listener, such as CONNECT_TIMEOUT_
LISTENER. Table 9.1 describes the available control parameters.
TABLE 9.1: LISTENER CONTROL PARAMETERS IN THE LISTENER.ORA FILE
Parameter Default Description
connect_timeout 10 Specifies the time (in seconds) that the listener will
wait for a valid connection to be made
log_directory
$ORACLE_HOME/ Specifies the destination directory for the listener
network/log log file
log_file
<listener_ Specifies the name of the listener log file
name>.log
logging ON Turns listener logging on or off
passwords oracle Sets an unencrypted password for the listener con-
trol (lsnrctl) utility and allows one or more pass-
words; an encrypted password can be set using
lsnrctl change_password
save_config_on_stop FALSE If set to TRUE, saves to the
listener.ora file any
configuration changes set using lsnrctl
startup_wait_time 0 Specifies the time (in seconds) that the listener will
sleep before responding to the lsnrctl status command
trace_directory
$ORACLE_HOME/ Specifies the destination directory for the listener

network/trace trace files
trace_file
<listener_ Specifies the name of the listener trace file
name>.trc
trace_filelen Unlimited Specifies the maximum size of the listener trace file,
in kilobytes
trace_fileno 1 When trace_filelen is also specified, specifies the
maximum number of listener trace files; when this
setting is exceeded, the listener will recycle the lis-
tener trace files
trace_level OFF Turns listener tracing on or off and specifies incre-
mental tracing levels: OFF (no trace output), USER
(user trace information), ADMIN (administrative trace
information), or SUPPORT (Oracle worldwide cus-
tomer support trace information)
CONFIGURING NET8
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
400
TABLE 9.1: LISTENER CONTROL PARAMETERS IN THE LISTENER.ORA FILE
Parameter Default Description
trace_timestamp OFF Specifies whether to add a timestamp in the format
of dd-month-yyyy hh:mm:ss to a trace event; set
using ON|TRUE|OFF|FALSE

use_plug_and_play OFF Tells the listener to register services with an Oracle
Names server
The following example sets the CONNECT_TIMEOUT parameter to 5 seconds and
turns listener logging off.
# Listener Control Options
connect_timeout_listener=5
logging_listener=off
Managing the Listener
You can manage the listener with the Listener Control utility, lsnrctl. You can issue a
single command from the operating system prompt by passing arguments to lsnrctl,
as follows:
$ lsnrctl command [listener_name]
In this syntax, listener_name is the name of the listener defined in the
listener.ora file. It is not necessary to identify the listener if you are using the
default listener, named LISTENER. Table 9.2 describes the basic lsnrctl commands.
TABLE 9.2: COMMONLY USED LISTENER CONTROL (LSNRCTL) COMMANDS
Command Description
START Starts the listener
STOP Stops the listener
RELOAD Reloads the listener configuration
STATUS Shows the current status of the listener, including the version of the lis-
tener, start time, up time, tracing level, logging and tracing options, the
name and location of the listener configuration file, a list of services reg-
istered with the listener, and the addresses the listener is monitoring
HELP Lists all available lsnrctl commands, or if a command is specified,
shows help information about that command
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

401
TABLE 9.2: COMMONLY USED LISTENER CONTROL (LSNRCTL) COMMANDS
Command Description
SET Lists the available parameters that can be passed to the SET command,
or if passed a parameter, modifies the setting of the parameter
SHOW Lists the available parameters that can be passed to the SHOW com-
mand, or if passed a parameter, shows the setting of the parameter
CHANGE_PASSWORD Sets an encrypted password for the listener
SERVICES Provides detailed information about the services registered with the
listener
TRACE Turns on tracing for the listener
VERSION Shows the current lsnrctl version
Configuring the Net8 Client
The Net8 client might be an application running on a PC or a database that requests
information from another database through a database link. The Net8 client resolves
connect identifiers to connect descriptors through a net service name identified by a
known name resolution method, as discussed in the “Naming Methods” section, ear-
lier in this chapter. Here, we will discuss the local naming method and basic Net8
client configuration.
Local naming resolves service names to network addresses by using information
configured in the tnsnames.ora file that is stored locally on each client node. Before a
database server can receive connections from clients, the clients must have a
tnsnames.ora file with service names that map to the service addresses listed in the
database server’s listener.ora file. You configure the client by creating a list of ser-
vice names (which are aliases for database network addresses) and addresses of net-
work destinations (database server names or IP addresses) in the tnsnames.ora file.
In the tnsnames.ora file, the net service names are mapped to database network
addresses contained in a connect descriptor. A connect descriptor contains the loca-
tion of the listener through a protocol address and the service name of the database
to which to connect. Clients and servers that are clients of other servers use this net

service name when making a connection to an application.
Here is the basic syntax for a net service name entry in the tnsnames.ora file:
<net service name>=
(description=
CONFIGURING NET8
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
402
(address=(protocol=<protocol>)(host=<host>)(port=<port>))
(connect_data=
(service_name=<service name>)
)
)
For each connect identifier referenced by a Net8 client, a matching net service
name entry should be listed in the tnsnames.ora file to allow the client to make the
proper connection. Listing 9.2 illustrates how a connect identifier is mapped to a con-
nect descriptor through the net service name toffee.
Listing 9.2: Mapping a Connect Identifer to a Connect Descriptor in the
tnsnames.ora File
toffee=
(description=
(address=(protocol=tcp)(host=oregano)(port=1521))
(connect_data=
(service_name=toffee.cafecandy.com)

)
)
In the event that a service name represents more than one instance, you may iden-
tify a specific instance in the connect descriptor. This is particularly useful if you are
using Oracle Parallel Server (OPS). Listing 9.3 shows an example that specifies the
instance name, which matches the INSTANCE_NAME parameter in the init.ora file
of that instance.
Listing 9.3: Identifiying an Instance in a Connect Descriptor in the
tnsnames.ora File
toffee=
(description=
(address=(protocol=tcp)(host=oregano)(port=1521))
(connect_data=
(instance_name=toffee)
(service_name=toffee.cafecandy.com)
)
)
Client Load Balancing
If you have configured multiple listeners for a service, you can configure the Net8
client to randomize connection requests to the listeners through a feature called client
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
403
load balancing. This feature causes the Net8 client to randomly select which listener it
will attempt to connect with. To enable client load balancing, you define two proto-
col addresses and set the LOAD_BALANCE parameter in the net service name descrip-
tion, as shown in Listing 9.4.
Listing 9.4: Using Client Load Balancing

toffee=
(description=
(load_balance=on)
(address=(protocol=tcp)(host=oregano)(port=1521))
(address=(protocol=tcp)(host=thyme)(port=1521))
(connect_data=
(service_name=toffee.cafecandy.com)
)
)
Enabling Connect Time Failover
If you have configured multiple listeners for a service, you can configure the Net8
client to fail over from one listener to the other if a connection request to the first lis-
tener fails. You may use this option with or without client load balancing. To enable
connect time failover, you define two protocol addresses and set the FAILOVER param-
eter in the net service name description. Listing 9.5 shows an example of enabling
load balancing and connect time failover.
Listing 9.5: Enabling Connect Time Failover
toffee=
(description=
(load_balance=on)
(failover=on)
(address=(protocol=tcp)(host=oregano)(port=1521))
(address=(protocol=tcp)(host=thyme)(port=1521))
(connect_data=
(service_name=toffee.cafecandy.com)
)
)
Using Transparent Application Failover
Transparent Application Failover (TAF) is a runtime failover method that enables a Net8
client to reestablish connection to a service through the same listener, or through an

alternate listener if the first connection fails. Optionally, you can have TAF resume a
CONFIGURING NET8
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
404
SELECT statement. The failover works transparently to the user. TAF is especially use-
ful for high-availability architectures such as OPS and Oracle Fail Safe (discussed in
Chapter 25).
TAF is different from connect time failover. Connect time failover handles redirect-
ing initial connections. TAF is concerned with established connections. You may use
TAF along with the connect time failover and client load balancing features described
in the previous sections.
NOTE TAF works only with services registered with the listener through service name
registration. Static configuration of a service name with a listener will disable TAF.
TAF is implemented by adding the FAILOVER_MODE parameter to the CONNECT_
DATA portion of the connect descriptor. The general syntax of the FAILOVER_MODE
parameter is:
failover_mode=
(backup=<backup connection ID>)
(type=<failover type>)
(method=<failover method>)
(retries=<number of retries> )
(delay=<wait time between retries> )
FAILOVER_MODE takes the following parameters:

• The BACKUP parameter specifies a connect identifier for the backup
connection.
• The TYPE parameter specifies the type of failover. Three types are possible:
• SESSION, so a failed session will reconnect
• SELECT, so a failed session will reconnect and resume SELECT statements in
progress at the time of session failure
• NONE, which is the default and explicitly disables TAF
• The METHOD parameter specifies the method of failover. Two methods are
possible:
• BASIC will establish failover connection at the time of failover.
• PRECONNECT will preestablish idle failover connection to the backup
server.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
405
• The RETRIES parameter specifies the number of times to retry a failed connec-
tion. If the DELAY parameter is set, RETRIES defaults to 5.
• The DELAY parameter specifies the time, in seconds, to wait between retry
attempts. If the RETRIES parameter is set, DELAY defaults to 1.
Basic Failover
Listing 9.6 shows an example of using the SELECT type and BASIC method of TAF. In
this configuration, Net8 will reestablish a session with the second listener when the
original connection fails. The session will resume processing of any SELECT state-
ments that were in progress at the time of session failure.
Listing 9.6: Enabling Basic Failover
toffee=
(description=
(address=(protocol=tcp)(host=oregano)(port=1521))

(address=(protocol=tcp)(host=thyme)(port=1521))
(connect_data=
(service_name=toffee.cafecandy.com)
(failover_mode=
(type=select)
(method=basic)
)
)
)
Preconnect Failover
When you use the PRECONNECT method of TAF, Net8 establishes both the initial
connection and an idle failover connection to a backup instance. This configuration
is faster than basic failover, at the cost of additional overhead. In the example shown
in Listing 9.7, TAF is configured to preestablish a backup connection to the net service
name orange and will fail over to that connection should the primary session opened
with the net service name toffee fail.
Listing 9.7: Enabling Preconnect Failover
toffee=
(description=
(address=(protocol=tcp)(host=oregano)(port=1521))
(connect_data=
(service_name=toffee.cafecandy.com)
(failover_mode=
CONFIGURING NET8
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
406
(backup=orange)
(type=select)
(method=preconnect)
)
)
)
orange=
(description=
(address=(protocol=tcp)(host=oregano)(port=1521))
(connect data=
(service_name=orange.cafecandy.com)
)
)
Connection Retry
When you use the RETRIES parameter, Net8 will attempt to reconnect to a service
until a connection is reestablished or the retry limit is reached. In the example shown
in Listing 9.8, TAF will retry the connection 20 times before failure.
Listing 9.8: Enabling Connection Retries
toffee=
(description=
(address=(protocol=tcp)(host=oregano)(port=1521))
(connect_data=
(service_name=toffee.cafecandy.com)
(failover_mode=
(type=select)
(method=basic)
(retries=20)

)
)
)
Using the Net8 Configuration Assistant
You might have noticed that there is a lot of manual work to the configuration of
Net8. One slip of the finger, one misplaced parenthesis, and you are in a world of
hurt. Oracle provides a somewhat simpler method of maintaining your Net8 configu-
rations through the use of the Net8 Configuration Assistant. This graphical utility
offers the following options for configuring Net8:
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
407
• The Listener Configuration allows you to create, update, remove, or rename an
Oracle listener. This option is valid only for a system on which the database
server is running; it is not used on clients.
• The Naming Methods (Oracle Names) Configuration option allows you to con-
figure Net8 naming methods. You can choose from the naming methods
described in the “Naming Methods” section earlier in this chapter.
• The Local Net Service Name Configuration option allows you to maintain a
local copy of the tnsnames.ora file.
• The Directory Service Access Configuration option is used to configure access to
an LDAP directory server. Choose this option if you are using Oracle Directory
Naming or Oracle Advanced Security.
Once you have selected the type of Net8 configuration you wish to complete, just
follow the prompts, and the Net8 Configuration Assistant will complete the Net8
configuration for you.
Using Oracle’s Multithreaded Server (MTS) Option
Net8 connections are established using two different models: the dedicated server

model or the multithreaded server (MTS) model. With the dedicated server model, the
listener starts a server process dedicated to the client session and passes the connec-
tion to that server process.
With MTS, the listener passes the connection to a dispatcher, which supports mul-
tiple client sessions concurrently. Each session is bound to a virtual circuit, which is a
unit of memory used by the dispatcher to manage that session. The dispatcher places
the virtual circuit in a queue when communication from the client arrives. An idle
shared server process picks up the virtual circuit from the queue and services the
request. Because any individual client session is relatively idle, this architecture allows
a small pool of server processes to handle a larger number of client sessions and also
consumes less memory on the host.
NOTE When an Oracle instance configured for MTS is started and a listener to support
the service is running, each dispatcher is registered with the listener. Registration can take
up to a minute. If a client session request is received before the dispatchers are registered
with the listener, the listener may assign a dedicated server process.
USING ORACLE’S MULTITHREADED SERVER (MTS) OPTION
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
408
You should use MTS only if your application is using technology that mandates it
(like Enterprise JavaBeans) or if you have reached your scalability limits in terms of
process counts or possibly virtual memory. With MTS, you need fewer processes, thus
context switching is cheaper and the total virtual memory size is a little lower (but
the SGA is much larger). This means that MTS can let you support more users on a

system that is already running at capacity, but increasing that capacity is normally a
better solution.
Configuring MTS
MTS is configured for an Oracle instance using the MTS_DISPATCHERS parameter in
the init.ora file for the instance. This is the only required parameter for configuring
MTS; all of the other MTS parameters are optional.
The following is the basic syntax for MTS_DISPATCHERS:
mts_dispatchers=”(<attribute>=<value>)[(<attribute>=<value>)… ]”
At a minimum, the MTS_DISPATCHERS parameter must set one attribute: the
address, description, or protocol attribute. These and the other, optional, attributes
available for MTS_DISPATCHERS are described in Table 9.3.
TABLE 9.3: MTS_DISPATCHERS ATTRIBUTES
Attribute Description
address Specifies the network protocol address of the endpoint on which the dis-
patchers listen. This attribute must be set if the description or protocol
attribute is not specified.
description Specifies the network description of the endpoint on which the dispatchers
listen, including the network protocol address. This attribute must be set if
the address or protocol attribute is not specified.
protocol Specifies the network protocol for which the dispatcher generates a listening
endpoint. This attribute must be set if the address or description attribute is
not specified.
connections Specifies the maximum number of network connections to allow for each
dispatcher.
dispatchers Specifies the initial number of dispatchers to start. The number of dispatchers
does not change dynamically but must be incremented with the ALTER SYS-
TEM command, so be sure to configure enough dispatchers for your system.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
409
TABLE 9.3: MTS_DISPATCHERS ATTRIBUTES (CONTINUED)
Attribute Description
listener Specifies a listener alias with which the PMON process will register dis-
patcher information. Refer to the “Registering Services” section earlier in this
chapter for information about registering with a nondefault listener.
multiplex Enables connection concentration.
pool Enables connection pooling.
service Specifies the service name to register with the listener. By default, MTS will
use the service_names setting.
session Specifies the maximum number of sessions to allow for each dispatcher.
ticks Specifies the size of a network tick in seconds. The value set is multiplied by
the pool time-out value to get the total connection pool time-out. The default
is 15 seconds. Oracle recommends a tick size of about 1 second for a fast
network and about 3 to 4 seconds for a slow network.
For example, to set up MTS on the TCP/IP protocol with 20 initial dispatchers, you
would add the following line to your init.ora file:
mts_dispatchers=”(protocol=tcp)(dispatchers=20)”
Other MTS parameters can be used to tune the performance of MTS. The following
parameters are optional:
• MTS_MAX_DISPATCHERS specifies the maximum number of MTS dispatchers.
• MTS_SERVER specifies the number of MTS shared server processes to be started
at instance startup.
• MTS_MAX_SERVERS specifies the maximum number of MTS shared servers.
• MTS_CIRCUITS specifies the maximum number of MTS virtual circuits.
• MTS_SESSIONS specifies the maximum number of MTS sessions to allow.
TIP When configuring MTS, you may also need to adjust the LARGE_POOL_SIZE and
SESSIONS parameters. The LARGE_POOL_SIZE parameter specifies the size of the large
pool, in bytes. The SESSIONS parameter specifies the maximum number of sessions avail-

able to the Oracle instance.
USING ORACLE’S MULTITHREADED SERVER (MTS) OPTION
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
410
Viewing MTS Information
Oracle provides some V$ views that offer useful information about MTS. For example,
the V$DISPATCHER view shows information about dispatcher processes. The V$MTS,
V$SGA, and V$SGASTAT views provide information that may be useful for tuning
MTS. Table 9.4 describes the MTS views.
TABLE 9.4: MTS VIEWS
View Description
V$DISPATCHER Provides information on the dispatcher processes,
including name, network address, status, various
usage statistics, and index number
V$DISPATCHER_RATE Provides rate statistics for the dispatcher processes
V$QUEUE Contains information on the multithread message
queues
V$SHARED_SERVER Contains information on the shared server processes
V$CIRCUIT Contains information about virtual circuits, which are
user connections to the database through dispatch-
ers and servers
V$MTS Contains information for tuning MTS
V$SGA Contains size information about various system

global area (SGA) groups
V$SGASTAT Shows detailed statistical information about the SGA
V$SHARED_POOL_RESERVED Lists statistics to help tune the reserved pool and
space within the shared pool
Managing MTS on the Client
You may optionally configure a client to use only dedicated or shared servers using
the server parameter in the CONNECT_DATA portion of the connect descriptor in the
tnsnames.ora file. If a shared server is requested but not available, the connection
request fails. In the example shown in Listing 9.9, the connect descriptor for toffee is
set up to use only dedicated servers, while orange is configured to use only shared
servers.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
411
Listing 9.9: Configuring Clients to Use Only a Dedicated Server or Only a
Shared Server
toffee=
(description=
(address=(protocol=tcp)(host=oregano)(port=1521))
(connect_data=
(service_name=toffee.cafecandy.com)
(server=dedicated)
)
)
orange=
(description=
(address=(protocol=tcp)(host=thyme)(port=1521))
(connect_data=

(service_name=orange.cafecandy.com)
(server=shared)
)
)
Using Oracle Names
Oracle Names is a distributed directory service made up of a system of integrated Oracle
Names servers that provide name-to-address resolution for each Net8 service on the
network. Oracle Names simplifies Net8 setup and administration in complex, distrib-
uted computing environments.
How Oracle Names Works
Clients configured to use Oracle Names refer connection requests to an Oracle Names
server. The Oracle Names server resolves the service name provided by the client to a
network address and returns that information to the client. The client can then use
that address to connect to the service.
Oracle Names employs administrative regions. An administrative region is a logical
entity for organizing Net8 services. Each administrative region consists of a collection
of one or more Oracle Names servers that administer services for that region. Admin-
istrative regions are transparent to clients in that Oracle Names servers forward name
resolution requests from clients in foreign administrative regions to the proper Oracle
Names server. An administrative region can span multiple domains. Domain names
USING ORACLE NAMES
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
412

in Oracle exist independently of network domains, although you may follow the
same domain naming conventions to ease administration.
Oracle Names includes three features to improve network performance and ease of
administration:
• Dynamic service registration
• Client discovery of Names servers
• Name resolution optimization
Let’s look at each of these features in a bit more detail.
Service Registration
Net8 services can register themselves with a Names server, and their addresses are
made available to all the other Names servers in the region. Upon startup, a Net8 ser-
vice looks for a Names server with which to register. This process is as follows:
• If a service has a sqlnet.ora file, it looks for the NAMES.PREFERRED_SERVER
parameter. If the parameter exists, it registers with the first Names server listed.
• If there is no sqlnet.ora file, it looks for a Names server with a well-known
address. The well-known Names server address on a TCP/IP network is a host
aliased to oranamesrvr0, oranamesrvr1, and so on, using port 1575.
• If it can’t find a well-known address, the Oracle Installer prompts the user to
provide a Names server address.
NOTE Administrators can also register services manually using namesctl. Using this util-
ity is discussed a bit later in this chapter.
Once the service is registered, its address is made available to all other Names
servers in the region. The address information is shared in one of two ways: through
service replication or through an Oracle Names database. In service replication, ser-
vice information is stored in a Names server’s cache and is instantly replicated to the
caches of all other Names servers in the region. If an Oracle database is used as the
registration repository, the registration information is stored in the database, and
from there is accessible to all the Oracle Names version 8 servers in the region.
Client Discovery of Names Servers
By referring to a list of Oracle Names servers, a client or another Oracle Names server

can contact an Oracle Names server. This process of creating the list is called discovery.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
413
When a client tries to discover an Oracle Names server (with the namesctl utility or
Net8 Assistant), one Oracle Names server is found first. Once the client finds an Oracle
Names server, it pings all other Oracle Names servers in the region. A list of Oracle Names
servers is then created on the client and saved to a file named .sdns.ora on Unix sys-
tems and sdns.ora on Windows platforms. This list is sorted in order of response time.
The discovery process allows the client to retrieve a list of all the existing Names
server addresses and to find out about new Names servers as they appear in the net-
work. This allows for dynamic changes in the network topology with minimal
involvement on the user’s part and with little or no impact on the performance of a
normal query.
Clients discover Names servers in much the same way that services find them for
registration:
• A client first looks in its own client-side cache. If it has contacted a Names server
within the past 24 hours, the address of a Names server may be in the cache.
• If a client has a sqlnet.ora file, it looks for the NAMES.PREFERRED_SERVER
parameter. If one exists, it queries the first Names server listed.
• If there is no sqlnet.ora file, a client looks for a Names server with a well-
known address. The well-known Names server address on a TCP/IP network is a
host aliased to oranamesrvr0, oranamesrvr1, and so on, using port 1575.
• If Net8 is being installed on the client and the client cannot find a Names server
address, the Oracle Installer prompts the user to provide a Names server address.
The user must provide a Names server address in order to continue.
Once a Names server is found, the addresses of all the other Names servers in the
region are made available to the client.

Name Resolution Optimization
There are two features of Oracle Names that optimize the speed with which client
name queries can be resolved:
• A client-side daemon process to find the fastest responding Names server
• A client-side cache
The following sections describe how each of these features optimizes client name
queries.
The Client-Side Daemon Process
When a client is installed with Net8 and Oracle Names, it finds a Names server and
retrieves a list of all the Names servers in the region. A client-side daemon process
contacts each of the Names servers in turn, and orders the list on the basis of the
USING ORACLE NAMES
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
414
speed of each Names server’s response. The result of this process is stored in an
sdns.ora file. Subsequently, when a client makes a query to a Names server, the
Names server at the top of the list in the sdns.ora file is contacted first. Whenever
the client queries a Names server, the time of the round-trip is used to modify the
order of entries in the list.
A Names server list reordering consists of asking one live Names server for all of its
Names server addresses within the region. If fewer than two are found, or if fewer
than two are live when asked by the initial Names server, a list of Name servers in the
parent region is requested (if one exists). Each Names server that responds is then

added to the list that is being constructed. The resorted list is then written to
sdns.ora. By featuring periodic reorders, Oracle Names version 8 ensures that the
client receives the best response time to a query. The reordering algorithm takes no
longer than a few seconds.
A full Name server reorder is performed at the following times:
• At installation of the Net8 client
• When requested by the user using namesctl (discussed shortly)
• At shutdown of the Net8 client
The Client-Side Cache
On most platforms, a local client cache is created when a client is started. Once a cur-
rent list of Names servers is retrieved, that list is stored in the local client cache. Simi-
larly, when a Names server resolves a name query, the result of that query is stored in
the client-side cache. Clients attempt to find the result of a query by first looking in
their cache, so that subsequent requests for name resolution can be answered, in most
cases, more quickly than a network round-trip between the client and a Names server.
Forwarding the query on to the Names server retrieves any names that are not in the
local client-side cache or have timed-out.
The local client-side cache is particularly advantageous if at some time no Names
server is available. In this case, the local client-side cache has the current list of
recently accessed services.
NOTE All the information in the client cache has a time to live (TTL). At the end of that
TTL, the information is flushed from the cache. The purpose of this feature is to avoid hav-
ing stale information in the client cache. The default TTL is 86,400 seconds (24 hours). It
cannot be changed.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
415
Not all platforms support the client-side cache. See your Oracle platform-specific

documentation for further information. If the client platform does not have a cache,
the result of the initial discovery process is stored in .sdns.ora in the client’s $ORACLE_
HOME/network/names directory.
Configuring Names Servers
An Oracle Names server stores the following information:
• Global database names and addresses
• Other Oracle Names server names and addresses
• Net service names
• Global database links
• Aliases
• Oracle Connection Managers
There should be at least two Names servers in a region, for fault-tolerance. Each
Names server in the network requires an individual configuration file called
names.ora. This file contains control parameters for the Names server and points the
Names server to the database where the network definition is stored. Listing 9.10
shows an example of a names.ora file.
Listing 9.9: A names.ora File
names.server_name = NameServer.world
names.admin_region =
(REGION=
(NAME = LOCAL_REGION.world)
(TYPE = ROSDB)
(USERID = names)
(PASSWORD = names)
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL=tcp)(Host=nineva)(Port=1387)
)
)
(CONNECT_DATA=(SID=EM))

)
(DOCNAME=sbox)
(REFRESH=14400) #4 hours#
USING ORACLE NAMES
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 9 • ORACLE NETWORKING
416
(RETRY=600) #10 minutes#
(EXPIRE=259200) #3 days#
(VERSION=34619392) #2.1.4#
names.addresses = (address=(protocol=tcp)(host=george.world)(port=1522))
names.domains =
(DOMAIN_LIST =
(DOMAIN=(NAME=dname1)(MIN_TTL=20864))
(DOMAIN=(NAME=world)(MIN_TTL=20864))
)
names.config_checkpoint_file = cache.ckp
names.trace_level = OFF
names.trace_unique = FALSE
Managing Names Servers
The Names control (namesctl) program is a basic utility for controlling Oracle Names
servers. The namesctl utility can be run in three modes: INTERPRETER, COMMAND
LINE, and BATCH COMMAND.
With INTERPRETER mode, namesctl is loaded and all operations are executed

within it. When loaded, the program displays the following prompt:
namesctl>
You can also execute most commands from the operating system in COMMAND
LINE mode by running the namesctl program with a complete command as a parame-
ter to the program, as in this example:
namesctl START
In this case, namesctl will load and execute the command, then return to the operat-
ing system prompt.
In BATCH COMMAND mode, you can combine commands in a standard text file,
then run them as a sequence of commands. To execute in batch mode, use this format:
namesctl @file_name
You can use either REM or a hash mark (#) to identify comments in the batch script;
all other lines are considered commands. Any commands that would typically require
confirmation do not require confirmation during batch execution.
Requiring Passwords
You have the option of configuring a Names server to require a password for any
namesctl command that alters how it operates. If you do not enter anything in the
Password field on the Nameserver property sheet in the Oracle Network Manager, no
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
417
password is required to control any Names server function. If you do supply a pass-
word on the Nameserver property sheet in the Network Manager, you must also set
the password property in the namesctl program. If this is not done, the Names server
will not respond to some namesctl commands.
If you are concerned with the security implications of explicitly putting a Names
server password in the administrator’s client sqlnet.ora file, you can omit the param-
eter and always use the command:

SET PASSWORD
After you issue this command, you will be prompted for the password.
NOTE When passed over the network, the namesctl password is always encrypted,
regardless of how it is set in namesctl.
Issuing Names Control Commands
Some of the namesctl commands require your confirmation before they are executed.
When you issue the command, you are prompted:
confirm:[yes or no]
Type yes to execute the command, or type no to cancel the command. You can turn
confirmation mode off by setting this parameter in the sqlnet.ora file:
namesctl.NOCONFIRM = TRUE
When this parameter is set to TRUE, all commands execute without asking for
confirmation.
Table 9.5 lists the namesctl commands.
TABLE 9.5: COMMONLY USES NAMES CONTROL (NAMESCTL) COMMANDS
Command Description
EXIT Exits namesctl
FLUSH Flushes all foreign names from the cache
FLUSH_NAME Flushes an individual name from the foreign data
cache
HELP Gets brief general or specific help on commands
LOG_STATS Logs the current statistics to the log file
USING ORACLE NAMES
Oracle Networking
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Tải bản đầy đủ ngay
×