2
Architecture and Concepts

Net8 uses the Transparent Network Substrate (TNS) and industry-standard networking protocols to connect a client to a server and establish an Oracle network 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. This chapter contains the following sections:

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

Net8 supports two types of connect operations:

Connecting to Servers

Users initiate a connect request by passing a user name and password along with an identifier for the service to which they wish to connect. That identifier, called a net service name, is mapped to a network address contained in a connect descriptor. A connect descriptor contains the:

• network route to the service, including the location of the listener through a protocol address

• service name, a logical representation of a database, used to identify the release 8.1 services, or Oracle System Identifier (SID) used to identify a pre-release 8.1 databases

• optional instance name of the release 8.1 service to which to connect

Clients and servers use this net service name when making a connection with an application.

Depending upon your specific network configuration, a connect descriptor may be stored in one of the following:

• a local names configuration file called TNSNAMES.ORA

• an Oracle Names server for use by Oracle Names

• a external naming service such as NIS or DCE CDS

Net8 coordinates its network sessions with the help of a listener.

Disconnecting from Servers

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

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 on another server, most Oracle tools 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 occasionally disconnect or abort communications without giving notice to Net8. In this event, Net8 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 allows Net8 to identify connections that have been left hanging by the abnormal termination of a client. 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.

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 is closed when an error is generated by the send operation, and the server process terminates the connection.

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.

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.

Net8 Architecture

This section covers the following architectural concepts:

Networking Environments

Oracle networking environments are based on two concepts:

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.

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.

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. 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 network sessions.

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 can be explained by referencing the Open System 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. Figure 2-1 depicts a typical OSI Protocol Communications Stack.

Figure 2-1 OSI 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:

client application

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

Establishes, manages, and terminates network 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.

Stack Communications in a Typical 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. This section covers the following topics:

Net8 Client-Side Interaction

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

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

Figure 2-2 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.

For more information about OCI, see the Oracle Call Interface Programmer’s Guide.

Two-Task Common

Two-Task Common is Oracle’s implementation of the presentation layer. 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:

Component  

Description  

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 network session to the destination. This may include any intermediary destinations or “hops” on the route to the server destination. NN resolves net service names 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 to make a protocol-specific call. Additionally, TNS supports encryption and sequenced cryptographic message digests to protect data in transit. TNS is the basic component of the TNS Network session (NS) layer.  

Oracle Protocols

Oracle protocols are Oracle’s implementation of the transport layer. Oracle protocols are responsible for mapping TNS functionality to industry-standard protocols used in the client-server connection. Each protocol is responsible for mapping the equivalent functions between TNS and a specific protocol. Oracle protocols include:

• LU6.2

• Named Pipes

• SPX

• TCP/IP

• TCP/IP with SSL

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 for the transport layer. 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.

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 listener.

The following components above the network 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.

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.

Stack Communications in an IIOP Environment

This release of Net8 supports a new presentation layer called General Inter-Orb Protocol (GIOP) that is used for those clients connecting to the Java option. Internet Inter-Orb Protocol (IIOP) is an implementation of GIOP over TCP/IP or TCP/IP with SSL. Oracle provides the GIOP service implementation.

IIOP Client-Side Interaction

IIOP clients have different communication stack than a typical Net8 client stack, as shown in Figure 2-3. IIOP clients use:

Figure 2-3 Typical Client vs. IIOP Client Communication Stacks

The server side does not require many of the Net8 communication layers needed in a typical Net8 connection. Instead, the server side only requires a network protocol of TCP/IP and an Oracle protocol of TCP/IP or TCP/IP with SSL. The only component of Net8 required is Transparent Network Substrate (TNS). Figure 2-4 depicts a communication stack between an IIOP client and the Java option in the Oracle database.

Figure 2-4 Client/Server Communications Stack in an IIOP Environment

See “Configuring Java Option Connections”.

Stack Communications in a JDBC Environment

Oracle’s Java DataBase Connectivity (JDBC) Drivers provide Java programmers access to an Oracle database. Oracle offers two JDBC drivers–one targeted specifically to Java developers writing client-server Java applications and Java-based middle tiers (Java web servers and Java application servers), the other targeted those developing Java applets.

• JDBC/OCI is Oracle’s Level 2 JDBC driver is targeted to client-server Java application programmers and Java-based middle-tier developers. The JDBC/OCI driver converts JDBC invocations to calls to the Oracle Call Interface (OCI} which are then sent over Net8 to the Oracle database server.

