What is Oracle Net Services?


Net8 is a layer of networking software which allows communcation between multiple machines, generally access between Oracle client and server machines where a server machine contains an Oracle database installation. There are three basic Net8 architectural configurations.

  1. Client-Server connection. The Listener process always resides on the server and listens from the server, over the network, for connection requests.
    Basic CLient-Server Configuration
  2. Client-Server connections using Oracle Connection Manager. The Oracle Connection Manager is a connection routing process allowing for load balancing of requests between multiple Oracle Servers.
    Oracle Connection Manager Configuration
  3. Either of the above including MTS (Multi-Threaded Server). MTS allows for sharing of connections in order to reduce server resource consumption, ie. connection pooling.
    Oracle MTS

Oracle networking environments are based on distributed processing and distributed database models. Distributed processing implies distribution of processing between client and server machines. Distributed databases are databases spread across multiple server machines where a single logical database is an overlay of distributed databases placed on separate servers linked together by use of database links.

Connecting to an Oracle Database Across a Network

A client uses a connect descriptor to connect a client to an Oracle database. A connect descriptor contains network details about the database service and passes these details to the listener. The network details in the connect descriptor contain the listener location (protocol address) and the global database name (service name) of the database. The global database name is usually a combination of the database name and the database domain. For instance, with a database name of PROD and a domain of xyz.com, the global database name would be PROD.xyz.com.

A connect descriptor is a database connection string. A connection string is generally a string required to connect a client-based process to a server-based database process. A connection string usually includes a username and password combination plus a database name, with or without protocol specification details. An Oracle connect descriptor is shown below.

CONNECT <username>/<password>@(description=(protocol=tcp)(host=<hostname>)(port=1521))(connect_data=(service_name=PROD.xyz.com)))

The connect descriptor above can become a more simple format of CONNECT <username>/<password>@<service name>. This is done by placing the missing connect descriptor definition into the listener configuration file on the server. A naming method stores the lengthy details of the connect descriptor in a configuration file. The name of the connection descriptor in the configuration file, called the connect identifier, calls a connect identifier. A connect identifier is defined using one of five different naming methods. These are local naming, directory naming, Oracle Names server, host naming and external naming.

Planning a Network for Oracle

When not using MTS connections will be made with a database using dedicated server connections. A dedicated server connection is dedicated to a specific user request, and for a specific period of time even whilst that user is not actually requesting information from the database. Every new connection requested from the database starts various new processes on the database server and reserves a chunk of server resources such as memory. Large numbers of users can overwhelm the resources of a server. The solution to high resource usage is generally sharing of those resources.

In the case of a non-MTS configuration a connection request is received by the listener. The listener will then pass the client process an address for an available dedicated server process, which may be spawned. In the case of an MTS configuration the listener will pass the client process the address of an available dispatcher process (spawned if non available) which in turn sends the client process the address of a server process. The client process then communicates with the database server using a shared server process. In a non-MTS configuration there can be a number of pre-spawned dedicated server processes. If a user connection request is serviced and all dedicated server processes are actively servicing other client connections then the listener will spawn another dedicated server process. A dedicated server process is spawned if two attributes in the listener.ora file are adhered to. PRESPAWN_MAX must always exceed the number of all active and idle pre-spawned dedicated server processes and the attribute POOL_SIZE is not exceeded. The POOL_SIZE attribute places a limitation on the number of idle pre-spawned dedicated server processes.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521))
      (PROTOCOL_STACK = (PRESENTATION = TTC) (SESSION = NS))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC = 
      (GLOBAL_DBNAME = <SID>.<hostname>)
      (SID_NAME = <SID>)
      (ORACLE_HOME = /oracle/ora81)
      (PRESPAWN_MAX = 20)
      (PRESPAWN_LIST =
        (PRESPAWN_DESC =
          (PROTOCOL = TCP)
          (POOL_SIZE = 5)
          (TIMEOUT = 10)
        )
      )
    )
  )

When to Use MTS

