Net8(TM) Administrator's Guide Release 8.0.3 A51576_01

Library Product Contents Index

2
Understanding Net8

Net8 uses the Transparent Network Substrate (TNS) and industry-standard networking protocols to connect a client to a server and establish an Oracle session.

This chapter describes TNS and the role it plays in distributed systems. It also explains how Net8 interacts with TNS to perform basic connectivity and transport operations. Net8 extends this functionality through applications including Oracle Names and Oracle Connection Manager. This chapter contains the following sections:

• Section 2.1, "Net8 Operations"
• Section 2.2, "Net8 and the Transparent Network Substrate (TNS)"
• Section 2.3, "Net8 Architecture"
• Section 2.4, "Net8 and the Network Listener"
• Section 2.5, "Oracle Names"
• Section 2.6, "Oracle Connection Manager"

2.1 Net8 Operations

Net8 is responsible for enabling communications between the cooperating partners in an Oracle distributed transaction, whether they be client-server or server-server. Specifically, Net8 provides three basic networking operations:

• Connect Operations
• Data Operations
• Exception Operations

2.1.1 Connect Operations

Net8 supports two types of connect operations:

• Connecting to Servers (open)
• Disconnecting from Servers (close)

2.1.1.1 Connecting to Servers

Users initiate a connect request by passing information such as a username and password along with a short name for the database service that they wish to connect. That short name, called a service name, is mapped to a network address contained in a connect descriptor. Depending upon your specific network configuration, this connect descriptor may be stored in one of the following:

• a local names configuration file called TNSNAMES.ORA
• a Names Server for use by Oracle Names
• a native naming service such as NIS or DCE CDS

Note: If the network includes Oracle Names, you do not need a local names (TNSNAMES.ORA) configuration file. The service names and associated connect descriptors are stored in a Names Server. Similarly, if an Oracle Native Naming Adapter such as NIS or DCE CDS is being used, this information is stored and retrieved from that native name service.

Net8 coordinates its sessions with the help of a network listener. A listener is a process that is set up specifically to receive and respond to client connection requests for a database instance. Net8 makes the connection request on behalf of a client. For more information about how a listener responds to connect requests, refer to "Net8 and the Network Listener".

2.1.1.2 Disconnecting from Servers

Requests to disconnect from the server can be initiated in the following ways:

• user-initiated disconnect
• additional connection request
• abnormal connection termination
• timer-initiated disconnect

User-Initiated Disconnect

A user can request a disconnection from the server when a client-server transaction completes. A server can also disconnect from a second server when all server-server data transfers have been completed, and no need for the link remains.

Additional Connection Request

If a client application is connected to a server and requires access to another user account on the same or other server, most Oracle tools will first disconnect the application from the server to which it is currently connected. Once the disconnection is completed, a connection request to the new user account on the appropriate server is initiated.

Abnormal Connection Termination

Other components will occasionally disconnect or abort communications without giving notice to Net8. In this event, Net8 will recognize the failure during its next data operation, and clean up client and server operations, effectively disconnecting the current operation.

Timer Initiated Disconnect or Dead Connection Detection

Dead connection detection is a feature that allows Net8 to identify connections that have been left hanging by the abnormal termination of a client. On a connection with dead connection detection enabled, a small probe packet is sent from server to client at a user-defined interval (usually several minutes). If the connection is invalid (usually due to the client process or machine being unreachable), the connection will be closed when an error is generated by the send operation, and the server process will terminate the connection.

This feature minimizes the waste of resources by connections that are no longer valid. It also automatically forces a database rollback of uncommitted transactions and locks held by the user of the broken connection.

2.1.2 Data Operations

Net8 supports four sets of client-server data operations:

• send data synchronously
• receive data synchronously
• send data asynchronously
• receive data asynchronously

On the client side, a SQL dialogue request is forwarded using a send request in Net8. On the server side, Net8 processes a receive request and passes the data to the database. The opposite occurs in the return trip from the server.

Basic send and receive requests are synchronous. When a client initiates a request, it waits for the server to respond with the answer. It can then issue an additional request.