• Thin JDBC driver is Oracle’s Type 4 driver designed for Java applet and Java application developers. The JDBC driver establishes a direct connection to the Oracle database server over Java sockets. Access to the database is assisted with a lightweight implementation of Net8 and Two-Task Common.

The layers in a JDBC client communications stack are similar to those of a standard Oracle communications stack, as shown in Figure 2-5:

Figure 2-5 Typical Client vs. JDBC Client Communication Stacks

The OCI JDBC client stack is similar to a typical Net8 Client stack. The Thin JDBC client stack has similar components implemented differently. In an Java client applet-server transaction, information passes through the following layers:

DBAccess Interface

The Java DBAccess Interface layer allows the client to initiate a SQL session much like Oracle Call Interface (OCI) does in a standard client communication stack.

JavaTTC

Provides a subset version of the Two-Task Common implementation necessary for exchanges of information between the Java client and the database. JavaTTC is responsible for:

• negotiating protocol version and data type

• determining whether conversions between the Java client character set and server character set are necessary

• SQL statement execution

JavaNet

Provides a communication infrastructure so JDBC client can connect to an Oracle database that is an equivalent implementation of NI, NR/NN/NA, and TNS in Net8.

• Communication Interface – Provides an interface between JavaTTC and other networking layers much like NI does in a standard client communication stack.

• Addressing – Processes Net8 destination addresses much like NN does in a standard client communication stack.

• Java NS – Much like Transparent Network Substrate (TNS) in a standard client communication stack, Java NS provides a common interface to TCP/IP, 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).

Network Protocol Layer

Java Sockets – Provides a connection to between Java NS and TCP/IP.

TCP/IP Protocol – Java NS will only run on top of TCP/IP, because Java sockets use TCP/IP.

Figure 2-6 depicts a communication stack between a Java client applet and an Oracle database.

Figure 2-6 Client/Server Communications Stack in a JDBC Environment

Network Sessions to Multi-Threaded Servers

Multi-threaded server (MTS), also called shared server, allows many user processes to share very few server processes.

With MTS configuration, many user processes connect to a dispatcher. A dispatcher enables many clients to connect to the same server without the need for a dedicated server for each client. A dispatcher handles and directs multiple incoming network session requests to the shared server. The advantage of MTS is that system overhead is reduced and less resources are used, allowing the number of users supported to be increased.

Without MTS, each user process requires its own dedicated server process. A new server process is created for each client requesting a connection. A dedicated server remains associated to the user process for the remainder of the connection.