Basically MTS allows overriding of dedicated server connections with shared connections. MTS works such that dispatcher processes are used by multiple client requests to communicate with shared server processes. Thus the client connects with one of many dispatcher processes rather than directly with a dedicated server process, thus database connections can effectively be shared amongst different users where users share server connections. The best use of MTS is when users spend a large amount of connection time idle, ie. they are not utilising a preserved set of database connection resources. When one client is not utilising a connection then another client can utilise the database connection (shared server process and memory resources) thus effectively sharing connections. MTS is not appropriate where multiple users are executing intensive processing for long periods of time. Client processes requiring large data load connections are best served with dedicated server connections. MTS processes can be stopped for periods of time or specific client connections can be served exclusively by dedicated connections whilst other clients continue to be serviced by shared server-dispatcher serviced connections. For instance, SQL*LDR, import data uploads or backups are best serviced by dedicated connections. A Recovery Manager (RMAN) database, database connection, can only be serviced by a dedicated connection (Set the attribute SERVER = DEDICATED in the tnsnames.ora file). Client processes can be forced to always use a dispatcher process when connecting to a database by setting the attribute SERVER = SHARED in the tnsnames.ora file.

TEST =
  (DESCRIPTION =
    (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521)))
    (CONNECT_DATA = (SERVICE_NAME = TEST) (SERVER = SHARED))
  )

RMAN =
  (DESCRIPTION =
    (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521)))
    (CONNECT_DATA = (SERVICE_NAME = RMAN) (SERVER = DEDICATED))
  )

Tuning Database Connections

There are various improvements which can be made to tune database connections, with or without use of MTS.

The Listener

The listener process configuration resides on the database server. The listener listens for connection requests and then routes those connections to a server process. Multiple protocol addresses can be configured within the listener. This allows the listener to be called with multiple protocols. When a request is made to a database listener the listener will pass the request to a server process by sending a redirection message back to the client process with an address of a server process. The client process then proceeds to communicate with the database using the server process whilst the listener continues to listen for further connection requests from other client processes. Any spawning of server processes or dispatcher processes is executed by the listener as a result of a client connection request exceeding currently unused process availability on the server.

Service Registration to the Listener

Service registration involves PMON and the registration of instance information plus instance and dispatchers' state and load with a listener process. The registered information is then used by the listener to forward client connection requests to appropriate service handlers. Thus the listener can always detect the usability of an instance, is the instance up ? For example in an Oracle Parallel Server environment. Everything required for the listener to operate effectively is provided using service registration, even down to dispatcher load rates when using MTS, thus allowing the listener to decide which dispatcher process to pass a request to when load balancing between dispatchers.

Note that the parameters service_names (database service name) and instance_name (database instance name) must be set in the parameter file for service registration to function.

service_names = <database SID>.<hostname>
instance_name = <database SID>

The parameter local_listener is used to specifiy a network name. This network name will resolve to an address list of local listeners. Local listeners are listener processes running on the same machine as the database instance. The address list must be specified in the file specified by the naming method in use, ie. the tnsnames.ora file.

The Parameter File
local_listener=<listener>
The Local Naming Method File (tnsnames.ora)
<listener> =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521) )
      (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1522) )
    )
  )
Service Registration with Remote Listeners

Service registration can be performed with remote listeners and can be configured using the listener atttribute of the mts_dispatchers parameter in the parameter file.

MTS_DISPATCHERS = "(PROTOCOL = TCP) (LISTENER = <listener>)"

Once again the listener alias (<listener>) must be resolved using a naming method such as tnsnames.ora as in the previous example.

Multiple Listeners

Multiple listener processes can be created. Whenever a database connection request is made it is the listener process which will pass the connection request to either a dispatcher or server process. Many connection requests can cause a connection requests backlog, each connection requiring processes and memory. Even creation of a connection takes processing time; processing time is a valuable resource. Thus the fewer connections created the more resources available for other processing. Creation of multiple listener processes can effectively share handling of and routing of connection requests to server and dispatcher processes; effectively allowing the enabling of connection pooling and/or load balancing.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521))
      (PROTOCOL_STACK = (PRESENTATION = TTC) (SESSION = NS))
    )
  )