Net8 adds the capability to send and receive data requests asynchronously. This capability was added to support the Oracle shared server, also called a multi-threaded server, which requires asynchronous calls to service incoming requests from multiple clients.

2.1.3 Exception Operations

Net8 supports three types of exception operations:

• initiate a break over the connection
• reset a connection for synchronization after a break
• test the condition of the connection for incoming break

The user controls only one of these three operations, that is, the initiation of a break. When the user presses the Interrupt key ([Ctrl-C] on some machines), the application calls this function. Additionally, the database can initiate a break to the client if an abnormal operation occurs, such as during an attempt to load a row of invalid data using SQL*Loader.

The other two exception operations are internal to products that use Net8 to resolve network timing issues. Net8 can initiate a test of the communication channel, for example, to see if new data has arrived. The reset function is used to resolve abnormal states, such as getting the connection back in synchronization after a break operation has occurred.

2.2 Net8 and the Transparent Network Substrate (TNS)

Net8 uses the Transparent Network Substrate (TNS) and industry-standard networking protocols to accomplish its basic functionality. TNS is a foundation technology that is built into Net8 providing a single, common interface to all industry-standard protocols.

With TNS, peer-to-peer application connectivity is possible where no direct machine-level connectivity exists. In a peer-to-peer architecture, two or more computers (called nodes when they are employed in a networking environment) can communicate with each other directly, without the need for any intermediary devices. In a peer-to-peer system, a node can be both a client and a server.

A review of how Oracle clients and servers operate and communicate with each other will help you to understand what TNS is and how it works with Net8 to establish Oracle sessions.

2.3 Net8 Architecture

Oracle networking environments are based on two concepts:

• Distributed Processing
• Stack Communications

Distributed Processing

Oracle databases and client applications operate in what is known as a distributed processing environment. Distributed or cooperative processing involves interaction between two or more computers to complete a single data transaction. Applications such as an Oracle tool act as clients requesting data to accomplish a specific operation. Database servers store and provide the data.

In a typical network configuration, clients and servers may exist as separate logical entities on separate physical machines. This configuration allows for a division of labor where resources are allocated efficiently between a client workstation and the server machine. Clients normally reside on desktop computers with just enough memory to execute user friendly applications, while a server has more memory, disk storage, and processing power to execute and administer the database. Figure 2-1 depicts a typical client-server relationship.

Figure 2-1 Typical Client-Server Relationship

Distributed Databases

This type of client-server architecture also enables you to distribute databases across a network. A distributed database is a network of databases stored on multiple computers that appears to the user as a single logical database. Distributed database servers are connected by a database link, or path from one database to another. One server uses a database link to query and modify information on a second server as needed, thereby acting as a client to the second server.

2.3.1 Stack Communications

The concept of distributed processing relies on the ability of computers separated by both design and physical location to communicate and interact with each other. This is accomplished through a process known as stack communications.

Stack communications are defined by the Open System Interconnection (OSI) reference model. In the OSI model, communication between separate computers occurs in a stack-like fashion with information passing from one node to the other through several layers of code. Figure 2-2 depicts a typical OSI Protocol Communications Stack.

Figure 2-2 OSI Protocol Communications Stack

Information descends through layers on the client side where it is packaged for transport across a network medium in a manner that it can be translated and understood by corresponding layers on the server side.

A typical OSI protocol communications stack will contain seven such layers:

• Application - this is the OSI layer closest to the user, and as such is dependent on the functionality requested by the user. For example, in a database environment, a Forms application may attempt to initiate communication in order to access data from a server.
• Presentation - ensures that information sent by the application layer of one system is readable by the application layer of another system. This includes keeping track of syntax and semantics of the data transferred between the client and server. If necessary, the presentation layer translates between multiple data representation formats by using a common data format.
• Session - as its name suggests, establishes, manages, and terminates sessions between the client and server. This is a virtual pipe that carries data requests and responses. The session layer manages whether the data traffic can go in both directions at the same time (referred to as asynchronous), or in only one direction at a time (referred to as synchronous).
• Transport - implements the data transport ensuring that the data is transported reliably.
• Network - ensures that the data transport is routed through optimal paths through a series of interconnected subnetworks.
• Link - provides reliable transit of data across a physical link.
• Physical - defines the electrical, mechanical, and procedural specifications for activating, maintaining and deactivating the physical link between client and server.

