| Oracle® Database Net Services Administrator's Guide 10g Release 2 (10.2) Part Number B14212-02 |
|
|
PDF · Mobi · ePub |
| Oracle® Database Net Services Administrator's Guide 10g Release 2 (10.2) Part Number B14212-02 |
|
|
PDF · Mobi · ePub |
This chapter explains how databases are identified and how clients access them.
This chapter contains these topics:
See Also:
Chapter 1 for an introductory level overview of networking conceptsThis section contains these topics:
An Oracle database is represented to clients as a service; that is, the database performs work on behalf of clients. A database can have one or more services associated with it.
Figure 3-1 shows two databases, each with its own database service for intranet clients. One service, sales.us.acme.com, enables salespersons to access the sales database. Another service, finance.us.acme.com, enables financial analysts to access the finance database.
The sales and finance databases are each identified by a service name, sales.us.acme.com and finance.us.acme.com. The service name is specified by the SERVICE_NAMES parameter in the initialization parameter file. The service name defaults to the global database name, a name comprising the database name (DB_NAME parameter) and domain name (DB_DOMAIN parameter). In the case of sales.us.acme.com, sales is the database name and us.acme.com is the domain name.
Note:
You can change the value of
SERVICE_NAMES parameter dynamically with the SQL statement ALTER SYSTEM when the database is running. See the Oracle Database SQL Reference for further information about the ALTER SYSTEM statement and the Oracle Database Reference for further information about the SERVICE_NAMES parameter.A database can have multiple services associated with it. Figure 3-2 shows one database that has two different services for Web clients. One service, book.us.acme.com, is dedicated to clients making book purchases. The other service, soft.us.acme.com, is dedicated to clients making software purchases.
Figure 3-2 Multiple Services Associated with One Database
Having multiple services associated with one database enables the following functionality:
A database has at least one instance. An instance is comprised of a memory area called the System Global Area (SGA) and Oracle processes. The memory and processes of an instance efficiently manage the associated database's data and serve the database users.
Note:
An instance also manages other services, such as Oracle XML DB.Figure 3-3 shows two instances, sales and finance, associated with their respective databases.
Figure 3-3 One Instance for each Database
Like services, instances are identified by an instance name, sales and finance in this example. The instance name is specified by the INSTANCE_NAME parameter in the initialization parameter file. The instance name defaults to the Oracle System Identifier (SID) of the instance.
Some hardware architectures allow multiple computers to share access to data, software, or peripheral devices. Oracle Real Application Clusters can take advantage of such architecture by running multiple instances on different computers that share a single physical database.
Figure 3-4 shows an Oracle Real Application Clusters configuration. In this example, two instances, sales1 and sales2, are associated with one database service, sales.us.acme.com.
Figure 3-4 Multiple Instances Associated with a Database
To connect to a database service, clients use a connect descriptor that provides the location of the database and the name of the database service. The following example shows a connect descriptor that enables clients to connect to a database service called sales.us.acme.com.
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.acme.com)))
The address portion of the connect descriptor is actually the protocol address of the listener. To connect to a database service, clients first contact a listener process that typically resides on the database server. The listener receives incoming client connection requests and hands these requests to the database server. Once the connection is established, the client and database server communicate directly.
Much like a business address, the listener is configured to accept requests from clients at a protocol address. This address defines the protocol the listener is listening on and any other protocol specific information. For example, the listener could be configured to listen at the following protocol address:
(DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)))
This example shows a TCP/IP protocol address that specifies the host of the listener and a port number. Clients configured with this same protocol address can send connection requests to this listener.
The connect descriptor also specifies the database service name with which clients seek to establish a connection. The listener knows which services for which it can handle connection requests, because an Oracle database dynamically registers this information with the listener. This process of registration is called service registration. It also provides the listener with information about the database instances and the service handlers available for each instance. Service handlers act as connection points to an Oracle database server. A service handler can be a dispatcher or a dedicated server.
See Also:
"Service Handlers" for a description of these service handler types
"Listener Architecture" for a discussion of how the listener works with service handlers
If connecting to a specific instance of the database is required, clients can also specify the INSTANCE_NAME of a particular instance in the connect descriptor. This feature can be useful if you have an Oracle Real Application Clusters configuration. For example, the following connect descriptor specifies an instance name of sales1 that is associated with sales.us.acme.com.
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.acme.com)
(INSTANCE_NAME=sales1)))
Alternatively, clients that always want to use a particular service handler type can use a connect descriptor that specifies the service handler type. In the following example, a connect descriptor is configured to use a dispatcher for a shared server configuration, as indicated by (SERVER=shared).
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.acme.com)
(SERVER=shared)))
If you want the client to use a dedicated server, you can specify (SERVER=dedicated) in place of (SERVER=shared). If the SERVER parameter is not set, then shared server configuration is assumed. However, the client will use a dedicated server if no dispatchers are available.
When the listener receives the client request, it selects one of the service handlers that were previously registered. Depending on the type of handler selected, the communication protocol used, and the operating system of the database server, the listener performs one of the following actions:
Hands the connect request directly off to a dispatcher.
Sends a redirect message back to the client with the location of the dispatcher or dedicated server process. The client then connects directly to the dispatcher or dedicated server process.
Spawns a dedicated server process and passes the client connection to the dedicated server process.
Once the listener has completed the connection operation for the client, the client communicates with the Oracle database server without the listener's involvement. The listener resumes listening for incoming network sessions.
For some configurations, such as Oracle Real Application Clusters, multiple listeners on multiple nodes can be configured to handle client connection requests for the same database service. In the following example, sales.us.acme.com can connect to sales.us.acme.com using listeners on either sales1-server or sales2-server.
(DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)))
A multiple-listener configuration also enables you to leverage the following failover and load balancing features:
These features can be implemented either singly or in combination with each other.
The connect-time failover enables clients to connect to another listener if the initial connection to the first listener fails. The number of listener protocol addresses determines how many listeners are tried. Without connect-time failover, Oracle Net attempts a connection with only one listener.
The Transparent Application Failover (TAF) feature is a runtime failover for high-availability environments, such as Oracle Real Application Clusters. TAF fails over and reestablishes application-to-service connections. It enables client applications to automatically reconnect to the database if the connection fails and, optionally, resume a SELECT statement that was in progress. The reconnection happens automatically from within the Oracle Call Interface (OCI) library.
The client load balancing feature enables clients to randomize connection requests among the listeners. Oracle Net progresses through the list of protocol addresses in a random sequence, balancing the load on the various listeners. Without client load balancing, Oracle Net progresses through the list of protocol addresses sequentially until one succeeds.
The runtime connection load balancing feature improves connection performance by balancing the number of active connections among multiple dispatchers. In a single-instance environment, the listener selects the least loaded dispatcher to handle the incoming client requests. In an Oracle Real Application Clusters environment, runtime connection load balancing also has the capability to balance the number of active connections among multiple instances.
Due to dynamic service registration, a listener is always aware of all instances and dispatchers regardless of their location. Depending on the load information, a listener decides which instance and, if shared server is configured, which dispatcher to send the incoming client request to.
In a shared server configuration, a listener selects a dispatcher in the following order:
Least-loaded node
Least-loaded instance
Least-loaded dispatcher for that instance
In a dedicated server configuration, a listener selects an instance in the following order:
Least loaded node
Least loaded instance
If a database service has multiple instances on multiple nodes, the listener chooses the least loaded instance on the least loaded node. If shared server is configured, then the least loaded dispatcher of the selected instance is chosen.
This section contains these topics:
Dedicated Server Processes
The shared server architecture uses a dispatcher process to direct client connections to a common request queue. An idle shared server process from a shared pool of server processes picks up a request from the common queue. This approach enables a small pool of server processes to serve a large number of clients. A significant advantage of the shared server model over the dedicated server model is reduced system resources, enabling support of an increased number of users.
The listener uses the dispatcher as a type of service handler to which it can direct client requests. When a client request arrives, the listener performs one of the following actions:
Issues a redirect message to the client, containing the protocol address of a dispatcher. The client then terminates the network session to the listener and establishes a network session to the dispatcher, using the network address provided in the redirect message.
The listener uses direct hand off whenever possible. Redirect messages are used, for example, when dispatchers are remote to the listener.
Figure 3-5 shows the listener handing a connection request directly off to a dispatcher.
The listener receives a client connection request.
The listener hands the connect request directly to the dispatcher.
The client is now connected to the dispatcher.
Figure 3-5 Direct Hand-Off to a Dispatcher
Figure 3–6 shows the role of a dispatcher in a redirected connection.
The listener receives a client connection request.
The listener provides the location of the dispatcher to the client in a redirect message.
The client connects directly to the dispatcher.
Figure 3-6 Redirected Connection to a Dispatcher
In a dedicated server configuration, the listener starts a separate dedicated server process for each incoming client connection request dedicated to servicing the client. Once the session is complete, the dedicated server process terminates. Because a dedicated server process has to be started for each connection, this configuration may require more system resources than shared server configurations.
A dedicated server process is a type of service handler that the listener starts when it receives a client request. To complete a client/server connection establishment, one of the following actions occurs:
The dedicated server inherits the connection request from the listener.
The dedicated server informs the listener of its listening protocol address. The listener passes the protocol address to the client in a redirect message and terminates the connection. The client connects to the dedicated server directly using the protocol address.
Note:
One of the options is selected based on the operating system and the transport protocol.If the client and database server exist on the same computer, a client connection can be passed directly to a dedicated server process without going through the listener. The application initiating the session spawns a dedicated server process for the connection request. This happens automatically if the application that is used to start the database is on the same computer as the database.
Note:
In order for remote clients to connect to dedicated servers, the listener and the database instance must be running on the same computer.Figure 3-7 shows the listener passing a client connection request to a dedicated server process.
The listener receives a client connection request.
The listener starts a dedicated server process, and the dedicated server inherits the connection request from the listener.
The client is now connected directly to the dedicated server.
Figure 3-7 Connection to a Dedicated Server Process
Figure 3-8 shows the role of a dedicated server in a redirected connection.
The listener receives a client connection request.
The listener starts a dedicated server process.
The listener provides the location of the dedicated server process to the client in a redirect message.
Figure 3-8 Redirected Connection to a Dedicated Server Process
Users initiate a connection request by providing a connect string. A connect string includes a username and password, along with a connect identifier. A connect identifier can be the connect descriptor itself or a name that resolves to a connect descriptor. One of the most common connect identifiers is a net service name, a simple name for a service. The following examples demonstrate one connect string that uses a complete connect descriptor as the connect identifier and another connect string that uses net service name sales as the connect identifier.
CONNECT scott/tiger@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=sales-server1)(PORT=1521)) (CONNECT_DATA=(SERVICE_NAME=sales.us.acme.com))) CONNECT scott/tiger@sales
When net service name sales is used, connection processing takes place by first mapping sales to the connect descriptor. This mapped information is stored in one or more repositories of information that are accessed with naming methods.
The process for establishing a client session with the aid of a naming method is as follows:
The client initiates a connect request by providing a connect identifier.
The connect identifier is resolved to a connect descriptor by a naming method. This information is returned to the client.
The client makes the connection request to the address provided in the connect descriptor.
A listener receives the request and directs it to the appropriate database server.
The connection is accepted by the database server.
Oracle Net provides support for following naming methods:
Note:
Besides connect descriptors, you can use naming methods to map a name to a protocol address or protocol address list.The local naming method stores net service names and their connect descriptors in a localized configuration file named tnsnames.ora.
See Also:
"Configuring the Local Naming Method"The directory naming method stores connect identifiers in a centralized LDAP-compliant directory server to access a database service.
The easy connect naming method enables clients to connect to an Oracle database server by using a TCP/IP connect string consisting of a host name and optional port and service name:
CONNECT username/password@host[:port][/service_name]
The easy naming method requires no configuration.
See Also:
"Using the Easy Connect Naming Method"The external naming method stores net service names in a supported non-Oracle naming service. These supported third-party services include:
Network Information Service (NIS) External Naming
Distributed Computing Environment (DCE) Cell Directory Services (CDS)
See Also:
"Configuring External Naming Methods"
|
 Copyright © 2002, 2005, Oracle. All rights reserved. Legal Notices |
|