Oracle Network Administration (2 of 3)

Basic Net8 Architecture

Define the procedure by which Net 8 establishes a server connection

Identify the key components of Net 8 architecture and their interaction

Net8 uses the Transparent Network Substrate (TNS) and industry-standard networking protocols to connect a client to a server and establish an Oracle session. Net8 is responsible for enabling communications between the cooperating partners in an Oracle distributed transaction, wheter they be client-server or server. Specificaly Net 8 provide 3 basic networking operations:

1. Connection Operations
1. Connecting to Servers (open): Users initiate a connect request by passing information such as username and password along with a short name for the database service that they wish to connect(this is in tnsnames.ora) . This short name, called a service name , is mapped to a network address contained in a connect descriptor . Depending on the network configuration this descriptor may be stored in:
1. A local configuration file named TNSNAMES.ORA
2. A Name server for use by Oracle Names
3. A native naming server such as NIS or DCE CDS

Net8 coordinates its sessions with the help of network listener

2. Bequeath the session to a new dedicated server process

If the listener and server exist on the same node, the listener may create or 'spawn' dedicated server processes as connect requests are receive. Dedicated server processes are commited to one session only and exist for the duration of that session. The sequence of events is

1. The listener is started and listenes 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.The listener continues listening for incoming connections
4. The listener spawns a new dedicated server process to serve the incoming session, and bequeaths the session to that server proces. Once the session is established, data flows directly between the client and dedicated server process.
5. The listener continues listening for incoming connections

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

3. Redirect to an existing server process ( such as a dispatcher or prestarted dedicated server process)

It does this by sending the address of an exisiting server process back to the client. The client will then resend its connect request to the server address provided,there are two options:

1. Prespawned Dedicated Server Process: This option automatically creates a 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 files. The events that take place are:
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 SID defined in its config file.
3. Each spawned server process performs a partial address listen and provides the listener with a partial address that it is listening on. The listener initially marks all prespawned servers as idle.NOTE: A partial address listener is where the server process listenes, 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 assing this to the requesting server process.
4. The client send a connect request to the listener.
5. The listener receives the session request, and determines if the clients request may be serviced. If not, the listener refuses the session.
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 config. file is grater than the number of prespawned server processes active and idle)
9. The listner continues listening for incoming sessions.
2. Dispatcher Server Processes :A dispatcher server processes enables many clients to connect to the same server without the need for a dedicated server processes for each client. It does this with the help of a dispatcher which handles and directs multiple incoming session request to the shared server.

When an Oracle server has been configured as multi-thereaded 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 is as follows:

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

Once the dispatchers addresses are registered, the listener can redirect incoming connect request 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 contact 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.

4. The listener and the Oracle dispatcher server are now ready to receive incoming sessions.
5. Once the listener and the dispatcher server have been started, the session activity continues as follows:
6. The client connects to the listener with the network address
7. The listener receives the connect request, and ddetermines if the clients request may be serviced. If not, the listener refueses the session.
8. The listener issues a redirect message to the client containing the network address of the least-used dispatcher for the shared server.
9. The client dissolves the session to the listener and establishes a sesion to the shared server using the network address provided in the redirect message.
10. 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 on the same protocol

11. The listener resumes listening for incoming sessions.
4. Refuse the session: 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. Data Operations: Net8 supports four sets of client-server data operations:
1. Send data synchronously
2. Receive data synchronously
3. Send data asynchronously
4. Receive data asynchronously

Basic send and receive requests are synchornous. When a client initiates a request, it waits for the server to respond with the answer. It can then issue an additional request. The asynchronous capability to send and receive data requests asynchronously, was added to support Oracle shared server(Multithreaded-Server), which requires asynchronous calls to service incoming request from multiple clients.

3. Exception Operations:Net8 supports three type of exception operations:
1. Initiate a break over the connection
2. Reset a connection for synchronization
3. Test the condition of the connection for incoming break

The user control only one of these operations, that is, the initiation of a break, with de CTRL-C command. Additionaly 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 excptions 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.

Basic Net 8 Server-Side Configuration

Describe the listener process

The network listener is a single process or task setup specifically to receive connection requests on behalf of an application. Listeners are configured to "listen on" an address specified in a listener configuration file (listener.ora) for a database or a non-database service. Once started the listener will receive client connect requests on behalf of a service, and respond in one of three ways.

Configure the listener

Start the Net 8 listener using the Listener Control Utility (LSNRCTL)

Stop the Net 8 listener using the Listener Control Utility (LSNRCTL)

Identify additional LSNRCTL commands

SERVICES : Displays which dispatchers have registered with the listener.

Basic Net8 Client-side configuration

Establish the connection from the Net 8 client side using the host named method

Configure Net 8 client-side files and connect using the local naming method

Define preferences on the client side

Configure Net8 client to use the client load balancing and failover feature.

1. Connection Pooling : It is a resource utilization feature that allows you to maximize the number of physical network connections to a multi-threaded server. This is achieved by sharing or pooling a dispatchers set of connections among multiple client processes . By using a time-out mechanism to temporarily release transport connection that have been idle for a specified period of time, connection pooling makes these physical connections available for incoming clients, while still maintaining a logical session with the previous idle connection. When the the idle client has more work to do, the physical connection is reestablished with the dispatcher.Connect pooling is enabled by parameters in init.ora
2. Connection Concetration : This feature is availabel through Oracle Connection Manager, it allows you to take advantage of Net8's ability to multiplex or funnel multiple client sessions over a single transport to a multithreded server. Like connection pooling, concentration optimizes network resources and increses the number of client-server sessions that are possible across a fixed number of physical server ports. Unlike connection pooling, concentration maintains the transport connection.