2.3.2 Stack Communications in an Oracle networking environment

Stack communications allow Oracle clients and servers to share, modify, and manipulate data between themselves. The layers in a typical Oracle communications stack are similar to those of a standard OSI communications stack.

2.3.2.1 Client-Server Interaction

In an Oracle client-server transaction, information passes through the following layers:

• Client Application
• Oracle Call Interface (OCI)
• Two Task Common
• Net8
• Oracle Protocol Adapters
• Network Specific Protocols

Figure 2-3 depicts a typical communications stack in an Oracle networking environment.

Figure 2-3 Typical Communications Stack in an Oracle environment

Client Application

Oracle client applications provide all user-oriented activities, such as character or graphical user display, screen control, data presentation, application flow, and other application specifics. The application identifies database operations to send to the server and passes them through to the Oracle Call Interface (OCI).

Oracle Call Interface (OCI)

The OCI code contains all the information required to initiate a SQL dialogue between the client and the server. It defines calls to the server to:

• parse SQL statements for syntax validation
• open a cursor for the SQL statement
• bind client application variables into the server shared memory
• describe the contents of the fields being returned based on the values in the server's data dictionary
• execute SQL statements within the cursor memory space
• fetch one or more rows of data into the client application
• close the cursor

The client application uses a combination of these calls to request activity within the server. OCI calls can be combined into a single message to the server, or they may be processed one at a time through multiple messages to the server, depending on the nature of the client application. Oracle products attempt to minimize the number of messages sent to the server by combining many OCI calls into a single message to the server. When a call is performed, control is passed to Net8 to establish the connection and transmit the request to the server.

Two-Task Common

Two-Task Common provides character set and data type conversion between different character sets or formats on the client and server. This layer is optimized to perform conversion only when required on a per connection basis.

At the time of initial connection, Two Task Common is responsible for evaluating differences in internal data and character set representations and determining whether conversions are required for the two computers to communicate.

Net8

Net8 provides all session layer functionality in an Oracle communications stack. It is responsible for establishing and maintaining the connection between a client application and server, as well as exchanging messages between them. Net8 itself has three component layers that facilitate session layer functionality:

• Network Interface (NI) - This layer provides a generic interface for Oracle clients, servers, or external processes to access Net8 functions. The NI handles the "break" and "reset" requests for a connection.
• Network Routing (NR)/ Network Naming (NN)/ Network Authentication (NA) - NR provides routing of the session to the destination. This may include any intermediary destinations or `hops,' on the route to the server destination. NN resolves aliases to a Net8 destination address. NA negotiates any authentication requirement with the destination.
• Transparent Network Substrate (TNS) - TNS is an underlying layer of Net8 providing a common interface to industry standard protocols. TNS receives requests from Net8, and settles all generic machine-level connectivity issues, such as: the location of the server or destination (open, close functions); whether one or more protocols will be involved in the connection (open, close functions); and how to handle interrupts between client and server based on the capabilities of each (send, receive functions). The generic set of TNS functions (open, close, send, receive) passes control to an Oracle Protocol Adapter to make a protocol-specific call. Additionally, TNS supports encryption and sequenced cryptographic message digests to protect data in transit.

Oracle Protocol Adapters

Oracle Protocol Adapters are responsible for mapping TNS functionality to industry-standard protocols used in the client-server connection. Each adapter is responsible for mapping the equivalent functions between TNS and a specific protocol.

Network-Specific Protocols

All Oracle software in the client-server connection process require an existing network protocol stack to make the machine-level connection between the two machines. The network protocol is responsible only for getting the data from the client machine to the server machine, at which point the data is passed to the server-side Oracle Protocol Adapter.

Server-Side Interaction

Information passed from a client application across a network protocol is received by a similar communications stack on the server side. The process stack on the server side is the reverse of what occurred on the client side with information ascending through communication layers. The one operation unique to the server side is the act of receiving the initial connection through the network listener.

The following components above the Net8 session layer are different from those on the client side:

• Oracle Program Interface (OPI)
• Oracle Server

Oracle Program Interface (OPI)

The OPI performs a complementary function to that of the OCI. It is responsible for responding to each of the possible messages sent by the OCI. For example, an OCI request to fetch 25 rows would have an OPI response to return the 25 rows once they have been fetched.

Oracle Server

The Oracle Server side of the connection is responsible for receiving dialog requests from the client OCI code and resolving SQL statements on behalf of the client application. Once received, a request is processed and the resulting data is passed to the OPI for responses to be formatted and returned to the client application.

2.3.3 Server-to-Server Interaction

When two servers communicate to complete a distributed transaction, the process, layers, and dialogues are the same as in the client-server scenario, except that there is no client application. The server has its own version of OCI, called the Network Program Interface (NPI). The NPI interface performs all of the functions that the OCI does for clients, allowing a coordinating server to construct SQL requests for additional servers.

Figure 2-4 depicts a typical server-server interaction.

Figure 2-4 Server-Server Interaction

2.4 Net8 and the Network Listener

The network listener is a single process or task included with TNS specifically to receive connection requests on behalf of an application. The network listener is available for all standard transport protocols supported by TNS. In addition, there are protocols that have application generic listeners or connection acceptance methods, such as DECnet and APPC/LU6.2, that may receive TNS connections. For more information on Net8 connections with a native connection acceptance method, refer to the Oracle operating system-specific documentation for that protocol and platform.

The network listener supports multiple server processes and/or mid-tier application processes (either Oracle provided or user provided through Net8 OPEN). Correspondingly, a server may have more than one listener.

2.4.1 Establishing Connections with the Network Listener

Net8, as a TNS-based product, establishes a session with a server with the help of a network listener. Listeners are configured to "listen on" an address specified in a listener configuration file (called LISTENER.ORA) for a database instance. Once started, the listener will receive client connect requests on behalf of a database, and respond in one of three ways:

• Bequeath the session to a new dedicated server process
• Redirect to an existing server process (such as a dispatcher or prestarted dedicated server process)
• Refuse the session

Figure 2-5 shows the role of the network listener in a Net8 connection to a server.

Figure 2-5 Network listener in a typical Net8 connection

2.4.1.1 Bequeathed Sessions to Dedicated Server Processes

If the listener and server exist on the same node, the listener may create or `spawn' dedicated server processes as connect requests are received. Dedicated server processes are committed to one session only and exist for the duration of that session. The sequence of events that occur when the listener creates a dedicated server process and passes or `bequeaths' control of a session to it is as follows:

1. The listener is started and listens on an address specified in a listener configuration file (LISTENER.ORA).
2. A client connects to the listener with the network address.
3. The listener receives the session request, and determines if the client's request may be serviced. If not, the listener refuses the session and then resumes at Step 5.
4. The listener spawns a new dedicated server process to serve the incoming session, and bequeaths the session to that server process. Once the session is established, data flows directly between the client and dedicated server process.
5. The listener continues listening for incoming sessions.

When a client disconnects, the dedicated server process associated with the client closes.

2.4.1.2 Redirected Sessions to Existing Server Processes

Alternatively, Net8 may redirect the request to an existing server process. It does this by sending the address of an existing server process back to the client. The client will then resend its connect request to the server address provided.

Existing server processes include:

• Prestarted or Prespawned Dedicated Server Processes by the listener
• Dispatcher Processes created outside the listener process

Prespawned Dedicated Server Processes

Net8 provides the option of automatically creating dedicated server processes before the request is received. These processes last for the life of the listener, and can be reused by subsequent connection requests. The use of prespawned dedicated server processes requires specification in a listener configuration file.

The sequence of events that occurs when using prespawned dedicated server processes to service client connection requests is as follows:

1. The listener is started and listens on an address specified in a listener configuration file.
2. The listener then spawns a series of dedicated server processes until it reaches the specified pool size for each Oracle System Identifier (SID) defined in its configuration file.
3. Each spawned server process performs a partial address listen and provides the listener with the partial address that it is listening on. The listener initially marks all prespawned servers as idle.

Note: A partial address listen is where the server process listens, but informs the underlying protocol stack that it has no preference as to the specific address it will listen on. As a result, many protocol stacks will choose a free listening address and automatically assign this to the requesting server process.

4. The client sends a connect request to the listener.
5. The listener receives the session request, and determines if the client's request may be serviced. If not, the listener refuses the session and then resumes at Step 9.
6. The listener issues a redirect message to the client containing one of the network addresses of the prespawned servers. The listener logs that server as active.
7. The client dissolves the session to the listener and establishes a session to the prespawned server using the address provided in the redirect message.
8. The listener spawns another server process to replace the active prespawned server (provided a value called PRESPAWN_MAX in the listener configuration file is greater than the number of prespawned server processes active and idle).
9. The listener continues listening for incoming sessions.

The above sequence of events continues until the PRESPAWN_MAX is reached, at which point the listener stops spawning new dedicated server processes.

When clients disconnect, the prespawned dedicated server process associated with the client returns to the idle pool. It then waits a specified length of time to be assigned to another client. If no client is handed to the prespawned server before the timeout expires, the prespawned server shuts down.

Dispatcher Server Processes

A dispatcher server process enables many clients to connect to the same server without the need for a dedicated server process for each client. It does this with the help of a dispatcher which handles and directs multiple incoming session requests to the shared server.

When an Oracle server has been configured as a multi-threaded server, incoming sessions are always routed to the dispatcher unless either the session specifically requests a dedicated server or no dispatchers are available. The sequence of events that occurs with the dispatcher server is as follows:

1. The listener is started and listens on either a default address or the addresses specified in the its configuration file.
2. A database instance starts. Dispatchers start according to the configuration parameters in the initialization parameter file. Each dispatcher then performs a listen on the address assigned to it.
3. Each dispatcher's address is registered. When the listener is not listening on its default address, the listener's network name may be specified in the database initialization file (INIT.ORA). The name may resolve to more than one such address if multiple listeners are used.

Once the dispatcher addresses are registered, the listener can redirect incoming connect requests to them.

• If step 2 is performed before step 1, the dispatchers will not be able to contact the listener in step 3. If this occurs, there may be a delay as the dispatcher attempts to connect to the listener. If a connect request comes in a timeframe where no dispatchers are registered, these requests may be handled through prespawned dedicated or newly spawned dedicated server processes or be rejected.

The listener and the Oracle dispatcher server are now ready to receive incoming sessions.

Once the listener and the dispatcher server have been started, the session activity continues as follows:

1. The client connects to the listener with the network address.
2. The listener receives the connect request, and determines if the client's request may be serviced. If not, the listener refuses the session and then resumes at Step 6.
3. The listener issues a redirect message to the client containing the network address of the least-used dispatcher for the shared server.
4. The client dissolves the session to the listener and establishes a session to the shared server using the network address provided in the redirect message.
5. The dispatcher updates the listener with the new load value because of the presence of the new session. This allows the listener to balance the incoming session requests between dispatchers running on the same protocol.
6. The listener resumes listening for incoming sessions.

When clients disconnect, the shared server associated with the client stays active and processes other incoming requests.

2.4.1.3 Refused Sessions

The network listener will refuse a session in the event that it does not know about the server being requested, or if the server is unavailable. It refuses the session by generating and sending a refuse response packet back to the client.

2.5 Oracle Names

Oracle Names is a distributed naming service developed for Oracle environments to facilitate the setup and administration of service names and addresses. Oracle Names does this by establishing and maintaining an integrated system of Names Servers which store service names and map them to their corresponding addresses on the network.

Oracle Names version 8 includes the following features:

• dynamic service registration
• client discovery of names servers
• client cache daemon process

