Release 8.1.5
A67440-01
 Library |
 Product |
 Contents |
 Index |
| Net8 Administrator's Guide Release 8.1.5 A67440-01 |
|
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 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:
Net8 supports two types of connect operations:
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:
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:
Net8 coordinates its network sessions with the help of a listener.
Requests to disconnect from the server can be initiated in the following ways:
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.
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.
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.
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.
Net8 supports four sets of client-server data operations:
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.
Net8 supports three types of exception operations:
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.
This section covers the following architectural concepts:
Oracle networking environments are based on two concepts:
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.
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 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.
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.
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:
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.
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.
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).
Implements the data transport ensuring that the data is transported reliably.
Ensures that the data transport is routed through optimal paths through a series of interconnected subnetworks.
Provides reliable transit of data across a physical link.
Defines the electrical, mechanical, and procedural specifications for activating, maintaining and deactivating the physical link between client and server.
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:
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.
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).
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:
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 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 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 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:
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.
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:
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.
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.
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.
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 clients have different communication stack than a typical Net8 client stack, as shown in Figure 2-3. IIOP clients use:
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.
See "Configuring Java Option Connections".
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.
The layers in a JDBC client communications stack are similar to those of a standard Oracle communications stack, as shown in Figure 2-5:
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:
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.
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:
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.
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.
|
Note: To take advantage of multi-threaded server (MTS), you must configure it, as described in Chapter 9, "Configuring Multi-Threaded Server". |
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:
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:
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.
For MTS configuration information, see Chapter 9, "Configuring Multi-Threaded Server".
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.
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.
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:
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.
The listener receives connection requests on behalf of a client application.
This section covers the following topics:
Database instances register themselves with the listener when started. Database instance registration is comprised of two elements:
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".
Database instance registration offers the following benefits:
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.
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.
|
CAUTION: Implementing connect-time failover does not allow use of static service configuration parameters in the LISTENER.ORA file. However, static configuration is required for Oracle8i release 8.0 or Oracle7 databases and Oracle Enterprise Manager. For further information about statically configuring the listener, see "Configuring a Listener with Service Information". See the Oracle8i Parallel Server Setup and Configuration Guide for additional configuration instructions on setting up connect-time failover for Oracle Parallel Server in an Oracle Enterprise Manager environment. |
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 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:
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".
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 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:
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:
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".
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.
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.
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.
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:
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. |
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:
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.
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 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.
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).
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.
For more information about domain names, see Oracle8i Concepts.
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.
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.
The root administrative region contains the root domain. The root administrative region contains the following information:
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).
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:
There are significant differences between this version of Oracle Names and earlier versions:
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".
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 |
|---|---|---|
|
oranamesrvr4 |
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.
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:
See "Configuring the Network with the Oracle Names Method" for configuration information.
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:
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.
There are three main processes associated with Oracle Connection Manager:
CMGW is a gateway process acting as a hub for the Oracle Connection Manager. This process is responsible for the following:
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:
The Oracle Connection Manager periodically goes to the Oracle Names server to update its cache of available services.
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)".
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:
For configuration information, see "Enabling Connection Concentration".
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:
For configuration information, see "Enabling Net8 Access Control".
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.
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.
For configuration information, see"Enabling Multi-Protocol Support".
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:
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".
