| Oracle® Database Net Services Administrator's Guide 10g Release 1 (10.1) Part Number B10775-01 |
|
|
View PDF |
| Oracle® Database Net Services Administrator's Guide 10g Release 1 (10.1) Part Number B10775-01 |
|
|
View PDF |
This chapter describes the architecture of Oracle Net, the listener, shared server, dedicated server, and Oracle Connection Manager.
This chapter contains these topics:
|
See Also: Chapter 1, " Networking Challenges in the Internet Age" for an introductory level overview of Oracle Net architecture |
The primary function of Oracle Net is to establish and maintain connections between a client application and an Oracle database server. Oracle Net is comprised of several communication layers that enable clients and database servers to share, modify, and manipulate data.
This section contains these topics:
Figure 4-1 illustrates the various layers on the client and on the database server after a connection has been established.
|
Note: The SDP protocol is supported but is not represented in this figure. |
This communication architecture is based on the Open Systems Interconnection (OSI) 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, including:
Figure 4-2 shows how Oracle Net software—Oracle Net Foundation layer and Oracle Protocol Support—fits into the session layer of the OSI model.
As shown in Figure 4-1, the client/server stack is comprised of the following:
During a session with the database, the client uses Oracle Call Interface (OCI) to interact with the database server. OCI is a software component that provides an interface between the client application and the SQL language the database server understands.
Character set differences can occur if the client and database server are running on different operating systems. The presentation layer resolves any differences. It is optimized for each connection to perform conversion only when required.
The presentation layer used by client/server applications is Two-Task Common (TTC). TTC provides character set and data type conversion between different character sets or formats on the client and database server.
At the time of initial connection, TTC is responsible for evaluating differences in internal data and character set representations and determining whether conversions are required for the two computers to communicate.
The Oracle Net foundation layer is responsible for establishing and maintaining the connection between the client application and database server, as well as exchanging messages between them. The Oracle Net foundation layer is able to perform these tasks because of a technology called Transparent Network Substrate (TNS). TNS provides a single, common interface functioning over all industry-standard protocols. In other words, TNS enables peer-to-peer application connectivity. 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.
On the client side, the Oracle Net foundation layer receives client application requests and resolves all generic computer-level connectivity issues, such as:
The location of the database server or destination
Whether one or more protocols are involved in the connection
How to handle interrupts between client and database server based on the capabilities of each
On the server side, the Oracle Net foundation layer performs the same tasks as it does on the client side and also works with the listener to receive incoming connection requests.
In addition to establishing and maintaining connections, the Oracle Net foundation layer communicates with naming methods to resolve names and uses security services to ensure secure connections.
Positioned between the Oracle Net foundation layer and the network protocol layer, the Oracle protocol support layer is responsible for mapping TNS functionality to industry-standard protocols used in the client/server connection. This layer supports the following network protocols:
TCP/IP
TCP/IP with SSL
Named Pipes
SDP
All Oracle software in the client/server connection process requires an existing network protocol stack to establish the computer-level connection between the two computers for the transport layer. The network protocol is responsible for transporting data from the client computer to the database server computer, at which point the data is passed to the serverside Oracle protocol support layer.
The Transmission Control Protocol/Internet Protocol (TCP/IP) is the de facto standard communication protocol used for client/server conversation over a network.
The TCP/IP with Secure Sockets Layer (SSL) protocol enables an Oracle application on a client to communicate with remote Oracle databases through TCP/IP and SSL. Oracle Advanced Security is required in order to use TCP/IP with SSL.
SSL stores authentication data, such as certificates and private keys, in an Oracle Wallet. When the client initiates a connection to the database server, SSL performs a handshake between the two using the certificate. During the handshake, the following processes occur:
The client and database server negotiate a cipher suite—a set of authentication, encryption, and data integrity types—to apply to the messages they exchange.
Depending on its configuration, the database server sends its certificate to the client in a message encrypted with the client's public key. The database server may also send a request for the client's certificate in the same message. The client decrypts this message by using its own private key, then verifies that the database server's certificate bears the certificate authority's signature.
If required, the client may send the user's certificate to the database server. The certificate ensures that the user's information is correct and that the public key actually belongs to that user.
The database server checks the user's certificate to verify that it bears the certificate authority's signature.
The Named Pipes protocol is a high-level interface providing interprocess communications between clients and database servers using distributed applications. One severside process creates the pipe, and the other clientside process opens it by name. What one side writes, the other can read, and vice versa. Named Pipes is specifically designed for PC LAN environments.
Named Pipes enables client/server conversation over a network using Named Pipes. This combination of Oracle products enables an Oracle application on a client to communicate with remote Oracle databases through Named Pipes (if the Oracle database is running on a host system that supports network communication using Named Pipes).
The Sockets Directory Protocol (SDP) is an industry-standard wire protocol between Infiniband network peers. When SDP is used over an Infiniband network, it reduces the overhead of TCP/IP by eliminating intermediate replication of data and transferring most of the messaging burden away from the CPU and onto the network hardware.
Information passed from a client application across a network protocol is received by a similar communications stack on the database server side. The process flow on the database server side is the reverse of the process flow on the client side, with information ascending through the communication layers.
Instead of OCI, the database server uses Oracle Program Interface (OPI). For each statement sent from OCI, OPI provides a response. For example, an OCI request to fetch 25 rows would elicit an OPI response to return the 25 rows once they have been fetched.
The Oracle Java Database Connectivity (JDBC) Drivers provide Java applications access to an Oracle database. Oracle offers two JDBC drivers.
JDBC OCI Driver driver is a level 2 JDBC driver which is used by client/server Java applications. The JDBC OCI driver converts JDBC invocations to calls to OCI which are then sent over Oracle Net to the Oracle database server.
JDBC Thin Driver is a level 4 driver which is used by Java applets. The JDBC Thin driver establishes a direct connection to the Oracle database server over Java sockets. Access to the database is assisted with a lightweight implementation of TTC and Oracle Net.
Figure 4-3 shows the stack communication layers used by JDBC drivers.
|
Note: The SDP protocol is supported but is not represented in this figure. |
The JDBC OCI driver uses a communication stack similar to a standard client/server communication stack. The JDBC Thin driver uses a Java implementation of the Oracle Net foundation layer called JavaNet and a Java implementation of TTC called JavaTTC.
In addition to the TTC presentation, the Oracle database server supports many other presentations that can be used for Web clients accessing features inside the database. The listener facilitates this by supporting any presentation requested by the database.
For example, Figure 4-4 shows the stack communication layers used in an HTTP or FTP connection to Oracle XML DB in the Oracle Database 10g instance. WebDAV connections use the same stack communication layers as HTTP and FTP.
The database server receives an initial connection from a client application through the listener. The listener is an application positioned on top of the Oracle Net foundation layer. Figure 4-5 illustrates the various layers on the client and database server during an initial connection.
|
Note: The SDP protocol is supported but is not represented in this figure. |
The listener brokers client requests, handing off the requests to the Oracle database server. Every time a client requests a network session with a database server, a listener receives the initial request.
Each listener is configured with one or more protocol addresses that specify its listening endpoints. Clients configured with one of these protocol addresses can send connection requests to the listener.
Once a client request has reached the listener, the listener selects an appropriate service handler to service the client's request and forwards the client's request to it. The listener determines if a database service and its service handlers are available through service registration. During service registration, the PMON process—an instance background process—provides the listener with information about the following:
Names of the database services provided by the database
Name of the instance associated with the services and its current and maximum load
Service handlers (dispatchers and dedicated servers) available for the instance, including their type, protocol addresses, and current and maximum load
This information enables the listener to direct a client's request appropriately Figure 4-6 shows instances registering information with listeners. Note that it does not represent all the information that can be registered.
Optionally, listening endpoints—port numbers—can be dynamically registered with the listener. For example, with Oracle XML DB, HTTP, FTP, and WebDAV listening endpoints are registered with the listener.
If the listener is not running when an instance starts, PMON is not able to register the service information. PMON attempts to connect to the listener periodically, however, it may take up to 60 seconds before PMON registers with the listener after it has been started. To initiate service registration immediately after the listener is started, use the SQL statement ALTER SYSTEM REGISTER. This is especially useful in high-availability configurations.
If a listener receives an incoming request before the respective instance has been registered, the listener rejects the request.
If an instance is in restricted mode, then PMON instructs the listener to block all connections to the instance. Clients attempting to connect receive one of the following errors:
ORA-12526: TNS:listener: all appropriate instances are in restricted mode
ORA-12527: TNS:listener: all appropriate instances are in restricted mode or blocking new connections
ORA-12528: TNS:listener: all appropriate instances are blocking new connections
Figure 4-7 shows the role of a listener during connection establishment with a browser making an HTTP connection and a client making a TTC connection:
The database registers information about the services, instances, and service handlers with the listener.
The client makes an initial connection with the listener.
The listener parses the client request and forwards it to the service handler for the database service requested.
|
See Also:
|
Based on the service handler type registered with the listener, the listener forwards requests to either a shared server or dedicated server process.
Shared server processes are utilized in the shared server architecture. Figure 4-8 depicts a shared server architecture. With shared server architectures, client processes ultimately connect to a dispatcher. The PMON process registers the location and load of the dispatchers with the listener, enabling the listener to forward requests to the least loaded dispatcher.
A dispatcher can support multiple client connections concurrently. Each client connection is bound to a virtual circuit. A virtual circuit is a piece of shared memory used by the dispatcher for client database connection requests and replies. The dispatcher places a virtual circuit on a common queue when a request arrives. An idle shared server picks up the virtual circuit from the common queue, services the request, and relinquishes the virtual circuit before attempting to retrieve another virtual circuit from the common queue. This approach enables a small pool of server processes to serve a large number of clients.
Figure 4-9 depicts a dedicated server architecture. With a dedicated server architecture, each client process connects to a dedicated server process. The server process is not shared by any other client.
PMON registers information about dedicated server processes with the listener. This enables the listener to start up a dedicated server process when a client request arrives and forward the request to it.
Oracle Connection Manager is a router through which a client connection request is sent either to its next hop ordirectly to the database server. Clients who route connection requests through an Oracle Connection Manager can take advantage of the session multiplexing and access control features configured on that Oracle Connection Manager.
Oracle Connection Manager consists of three components:
The listener receives client connections and evaluates against a set of rules whether to deny or allow access. If it allows access, the listener forwards a request to a gateway process, selecting the one with the fewest connections. The CMGW process, in turn, forwards the request to another Oracle Connection Manager or directly to the database server, relaying data until the connection terminates. If a connection to the server already exists, the gateway multiplexes, or funnels, its connections through the existing connection. CMADMIN monitors the health of the gateway processes and the listener, shutting down or starting up processes as needed. In addition, it registers the location and load of the gateway processes with the listener, and it answers requests from the Oracle Connection Manager Control utility.
In Figure 4-10, the listener screens connection requests. A gateway process registers with the CMADMIN process. And the CMADMIN process registers with the listener. Finally, the listener forwards the connection requests to the gateway process. Notice that the listener has denied access to the fourth client. After receiving the three valid client connections, the gateway process multiplexes them through a single network protocol connection to the database.
Oracle Net provides an architectural solution that allows for greater scalability in Internet and intranet environments.
Figure 4-11 shows how multiple connections to an Oracle database server are made more scalable with Oracle Connection Manager and a shared server architecture. Oracle Connection Manager is used to offload some of the network I/O of the application Web servers, and shared server is used to serve more concurrent users.