When an Oracle server has been configured as MTS, incoming network sessions are always routed to the dispatcher unless either the network 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 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 with the listener. When the listener is not listening on its default address, the listener’s network name may be specified in the database initialization file (INITSID.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 server will not be able to contact the listener in step 3. If this occurs, there may be a delay as the server attempts to connect to the listener. If a connect request comes in a timeframe where no dispatchers are registered, these requests may either be handled through prespawned dedicated or newly spawned dedicated servers or may be rejected.

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

Note: :

You can check which dispatchers have registered with the listener by issuing a SERVICES command in the Listener Control Utility. For more information, see “SERVICES”.  

Once the listener and the dispatcher server have been started, the network 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 network session, and then resumes at Step 6.

3. If the client’s request is validated, the listener issues a redirect message to the client containing the network address of the least-used dispatcher for the shared server. In Oracle Parallel Server, the message would be redirected to the least used dispatcher on the least loaded node.

4. The client dissolves the network session to the listener and establishes a network 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 network session. This allows the listener to balance the incoming network session requests between dispatchers running on the same protocol.

6. The listener resumes listening for incoming network sessions.

When a client disconnects, the shared server associated with the client stays active and processes other incoming requests. Different requests from the same client may be processed by different shared servers.

Figure 2-7 depicts the role of the listener in a redirected connection to a dispatcher.

Figure 2-7 Redirected Connection to a Dispatcher

For MTS configuration information, see Chapter 9, “Configuring Multi-Threaded Server”.

Network Sessions to Dedicated Servers

Alternatively to MTS, Net8 may redirect the request to an existing dedicated server. This is the default implementation. Net8 sends the address of an existing server process back to the client. The client then resends its connect request to the server address provided.

Net8 provides the option of automatically creating dedicated servers 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.

Note: :

Prespawned dedicated servers require SQL*Net version 2.1 or later, and Oracle Server release 7.1 or later.  

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

The above sequence of events continues until the maximum prespawn limit 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.

Figure 2-8 depicts the role of the listener in a redirected connection to a prespawned dedicated server process.

Figure 2-8 Redirected Connection To a Prespawned Dedicated Server Process

Bequeathed Network Sessions to Dedicated Servers

If the listener and server exist on the same node, the listener may create or spawn dedicated servers as connect requests are received. Dedicated servers are committed to one network session only and exist for the duration of that network session. The sequence of events that occur when the listener creates a dedicated server process and passes or “bequeaths” control of a network 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 network session request, and determines if the client’s request may be serviced. If not, the listener refuses the network session and then resumes at Step 5.

4. The listener spawns a new dedicated server process to serve the incoming network session, and bequeaths the network session to that server process. Once the network session is established, data flows directly between the client and dedicated server process.

5. The listener continues listening for incoming network sessions.

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

Figure 2-9 depicts the role of the listener in a bequeathed connection to a dedicated server process.

Figure 2-9 Bequeathed Connection To a Dedicated Server Process

Net8 and the Listener

The listener receives connection requests on behalf of a client application.

This section covers the following topics:

Database Instance Registration to Listeners

Database instances register themselves with the listener when started. Database instance registration is comprised of two elements:

• service registration provides the listener with instance information, such as database service names and instance names.

• MTS dispatcher registration provides dispatcher information to the listener

When an instance is started, initialization parameters are read from the INITSID.ORA. One of these initialization parameters is the service name. By default, an instance background process registers instance information to a listener on the local machine.

If a listener is started after the instance, there may be a delay before the instance and dispatchers are registered. The instance will attempt to connect to the listener periodically. Similarly, if a listener gets an incoming request before an instance is registered, the listener may reject the request.

For MTS configuration information, see Chapter 9, “Configuring Multi-Threaded Server”.

Benefits

Database instance registration offers the following benefits:

• The LISTENER.ORA file does not require the SID_LIST_listener_name parameter that specifies information on the databases served by the listener. This parameter is still required if the management tool you are using still requires it.

• Connect-time failover is enabled, as described in “Connect-Time Failover”.

• Connection load balancing is enabled, as described in “Load Balancing”.

Client Connections

A client is configured with a net service name that contains the location of a listener and service name of the service to which to connect.

When a client requests a connection from a listener, the service name is sent to the listener. The listener receives the network session request, determines if the information passed to it matches the information it has registered, and determines if the client request may be serviced.

Figure 2-10 depicts the role of the listener in a typical Net8 connection to a server.

Figure 2-10 Listener In a Typical Net8 Connection

Connect-Time Failover

Database instance registration enables the listener to know if an instance is up prior to attempting a connection. This feature facilitates automatic failover of a client connect request to a different listener.

To control how the client executes these connection attempts, you will need to configure multiple listening addresses for each net service name and use the failover (FAILOVER = ON) parameter.

Connect-time failover continues until the client successfully connects to a listener.

Connect-time failover is not the same as “Transparent Application Failover” which is a runtime-failover for high-availability environments, such as Oracle Parallel Server, that refers to the failure of and re-establishing of application-to-service connections. See Oracle8i Tuning for further information about transparent application failover.

For configuration information, see “Configuring Multiple Address Options”.

Load Balancing

Load balancing is a feature by which client connections are distributed evenly among multiple listeners, dispatchers, instances, and nodes so that no single component is overloaded.

Load balancing happens at the following levels:

Client Load Balancing

If more than one listener services a single database, a client can randomly choose between the listeners for its connect requests. This randomization allows all listeners to share the burden of servicing incoming connect requests.

To enable your clients to choose from listeners at random, you will need to configure multiple listening addresses for each net service name and use the load balance (LOAD_BALANCE=ON) parameter.

For additional configuration information, see “Configuring Multiple Address Options”.

Connection Load Balancing

Database instance registration enables connection load balancing because of the registration that happens with remote listeners. Connection load balancing evenly distributes the number of active connections among various instances and dispatchers for the same service. The load of a instance and dispatcher is determined by the number of connections.

Connection load balancing is only enabled for an MTS environment. It is not configurable by clients.

A listener sends an incoming client request for a specific service to the least loaded dispatcher and instance. For example, if the service has multiple instances on multiple nodes, it chooses a dispatcher based on the least loaded instance, where the instance load is based on the node load.

Oracle Names Architecture

Oracle Names is a distributed naming service developed for Oracle environments to help simplify the setup and administration of global, client/server computing networks.

This section covers the following topics:

Overview

Oracle Names establishes and maintains an integrated system of Oracle Names servers which work together like a directory service storing addresses for all the services on a network and making them available to clients wishing to make a connection.

Much like a caller who uses directory assistance to locate a telephone number, clients configured to use Oracle Names will refer their connection requests to a Oracle Names server. The Oracle Names server will attempt to resolve the service name provided by the client to a network address. If the Oracle Names server finds the network address, it will then return that information to the client. The client can then use that address to connect to the service.

Figure 2-11 depicts how Oracle Names works to help establish a connection between a client and server:

1. A database registering its service with an Oracle Names server.

2. Client seeking to locate a service on the network by contacting an Oracle Names server to retrieve the network address.

3. Clients then transparently connecting to the service:

Figure 2-11 Oracle Names

Oracle Names provides an alternative to file-based or local name resolution methods, where net service names and addresses must be configured and maintained with each individual client. By maintaining this information in a central administrative location, Oracle Names reduces the work effort associated with adding or relocating services.

For configuration information, see “Configuring the Network with the Oracle Names Method”.

Administrative Regions

Oracle Names provides support for one or more administrative regions.

Most networks have one central point of administration, that is, one administrative region. An administrative region consists of a collection of Oracle Names servers that administer services in a network. All connect information are stored in a single data repository, which has the authority to interpret a service name. All Oracle Names servers within an administrative region query information from this data repository. If the administrative region uses a database for storage, there is one database per administrative region. There can be any number of Oracle Names servers.

Most enterprise environments with multiple data centers and many Oracle instances will probably choose to take advantage of multiple administrative regions. This allows each data center to independently define and manage the services in its own environment. At the same time, all service addresses are continuously available to all of the clients in the whole environment. Oracle Names servers transparently forward name resolution requests from clients in foreign administrative regions to the proper Oracle Names server.

Domains

An administrative region contains one or more domains used to divide administrative responsibilities.

A domain is a logical group of machines and network services. A domain is a way to identify a service within a network. Similar to a directory structure in a file system, it assigns a unique logical name to a network service. Within each domain all names must be unique, but across domains simple unqualified names can be repeated.

Network domains are similar to file directories used by many operating systems in that they are hierarchical. Unlike file systems however, network domains may or may not correspond to any physical arrangement of databases or other objects in a network. They are simply names spaces developed to prevent name space conflicts.

Note:

Although they appear similar, the domains of an Oracle network are completely independent of Domain Name Service (DNS) name spaces. For convenience, you may choose to mirror the DNS directory structure in your Oracle network.  

Oracle Names As Data Repository

Data in Oracle Names servers is updated through continuous replication between all the Oracle Names servers in the region, or by writing to and reading from a common Oracle database.

For smaller workgroup environments where all of the services are registered dynamically, administrators may configure Oracle Names servers to replicate data continuously among themselves. When a listener registers a new service, information about that service will immediately be passed along to other Oracle Names servers in the administrative region.

Alternatively, administrators in large environments will normally want to store their registration data in an Oracle database, called the region database. A region database consists of tables that store Oracle Names information. If the Oracle Names servers are configured to use an Oracle database as a repository, all service registrations will be written to the database. Each Oracle Names server in a given administrative region will periodically poll the region database for updated registrations. In this way, new registrations are communicated in a timely manner to all of the Oracle Names servers in a given administrative region. At the same time, it relieves Oracle Names servers of the necessity to communicate directly with each other, as well as provides better reliability.

Data Stored in an Oracle Names Server

Below is a description of the types of data stored in an Oracle Names server.

Data  

Description  

database global database names and addresses  

The Oracle Names server retrieves information about the database, including the global database name (database name and domain) and address, from the listener. The address is configured in the LISTENER.ORA file, and the global database name is registered during database startup or statically configured in the LISTENER.ORA file. You do not to register this information.  

other Oracle Names server names and addresses  

An Oracle Names server stores the names and addresses of all other Oracle Names servers in the same administrative region. If there is more than one administrative region in a network, the Oracle Names server will store the name and address of at least one Oracle Names server in the root administrative region and each of the immediate sub-regions. You do not need to register this information.  

net service names  

If you register net service name with the NAMESCTL control utility or the Net8 Assistant, an Oracle Names server stores them. An Oracle Names server also stores gateways to non-Oracle databases and Oracle RDB databases.  

global database link  

Database links allow a database to communicate with another database another. The name of a database link is the same as the global database name of the database to which the link points. Typically, only one database link should exist per database.

The following types of database links may be created:

• You can create a private database link in a specific schema of a database. Only the owner of a private database link can use it.

• You can create a public database link for a database. All users and in the database can use it.

• You can create a global database link in Oracle Names server so anyone in the network can use it.

Because the Oracle Names retrieves the global database name from the listener, a global database link that is the global database name is automatically registered with the Oracle Names server. Therefore, you do not need to register this information.

User name and password credentials for the global database link may be registered with the Oracle Names server using the Net8 Assistatnt.These global database links may be supplemented with link qualifiers defined through the Net8 Assistant.

Global database links may be superseded with private and public database links created by individual users. For more information about private and public database links, see Oracle8i Distributed Database Systems.  

aliases  

An Oracle Names server stores aliases or alternative service names for any defined net service name, database service or global database link. Aliases may be registered with the Oracle Names server using either the NAMESCTL control utility or Net8 Assistant.  

Oracle Connection Managers  

An Oracle Names server stores the names and listening addresses of all Oracle Connection Managers on the network. You do not to register this information.  

Organizing and Naming Network Components

When you use Oracle Names, objects such as databases in a networked environment will need to be named in a way as to ensure that they are unique within the network. There are two basic models for naming objects in a network:

Single Domain Model

The use of the single domain naming model is useful if your network is small, and there is no duplication of names. Figure 2-12 depicts a typical flat naming structure using a single domain name, .WORLD.

Figure 2-12 Single Domain Naming Model

In this environment, database service names will automatically be appended with a .WORLD extension (for example, PROD.WORLD, FLIGHTS.WORLD, and so forth).

Hierarchical Naming Model

Hierarchical naming models divide names into a hierarchical structure to allow for future growth or greater naming autonomy. This type of naming model will allow more than one database with the same simple name in different domains.

Figure 2-13 depicts a hierarchical structure of domains including the (ROOT) domain, ACME domain, US.ACME, EUROPE.ACME, and ROW.ACME (Rest of World) domains.

Figure 2-13 Hierarchical Naming Model

Notice in Figure 2-13 both WEATHER and HISTORY are repeated, but the names remain unique (that is, HISTORY.ROW.ACME and HISTORY.EUROPE.ACME).

Default Domains

The default domain is the domain within which most of the client’s name requests are conducted. This is usually the domain in which the client resides, though it could also be another domain from which the client most often requests services. A client can request a network service within its default domain using the service’s simple, unqualified name, that is, without specifying a domain name. If a user requests a name without a “.” character in it, the default domain name is automatically appended to the database service or database link name requested.

Figure 2-14 depicts a client with a default domain of EUROPE.ACME.COM. When it makes a request for the service name “WINE”, the default domain name EUROPE.ACME.COM is appended to the requested name so that the name becomes WINE.EUROPE.ACME.COM.

Figure 2-14 Default Domains

For more information about domain names, see Oracle8i Concepts.

Multiple Domains

Multiple domains are related hierarchically to a root domain (the highest-level domain in the hierarchy) in a series of parent-child relationships. For example, under the root might be several domains, one of which is called COM. Under the COM domain might be several more domains, one of which is ACME. Under the ACME domain might be several domains, such as US, EUROPE, and so forth.

Note::

In previous releases of SQL*Net and Oracle Names, a network with only one domain, would by default be called “.world”. This is no longer a requirement with Net8 and Oracle Names version 8. You may, however, want to keep the same convention to be backward compatible, as well as to avoid having to rename all your databases.  

Using Multiple Regions to Decentralize Administrative Responsibilities

An administrative region can contain multiple domains. A fully qualified domain name can exist in only one administrative region, However, a domain name can appear in two different regions. In order to have a flexible naming scheme, the administration responsibility of a region must be decentralized.

If you are using Oracle Names and your network is large or widely distributed geographically, you may choose to subdivide separate multiple regions. For example, if your network includes both the United States and Europe, you might want to have administrative decisions about the network made locally. To subdivide, you must delegate regions and domains from a parent to a child or subregion.

To delegate administrative regions, you must use a hierarchical naming model with each administrative region controlling one or more different domains.

Networks with multiple administrative regions are composed of one root administrative region and one or more delegated administrative regions.

Root Administrative Regions

The root administrative region contains the root domain. The root administrative region contains the following information:

• Oracle Names servers in the root region.

• Domains as they are administered in this region. This is always at least the root domain, and can include other domains.

• Delegated administrative region Oracle Names servers–The domains and Oracle Names server addresses in any alternate regions which act as direct child regions of the root.

• Data definitions for the root region–all of the database service names, database links and aliases associated with the root administrative region.

Delegated Administrative Regions

Administrative regions can be “delegated” from the top of the hierarchy down to other domains in the naming model. For example, a network with ten domains can have between one and ten administrative regions.

All administrative regions other than the root are hierarchically delegated directly or indirectly from it.

Figure 2-15 depicts a network with five domains and three administrative regions: the ROOT, and two delegated regions (DR1, DR2).

Figure 2-15 Delegated Administrative Regions

Delegated Administrative Regions Below Root

All administrative regions below the root are considered delegated administrative regions. Delegated administrative region receive administrative responsibilities for a domain from other regions, such a the root administrative region. A delegated administrative region contains the following information:

• All Oracle Names servers and domains in the region

• Domains and Oracle Names server addresses in any of this administrative region’s child regions

• Addresses of the Oracle Names servers in the root region. Having this data allows Oracle Names servers in delegated regions to contact any other region (through the root region)

• Data definitions–All of the database service names, database links, and aliases for all of the domains in this local (delegated) administrative region

Differences Between Versions of Oracle Names

There are significant differences between this version of Oracle Names and earlier versions:

Oracle Names version 1

In Oracle Names version 1, administrators configured Oracle Names servers using Oracle Network Manager and stored all topology data in a database. All the Oracle Names servers in a region shared the same information because they accessed the same database.

The clients had a list of preferred Oracle Names server specified in the SQLNET.ORA file. This list was created by the user, listing the order of preferred Oracle Names to contact. The first Oracle Names server in the list would be contacted first by a client.

Preferred Oracle Names servers may still be configured, as described in “Configuring Preferred Oracle Names Servers”.

Oracle Names version 2

In Oracle Names version 2, the administrator could choose between continuing Oracle Names Server configuration as in version 1, or using the Dynamic Discovery Option. The Dynamic Discovery Option was recommended only for a network with a single region and single DNS domain. The Dynamic Discovery Option uses well-known Oracle Names server, which are precise names hard-coded into DNS or the HOSTS file on both the Oracle Names Server and its clients:

The well-known host names for TCP connections  

The well-known computer Names for Named Pipes connections1  

The well-known service name for an SPX connection  

oranamesrvr0

oranamesrvr1

oranamesrvr2

oranamesrvr3

oranamesrvr4  

ORANAMESRVR0

ORANAMESRVR1

ORANAMESRVR2

ORANAMESRVR3

ORANAMESRVR4  

oranamesrvr  

1
Well-known Names Server names for Names Pipes must be in all uppercase.

Oracle Names servers then become available at these well known addresses, so that clients did not need to be told, by way of preferred Oracle Names server lists, where to find an Oracle Names server.

If the Dynamic Discovery Option was chosen, each Oracle Names server automatically replicated its data to all other well-known Oracle Names server in the region. Listeners were configured to register themselves with well-known Oracle Names servers.

See the Oracle Names Administrator’s Guide, Release 2.0, for configuration information.

Oracle Names version 8

In Oracle Names version 8, the administrator may choose between continuing Oracle Names Server configuration as in version 1 or version 2, or using the new functionality. Oracle Names version 8 incorporates version 2 Dynamic Discover Option features without the constraints of a single region and single domain. The main features of Oracle Names version 8 include:

• A service can register itself with any Oracle Names server it can find, and its name and address are made available to all Oracle Names server in the region. Similarly, if an administrator manually registers a service to any Oracle Names server, that service information is available to all other Oracle Names Servers. The address information is shared in one of two ways:
  • Service Replication — In service replication, service information is stored in an Oracle Names server’s cache and is instantly replicated to the caches of all other Oracle Names servers.

  • Region Database — 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 Servers.

• A list of Oracle Names servers to contact is created on a client through a discovery process rather than manual configuration, as described in “Understanding Discovery”.

• A client-side process may be run to create a client cache version of the data stored in Oracle Names servers, including database addresses, Oracle Names server addresses, as well as other service information. As a result, the client does not have to contact an Oracle Names server for address information, reducing address look up time.

• Oracle Names version 8 does not require a database to hold topology information. However, an administrator may choose to use one, and it is recommended.

See “Configuring the Network with the Oracle Names Method” for configuration information.

Understanding Discovery

A list of Oracle Names servers is created that allows a client or another Oracle Names server contact an Oracle Names server. This process of creating the list is called discovery.

When a client or an Oracle Names server, tries discover Oracle Names servers, it tries to find one Oracle Names server. Once the client finds an Oracle Names server, it pings all other Oracle Names server in the region. A list of Oracle Names servers is then created on the client and saved to .SDNS.ORA on UNIX and SDNS.ORA on Windows platforms. This list is sorted in order of response time.

Discovery searches for the first Oracle Names server in the following order:

If the client is unable to find the first Oracle Names using the above methods:

• You will be prompted to specify the address of an Oracle Names server if you are using the Net8 Assistant.

• The NAMESCTL control utility will fail. You must re-run the command with the address specified.

Oracle Connection Manager Architecture

Oracle Connection Manager acts like a router through which client connection requests may either be sent to its next hop or directly to a server. Clients who route their connection requests through a Connection Manager may then take advantage of the connection concentration, Net8 access control, or multi-protocol support features configured on that Connection Manager.

Oracle Connection Manager Processes

There are three main processes associated with Oracle Connection Manager:

CMGW

CMGW is a gateway process acting as a hub for the Oracle Connection Manager. This process is responsible for the following:

• registering with the CMADMIN process

• listening for incoming connection requests. By default it listens on TCP/IP with port 1630

• initiating connection requests to listeners for clients

• relaying data between the client and server

• answering requests initiated by CMCTL

CMADMIN

CMADMIN is a multi-threaded process that is responsible for all administrative issues of the Oracle Connection Manager. This process is responsible for the following:

• processing the CMGW registration

• identifying all listeners serving at least one database instance

• registering source route address information about the CMGW and listeners

• answering requests initiated by CMCTL

• monitoring registered listeners with the Oracle Names server, then source route addresses

• locating local Oracle Names servers

• maintaining address information in the Oracle Names server for the SQL*Net 2.x and Net 8.x clients

The Oracle Connection Manager periodically goes to the Oracle Names server to update its cache of available services.

CMCTL

CMCTL is the executable name for the Oracle Connection Manager control utility. It provides administrative access to CMADMIN and CMGW. For more information about the Oracle Connection Manager Control Utility, see “Oracle Connection Manager Control Utility (CMCTL)”.

Connection Concentration

Oracle Connection Manager enables you to take advantage of Net8’s ability to multiplex or funnel multiple client network sessions through a single transport protocol connection to a multi-threaded 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 network sessions that a server can handle. By using multiple Connection Managers, it is possible for thousands of concurrent users to connect to a server.

Figure 2-16 depicts how concentration works:

Figure 2-16 Connection Concentration through Oracle Connection Manager

For configuration information, see “Enabling Connection Concentration”.

Net8 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. By specifying certain filtering rules you may allow or restrict specific clients access to a server based on the following criteria:

• Source host name(s) or IP address(es) for clients

• Destination host name(s) or IP address(es) for servers

• Destination database service name

For configuration information, see “Enabling Net8 Access Control”.

Net8 Firewall Proxy

Some firewall vendors also offer the Net8 Firewall Proxy, which is installed on firewalls requiring an application proxy. The Net8 Firewall Proxy has the same functionality as the Oracle Connection Manager.

Note:

Ask your firewall vendor if the Net8 Firewall Proxy is supported.  

Multi-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 Multi-Protocol 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-17 depicts how a client in an SPX network can route its network session to a server over a TCP/IP transport through Oracle Connection Manager.

Figure 2-17 Multi-Protocol Support Through Oracle Connection Manager

For configuration information, see”Enabling Multi-Protocol Support”.

Connection Pooling

Connection pooling is a resource utilization and user scalability 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 dispatcher’s set of connections among multiple client processes. Figure 2-18 shows how connection pooling works:

Figure 2-18 Connection Pooling

By using a time-out mechanism to temporarily release transport connections 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 network session with the previous idle connection. When the idle client has more work to do, the physical connection is reestablished with the dispatcher.

For configuration information, see “Enabling Connection Concentration”.