2.5.1 Dynamic Service Registration

Information including service names and addresses are entered into or registered with a Names Server through a feature called dynamic service registration. Listeners configured to find a Names Server will forward information about the database instances they listen for to any available Names Server.

Once a service is registered, Oracle Names stores its name and address in one of two places:

• cache replication
• a database

Network names and addresses are shared among other version 8 Names Servers in the region. In a small network with just a few Names Servers, replication to the data cache of the Names Servers may be sufficient. However, in a large network with many Names Servers, the use of a database server is safer and more efficient. For more information on configuring a database as a repository for Names Server information, refer to the section titled "Using a Database as a Names Repository in the Region" in Chapter 5, "Configuring Network Services".

2.5.1.1 What Data is Stored by Oracle Names

Table 2-1 describes the type of data stored in a Names Server.

Table 2-1 Data Stored by Oracle Names

2.5.1.2 Registration Using Oracle Names Control Utility

You may also register information with a Names Server manually by issuing a REGISTER command through Oracle Names Control (NAMESCTL). For more information about this command, refer to REGISTER in the Oracle Names Control Utility (NAMESCTL) section of Appendix A, "Control Utility Reference".

2.5.2 Client/Server Discovery of Names Servers

Clients and servers discover Names Servers when a user or database administrator executes a REORDER_NS command from Oracle Names Control (NAMESCTL) on the client and/or server node. When this command is given, NAMESCTL will proceed as follows:

1. Contacts a Names Server by using the address specified either in:
1. the command itself
2. a Preferred Names Server parameter in the client or server's local profile (SQLNET.ORA file)
3. an existing Names Server List
4. a well-known Names Server
2. If a Names Server is found, NAMESCTL sends a query for all the Names Servers in the local region.
3. Sends a 'ping' to each of these servers to determine the time it takes for each Names Server to respond.
4. Sorts a list of the Names Servers in increasing order of response time.
5. Creates or replaces an existing Names Server List file with the sorted list of names and addresses.

For more information, refer to the REORDER_NS command in the Oracle Names Control Utility (NAMESCTL) of Appendix A, "Control Utility Reference".

2.5.3 Client Cache Daemon Process

Oracle Names version 8 provides a client cache daemon process that allows a client on most platforms to store information retrieved from a Names Server in its local cache. Whenever a client makes a subsequent connection request, it first checks its local cache for the address information. If the information is located, and if it has not exceeded a specified time to live (TTL), the client will use the information to connect to a server, saving the time it would normally take to re-query the Names Server.

The local client-side cache is particularly advantageous if at any time a Names Server is not available. In this case, the local client-side cache has a current list of recently accessed services.

To start the client cache daemon process, issue a START_CLIENT_CACHE command from Oracle Names Control. For more information about the START_CLIENT_CACHE command, refer to "Oracle Names Control Utility (NAMESCTL)" in Appendix A, "Control Utility Reference".

2.6 Oracle Connection Manager

Oracle Connection Manager is a new application that is provided with the Oracle8 Enterprise Edition. It provides support for the following features:

• Concentration
• Network Access Control
• Multiple Protocol Support

2.6.1 Concentration

Oracle Connection Manager enables you to take advantage of Net8's multiplexing feature to funnel or concentrate multiple logical client sessions through a single transport connection to a server destination. Concentration reduces the demand on resources needed to maintain multiple connections between two processes by enabling the server to use fewer connection end points for incoming requests. This enables you to increase the total number of sessions that a server can handle. By using multiple Oracle Connection Managers, it is possible for thousands of concurrent users to connect to a server.

Figure 2-6 depicts how concentration works.

Figure 2-6 Concentration through Oracle Connection Manager

You can only enable multiplexing if the following occur:

• Each session is trying to communicate with the same multi-threaded server.
• Each session is started from the same Oracle Connection Manager.
• The feature is enabled on both nodes.

For information on configuring concentration, refer to the section titled, Configuring Oracle Connection Manager in Chapter 5, "Configuring Network Services".

2.6.2 Network Access Control