LISTENER2 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521))
    (PROTOCOL_STACK = (PRESENTATION = TTC) (SESSION = NS))
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC = (ORACLE_HOME = /oracle/ora81) (SID_NAME = <SID>))
  )

SID_LIST_LISTENER2 =
  (SID_LIST =
    (SID_DESC = (ORACLE_HOME = /oracle/ora81) (SID_NAME = <SID>))
  )

LOGGING_LISTENER = OFF
LOGGING_LISTENER2 = OFF
Connection Load Balancing

Connection load balancing can only be enabled when multiple listeners are configured by setting the attribute load_balance = ON within the tnsnames.ora file. Note the failover = on attribute will cause a client connection request to failover the client connection request to another listener if the connection to the first listener process fails. There is a runtime active failover implementation called Transparent Application Failover (TAF). TAF is intended for use with Oracle Parallel Server or Oracle Fail Safe where connection failure can result in automatic reconnection and resumption of partially completed SELECT statement processing. Generally failover is used between two separate database instances in an Oracle Parallel Server environment (Net8 Transparent Application Failover (TAF)).

<name> =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (FAILOVER = ON)
      (LOAD_BALANCE = ON)
      (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1522))
    )
    (CONNECT_DATA = (SID = <SID>) (ORACLE_HOME = /oracle/ora81))
  )

Listener Queue Size

With large volumes of traffic a connection queue to handle listener processing can be specified to handle high volumes of requests. An increased listener connection queue can handle larger numbers of connection requests concurrently. Change the listener connection requests queue size for each listener in the listener.ora file by setting the queuesize=[n] parameter. Note that listener queue sizes can only be altered using TCP/IP or DECnet. Default queue size on Solaris is 5 and 50 for NT.

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = <hostname>)(PORT = 1521)(QUEUESIZE = 50))
      (PROTOCOL_STACK = (PRESENTATION = TTC) (SESSION = NS))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC = (ORACLE_HOME = /oracle/ora81) (SID_NAME = <SID>))
  )

LOGGING_LISTENER = OFF

Connection Pooling

Connection pooling can only be enabled when using MTS. The sharing of a dispatcher process' set of connections must be enabled to connect to many client processes. Using dispatcher connection pooling, physical connections are maximised to shared server processes. A timeout mechanism can also be utilised to release idle connections for use by other client processes. Enable connection pooling by setting the POOL = ON attribute in the MTS_DISPATCHERS parameter in the parameters file.

MTS_DISPATCHERS = "(PROTOCOL = TCP) (DISPATCHERS = 1) (POOL = ON) (TICK = 1) (CONNECTIONS = 1000) (SESSIONS = 500)"
MTS_DISPATCHERS = "(PROTOCOL = TCP) (DISPATCHERS = 1) (POOL = ON) (TICK = 1) (CONNECTIONS = 750)"

Connection Timeouts

Connection timeouts can be controlled by setting the TNS Timeout value (CONNECT_TIMEOUT_LISTENER = [n]) value in the listener.ora file or by setting the SQLNET.EXPIRE_TIME =[n] parameter in the sqlnet.ora file. The sqlnet.ora profile configuration parameter will override tnsnames.ora settings.

The listener.ora File
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = <hostname>)(PORT = 1521))
      (PROTOCOL_STACK = (PRESENTATION = TTC) (SESSION = NS))
    )
  )

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC = (ORACLE_HOME = /oracle/ora81) (SID_NAME = <SID>))
  )

CONNECT_TIMEOUT_LISTENER = 30
LOGGING_LISTENER = OFF
The sqlnet.ora File
#SQLNET.EXPIRE_TIME = 0
SQLNET.EXPIRE_TIME = 30

Client-Server Naming Methods

A Naming method is used to map or resolve a connect identifier to a connect descriptor. A naming method is a way in which a name is interpreted into a network description or on a network where the target machine to be reached resides. The five available naming methods are as follows.

Local Naming

Local Naming uses a configuration file local to each client machine called tnsnames.ora. This configuration allows specific tuning for each client machine. A client process requests a connection using a network service name. The tnsnames.ora file contains the connect descriptor (connection string) for the network service name. The connection string retrieved from the tnsnames.ora file is then used by the client to execute the connection request to the database server. The listener on the server will service the request by passing the client process the address of the database dedicated server process or shared server process (MTS) required to make the database connection.

Directory Naming (LDAP)

With Directory Naming service addresses and net service names are stored into a lightweight directory access protocol (LDAP) server, much like a DNS server. Client processes make connection requests using name-network address pairs stored in the LDAP directory server. The client provides a name and the LDAP directory provides the client connection request process with a network connect descriptor or connection string when the client makes a named request to that LDAP directory server, similar to the /etc/hosts and /etc/resolv.conf files on a Solaris Unix box.

Oracle Names

Oracle Names involves the use of an Oracle Names server. The Oracle Names server is used to store service addresses and net service names. The Oracle Names server is used to keep a central store of service addresses much like a DNS server does. An Oracle Names server can be used to store names and addresses of all database services across a network. The Oracle Names server is used to return a network address when provided with a name by a client connection request. The client process will then make a connection request to a database server with the network address provided by the Oracle Names server.

Host Naming

In the case of Host Naming service names are stored using an IP-Address translation mechanism, ie. a host name alias. Host names are mapped to a server global database name using a names resolution service such as DNS (Domain Name System), NIS (Network Information Service) or even a centrally maintained set of hosts files such as /etc/hosts. Host Naming can be used without a tnsnames.ora file. Thus only the most simplistic of Oracle network access can be used.

External Naming

External Naming involves the use of a third-party naming service which is supported by Oracle such as NIS (Network Information Services), NDS (Novell Directory Services) or CDS (Cell Directory Services) / DCE (Distributed Computing Environment). The external naming method will resolve a net service name to a network address.

Service Name Database Identification

A distributed database is a single database service of multiple instances which can span multiple machines whilst using a single database service name. Thus it is inappropriate to identify a distributed database with it's <SID> since the database <SID> is synonymous with a single instance. The service_names parameter in the parameter file can be used to identify a single database service of multiple instances and machines. The service_names parameter is initially set to the global_database_name parameter. The global_database_name parameter is a concatenation of database and domain names, ie. the db_name and db_domain parameters. The tnsnames.ora file would be as shown below; note the exchange of the <SID> attribute for that of the <INSTANCE_NAME> and <SERVICE_NAME> attributes.

<name> =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (FAILOVER = ON)
      (LOAD_BALANCE = ON)
      (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1522))
    )
    (CONNECT_DATA = (INSTANCE_NAME = <SID>) (SERVICE_NAME = <SID>.<Domain name>))
  )

Database identification by service name is used by Oracle Parallel Server, distributed database environments and even definition of multiple types of services mapped to a single database instance. Different client connection requests are serviced in different ways based on client process requirements.

Oracle Connection Manager

Oracle Names Server is like a telephone book; it provides an address but not directions to that address. An Oracle Names Server will provide a client connection request with an address to connect to, for instance, hostname, port number and service or SID name. Oracle Connection Manager helps a client process with directions to a network address. The Oracle Connection Manager behaves like a listening router where a connection request is sent to the next node on the path to its destination; this next node could be the target server or a next step. Additionally Oracle Connection Manager can provide connection concentration, access control and support for multiple protocols simultaneously.

Oracle Connection Manager has two processes.

  1. The Connection Manager Administrative process (CMADMIN) is an Oracle Connection Manager administrative process. The utility cmctl will access CMADMIN through CMGW.
  2. The Gateway process (CMGW) listens for client connection requests; defaulted on port 1630 using TCP/IP. Connection requests are passed to a listener and data is relayed between client and server processes.

Connection Concentration