Oracle Connection Manager also includes a feature which you can use to control client access to designated servers in a TCP/IP environment. You may configure filtering rules allowing specific clients access to a server based on the following criteria:

• Source hostname(s) or IP address(es) for clients
• Destination hostname(s) or IP address(es) for servers
• Destination database server identifier

Oracle Connection Manager will forward a client's session request if a client meets the requirements of any "accept" rules. Conversely, it will refuse a client's session request if the client meets the requirements of any "reject" rules. If neither of the two is true, Oracle Connection Manager will refuse the session.

For information on configuring network access control, refer to "Specifying Network Access Control Rules" in Chapter 5, "Configuring Network Services".

2.6.3 Multiple Protocol Support

Oracle Connection Manager also provides multiple protocol support enabling a client and server with different networking protocols to communicate with each other. This feature replaces functionality previously provided by the Oracle MultiProtocol Interchange with SQL*Net version 2.

Net8 can traverse as many networking protocol stacks as can be installed and supported. In fact, the number of networking protocols supported is limited only by those restrictions imposed by the specific node's hardware, memory and operating system. Figure 2-7 shows how a client in an SPX/IPX network can route its session to a server over a TCP/IP transport through Oracle Connection Manager.

Figure 2-7 Multiprotocol Support through Oracle Connection Manager

For information on configuring multiple protocol support, refer to the section titled, Enabling Multiprotocol Support in Chapter 5, "Configuring Network Services".

2.6.4 Routing Sessions Through Oracle Connection Manager

Client sessions are routed through Oracle Connection Manager by:

• Starting Oracle Connection Manager on a network with an Oracle Names Server; or
• Specifying a network source route in a local naming configuration file (TNSNAMES.ORA).

If client sessions are routed through Oracle Connection Manager, the following occurs:

1. If on a network using Oracle Names, Oracle Connection Manager will initiate an administration process when it starts. This process retrieves all listener and server addresses on the network from a Names Server, then creates a source route address to each listener through Oracle Connection Manager. It then registers the source route address with the Names Server.

Note: A source route address is a path of addresses that the session needs to follow in order to reach its destination. This usually consists of Oracle Connection Manager's listening address followed by the server's listening address.

2. When a client requests a connection, it uses the source route address provided either by the Names Server or its local names (TNSNAMES.ORA) configuration file.
3. The connect request is routed to Oracle Connection Manager's listening address.
4. Oracle Connection Manager's main process receives the connect request, verifies if the client meets all access control rules (if rules exist), then forwards the request to the destination server.

2.6.5 Using Oracle Connection Manager with Oracle Names

You may use Oracle Connection Manager with a Names Server in one of the following scenarios:

1. Single protocol in a Names Server region - Each node in the network has the same protocol installed. This network is in a single region served by one or more Names Servers.
2. Multiple protocols in a Names Server region - More than one protocol exists in a single region network served by Names Servers. This type of network requires that you configure the Names Servers for each protocol. Once the Names Servers can access each other, then the destination addresses are "known" across the network.

Figure 2-8 describes how Oracle Connection Manager facilitates the scenarios listed above.

Figure 2-8 Oracle Connection Manager between different protocols

Any client with protocol P2 can connect to the server S1, by routing its session through Oracle Connection Manager, C1. Oracle Connection Manager is responsible for translating the request to protocol P1. Similarly, clients in protocol P1 that want to concentrate sessions or get beyond a firewall can route through Oracle Connection Manager to the server S1.

In this example, Oracle Connection Manager's administration process queries both Name Servers N1 and N2. After the administration process receives the Names Server cache, Oracle Connection Manager constructs a source route from any potential client to every server. After the administration process registers all possible source route addresses with the Names Servers, then all clients in both regions can access either database server, S1 or S2, provided that all access control rules are followed.

For information on configuring source route addresses in a local names configuration file (TNSNAMES.ORA), refer to Chapter 4, "Configuring Network Clients".

Prev Next

Copyright © 1997 Oracle Corporation. All Rights Reserved.

Library Product Contents Index