MTS can be utilised to reduce the total number of concurrent connections between client and server machines, therebye conserving valuable server resources. Oracle Connection Manager will allow multiplexing (funneling) of multiple client network sessions to a single TCP/IP connection to an MTS target server. Connection concentration allows for multiple connections between two processes. This allows the server to service more connection requests since multiple client connection requests can be serviced by a single dispatcher process. Therefore use of multiple Connection Managers can increase the number of concurrent client connections serviced astronomically. In order to enable Oracle Connection Manager connection concentration the mts_dispatchers parameter must be set appropriately in the parameters file as shown below.

mts_dispatchers = "(PROTOCOL=TCP) (MULTIPLEX=ON))"

Multiple Protocol Support

Multiple protocol support allows for communication across networks using something introduced before the introduction of Net8 called MultiProtocol Interchange. MultiProtocol Interchange allows communication between incompatible network protocols. Multiple protocol support through Oracle Connection Manager must be applied to tnsnames.ora files on client machines. Note the multiple protocol example tnsnames.ora file shown below.

TEST =
  (DESCRIPTION =
    (SOURCE_ROUTE = YES)
    (ADDRESS = (PROTOCOL = SPX) (SERVICE = cman))
    (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521)))
    (CONNECT_DATA = (SERVICE_NAME = TEST) (SERVER = SHARED))
  )
Oracle Connection Concentration using Oracle Connection Manager and Multi-Protocol Support

Oracle Connection Manager Configuration

Net8 uses listener.ora and tnsnames.ora files. An Oracle Names server uses a file called names.ora. Oracle Connection Manager uses a configuration file called cman.ora.

cman = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1630) (QUEUESIZE = 64)))
cman_admin = (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1830))
cman_profile = 
  (PARAMETER_LIST = 
    (MAXIMUM_RELAYS = 1 to 2048)
    (USE_ASYNC_CALL = YES)
  )
cman_rules = 
  (RULE_LIST = 
    (RULE = 
      (SRC = <hostname>)
      (DST = <hostname> | x)
      (SRV = <SID> | x)
      (ACT = accept | reject)
    )
  )

Note the default ports for non-adminsitration connections (CMGW) as port 1630 and adminsitrative (CMADMIN) connections as port 1830. The cman_profile parameter contains Oracle Connection Manager parameter settings. The cman_rules parameter sets filtering rules for network access control across the network. Filtering rules will apply access rules and rights to connection requests between different nodes in a network. Note the optional values in the DST and SRV attributes of the cman_rules parameter settings shown above; x implies any host or database SID can be connected to. The cman_profile, PARAMETER_LIST attribute shown above has 16 possible parameter settings. The MAXIMUM_RELAYS attribute will limit the maximum concurrent connections to be supported by a single Oracle Connection Manager CMGW process.

Supporting Large Networks

In general, large networking environments with high numbers of concurrent connections can be supported with Oracle Multi-Threaded Server (MTS). The objective of MTS is preservation of server resources such as memory and processor usage time. MTS can effectively share connections between multiple users by use of dispatchers and shared processes in place of dedicated server processes. Dispatcher processes communicate between shared server processes and client processes therebye sharing server connections where dispatchers support multiple users and multiple dispatchers are supported by each server process. Additionally, when using MTS the UGA (User Global Area) can be moved into the large pool and thus not compete with the database buffers for memory resources in the shared pool. The UGA contains session information, sort areas and private SQL areas. Thus since connections (sessions) are placed into the large pool, sort space is also placed into the large pool. Sort space can occupy a large amount of memory since each connection will reserve an amount of memory specified by the sort_area_size parameter in the parameter file.

MTS is enabled by the setting of the dispatchers parameters in the parameter file as shown below.

mts_dispatchers=(address=(<protocol>)(<hostname>)(<port>)(<# dispatchers>)(<# connections>))"
mts_max_dispatchers=<max # dispatchers>
mts_servers=<# shared servers on startup>
mts_max_servers=<max # shared servers>
mts_service=<SID | service_names parameter in parameter file>
mts_listener_address=<TNS listener address>
mts_dispatchers="(address=(protocol=tcp)(host=<host>)(port=5001)(dispatchers=2))"
mts_max_dispatchers=2
mts_servers=2
mts_max_servers=4
mts_service=TEST
mts_listener_address="(address=(protocol=tcp)(host=<host>)(port=1521))"

When setting the mts_dispatchers parameter, if not enough dispatchers are started automatically on instance startup, there will be an immediate performance hit starting up more dispatchers in order to cater for the required number of concurrent client connections. The number of dispatchers is generally dependant on the operating system, network protocol requirements and performance required. More dispatchers will decrease resources used by each user but will also decrease performance for each user. For NT there should be 1 dispatcher for every 1000 concurrent connections. Calculate the number of dispatchers required by rounding-up the division of maximum number of concurrent sessions for the operating system by connections per dispatcher.

To force a user to always use a dispatcher set the server=SHARED attribute in the tnsnames.ora file. Otherwise set the server=DEDICATED attribute in the tnsnames.ora file.

TEST =
  (DESCRIPTION =
    (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521)))
    (CONNECT_DATA = (SERVICE_NAME = TEST) (SERVER = SHARED))
  )

RMAN =
  (DESCRIPTION =
    (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = <hostname>) (PORT = 1521)))
    (CONNECT_DATA = (SERVICE_NAME = RMAN) (SERVER = DEDICATED))
  )

Also note that dispatchers can be configured in the parameters file to pass to any port at an IP-Address or tied-in to a specific port at an IP-Address.

mts_dispatchers="(address=(protocol=tcp)(host=<ip_address>)(dispatchers=2))"

Note that when specifiying multiple ports that those ports must be adjacent.

mts_dispatchers="(address=(protocol=tcp)(host=<ip_address>)(port=6200)(dispatchers=1))"
mts_dispatchers="(address=(protocol=tcp)(host=<ip_address>)(port=6201)(dispatchers=1))"

Network Transfer SDU (Session Data Unit)

Data is placed into the SDU buffer by Net8 prior to network transmission. The data is sent across the network towards its address by Net8 either when the buffer is full or on request. Information is passed over a network in packets. Large amounts of throughput at once can cause data sets to be returned in multiple or fragmented packets. Assuming this is always or at least largely the case it may be sensible to increase the SDU buffer size. Obviously consistently small amounts of data partially filling packets does not require an increase in SDU buffer size. Also very high speed networks tend to completely negate the need to alter the size of the SDU buffer. Another obvious point is to set the SDU buffer the same size as a packet or an exact mutliple thereof. Thus for an ethernet with frame size of 1500 set the SDU buffer size to a multiple of that frame size, be it 1500, 3000, 15000, etc. Note that connection pooling and connection concentration requires an extra 16 bytes per packet.

TCP.NODELAY

Sometimes when large amounts of information are passed across a TCP/IP network Net8 packets are not flushed immediately to the network. This can be resolved by creating in the $ORACLE_HOME/network/admin a file called protocol.ora. The parameter tcp.nodelay=yes will force immediate flushing of Net8 packets to the network.

Oracle Advanced Security

The Oracle Advanced Security option includes encryption and checksumming for network security, single sign-on from a single node and integration of distributed processing over a network. Encryption allows domestic and export 40-bit, 56-bit and 128-bit encryption. Single sign-on allows access to multiple user accounts and applications using one password using an authentication method such as SSL.

Net8 Administration and Configuration Tools

Net8 Adminsitration tools are Net8 Configuration Assistant, Net8 Assistant, the listener configuration utility called LSNRCTL, the Connection Manager control utility called CMCTL and the Oracle Names Server utility NAMESCTL.

The Net8 Configuration Assistant and Net8 Assistant are used to configure all Oracle networking aspects. Use netca and netasst on a Unix box. LSNRCTL is used to start, stop and check the status of the listener, ie. LSNRCTL [start | stop | status]. The CMCTL utility allows configuration of the Oracle Connection Manager, ie. CMCTL <command> [cman | adm | cm]. cman executes both CMGW gateway and CMADMIN adminstrative processes. adm executes CMADMIN and cm executes CMGW. The Oracle Names Control utility is executed as NAMESCTL <command>.