Tns oracle что это

Решение2: устанавливаем переменную TNS_ADMIN и проверяем корректность логина/пароля

Первичная конфигурация OID

К этому моменту должны быть выставлены переменные
TNS_ADMIN
LD_LIBRARY_PATH
Предполагается, что NodeManager уже запущен.
Запускаем утилиту WLST:

cd /u/app/oracle/product/middleware/Oracle_IDM1/oracle_common/common/bin export MW_HOME=$ORACLE_HOME 

Довыставляем переменные, которые нужны для работы утилиты WLST

./setHomeDirs.sh ./setWlstEnv.sh ./wlst.sh 

дальше с помощью утилиты WLST подключаемся к NodeManager. Нам потребуется логин и пароль, заданные при инсталляции (указанные для NodeManager, у нас это weblogic)

nmConnect(username='weblogic',password='пароль от NodeManager ',domainName='oid_domain') 

Пример вывода:

[13:45][uhost-oid1.oracle.:/u/app/oracle/product/middleware/Oracle_IDM1/oracle_common/common/bin]$ ./wlst.sh Initializing WebLogic Scripting Tool (WLST) . Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands wls:/offline> nmConnect(username='weblogic',password='*****',domainName='oid_domain') Connecting to Node Manager . Successfully Connected to Node Manager. 

Запускаем инициализацию, во время которой создается инстанс с именем oid1.
В строке ниже:

odsPassword – пароль к схеме ODS на базе репозитория, который был задан при выполнении ./rcu
orcladminPassword – пароль который будет использован в качестве cn=orcladmin для доступа к LDAP
realmDN – LDAP –схема, которая будет сконфигурирована

oid_setup(orcladminPassword='****',odsPassword='***',realmDN='dc=mycompany,dc=ru')

После выполнения должен будет создан компонент (инстанс в терминах FMW) с именем oid1

Проблема3:
Лог /u/app/oracle/config/domains/oid_domain/servers/OID/logs/oid1/oidmon*.log
содержит

/u/app/oracle/product/middleware/Oracle_IDM1/wlserver/../bin/oiddispd: error while loading shared libraries: libclntshcore.so.12.1: cannot open shared object file: No such file or directory

Решение3:
Задаем переменную окружения
LD_LIBRARY_PATH=/u/app/oracle/product/middleware/Oracle_IDM1/lib:$LD_LIBRARY_PATH
перезапускаем NodeManager,
запускаем компонент:

cd /u/app/oracle/config/domains/oid_domain/bin/ nohup ./startNodeManager.sh & ./startComponent.sh oid1 

Если компонет по этой причине создался но не работает, то убиваем процесс oidmon, изменяем в СУБД параметры статуса процесса:

ps –ef|grep oidmon kill oidmon 

sqlplus / as sysdba update ods.ods_process_status set pid=0 where compname='oid1'; update ods.ods_process_status set state=4 where compname='oid1'; 

./ldapbind -h localhost -p 3060 ./ldapbind -h localhost -p 3131 -U 1 -D 'cn=orcladmin' -w **** 

Возможно, придется еще раз выполнить инициализацию oid_setup
Проблема4. При попытке сохранения в NetManager:

oracle.net.common.dataStore.DataStoreException: error writing ServiceAlias to: LDAPDataStore [svr: uhost-oid1.mycompany.ru:3060:3131, type: OID, ctxt: cn=OracleContext,dc=mycompany,dc=ru, home: C:\oracle\product\12.1.0\client_1] original exception message: TNS-04409: Ошибка службы каталогов caused by: oracle.net.config.DirectoryServiceException: TNS-04405: Общая ошибка caused by: oracle.net.ldap.NNFLException original stack trace: oracle.net.config.ServiceAliasException: TNS-04409: Ошибка службы каталогов caused by: oracle.net.config.DirectoryServiceException: TNS-04405: Общая ошибка caused by: oracle.net.ldap.NNFLException oracle.net.config.DirectoryServiceException: TNS-04405: Общая ошибка caused by: oracle.net.ldap.NNFLException oracle.net.ldap.NNFLException 

Решение4:
Еще раз прогнать oid_setup
Проверить настройки ldap.ora на клиенте с которого запускается Net Manager
DEFAULT_ADMIN_CONTEXT = «dc=mycompany,dc=ru»

Изменение параметра OID (для разрешения запросов от анонимных пользователей)
Когда создается TNS-имя с помощью net manager, но не работает tnsping.
Создаем файл:
cat anonymousbind.ldif

dn: cn=oid1,cn=osdldapd,cn=subconfigsubentry changetype: modify replace: orclAnonymousBindsFlag orclAnonymousBindsFlag: 1 

и модифицируем параметры с помощью этого файла:

ldapmodify -D cn=orcladmin -W -p 3131 -h localhost -f anonymousbind.ldif

Диагностика:
tnsping mytest не работает, a ldapsearch работает
Проверяем доступность портов 3060 и 3131(для SSL)

так все работает (с указанием пароля)

ldapsearch -h uhost-oid1.mycompany.ru -p 3060 -D "cn=orcladmin" -w password_hear -b "cn=mytest,cn=OracleContext,dc=mycompany,dc=ru" -s base "objectclass=*"

mytest – созданный ранее псевдоним.

Настройки клиента

На стороне клиента в $ORACLE_HOME/network/admin ложатся файлы:
ldap.ora
sqlnet.ora
tnsnames.ora

Файл tnsnames.ora содержит «локальные» алиасы, как обычно, и используется, если не найдено имя в LDAP.
Файл sqlnet.ora содержит описание порядка резолва:

sqlnet.ora

SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES,LDAP)

Параметры доступа к файлу LDAP задаются в ldap.ora

DIRECTORY_SERVERS = (uhost-oid1.mycompany.ru:3060:3131,rephost-oid1.mycompany.ru:3060:3131) DIRECTORY_SERVER_TYPE = OID DEFAULT_ADMIN_CONTEXT = "dc=mycompany,dc=ru" 

В описанной конфигруации используется следующий порядок.

Сначала просматривется файл tnsnames.ora, если запись там не нашлась, то спрашиваем у LDAP (если нужно сменить порядок, меняем порядок в параметре NAMES.DIRECTORY_PATH

Далее идет запрос к основному серверу LDAP, если он недоступен по каким-то причинам, идем ко второму серверу в списке DIRECTORY_SERVERS

Порядок опроса в данном случае не важен, первым лучше указывать территориально ближайший сервер.

Default admin context (LDAP) используется для контекста по умолчанию, чтобы не указывать каждый раз mycompany.ru

По этой же причине не рекомендуется в записи алиаса использовать точку, он ее воспринимает как домен.

Дальше расскажу, как настроить репликацию между серверами

• Oracle
• Администрирование баз данных

Oracle TNS Listener Security

Oracle clients communicate with the database using the Transparent Network Substrate (TNS) protocol. When the listener receives a connection request (tcp port 1521, by default), it starts up a new database process and establishes a connection between the client and the database. This chapter contains security recommendations for the database TNS listener.

Hardening

Hardening Operating Environment

Follow the hardening instructions for Operating Environment Security.

Hardening External Procedure (EXTPROC) Services

The Oracle database uses the external procedure service to call external C programs. This extends the functionality of PL/SQL to routines that can be written in C to perform complex calculations, such as mathematical modeling or files system interactions. This functionality exploits the ability of the listener to issue operating system commands. The external procedures are supposed to issue the commands to the listener on a special IPC pipe named EXTPROC. The specification exists in the listener.ora parameter file as:

(ADDRESS_LIST = (ADDRESS = (PRTOCOL = IPC) (KEY = EXTPROC))

These external procedures operate by instructing the listener to issue these operating system commands on their behalf. Because the listener runs with the privilege of the operating system user, the only limits on external procedures are the limits on what that account can do.

The following Oracle E-Business Suite components use EXTPROC services:

1. Oracle Multimedia (formerly Oracle interMedia) cartridges
2. Oracle Email Center
3. Oracle Demand Planning Express implementation

To protect against some EXTPROC attack vectors:

1. Create two Oracle TNS listeners, one for the Oracle database and one for PL/SQL EXTPROC.
2. Remove EXTPROC specific entries from the Oracle Database listener configuration files.
3. Configure the Oracle EXTPROC listener with an IPC protocol address only. If TCP connectivity is required, configure a TCP protocol address, but use a port other than the one the Oracle listener for the database is using. Ensure that the Oracle listener created for PL/SQL EXTPROC runs as an unprivileged operating system user (e.g., "nobody" on UNIX). On Windows platforms, run the Oracle TNS listener process as an unprivileged user and not as the Windows LOCAL SYSTEM user. Give this user the operating system privilege to "Logon as a service."
4. If the Oracle listener for PL/SQL EXTPROC has been configured with a TCP address, do the following:
   1. Modify the EXTPROC specific entry in $ORACLE_HOME/network/admin/tnsnames.ora to reflect the correct port for the new Oracle listener.
   2. Enable Valid Node Checking and restrict access to those network clients requiring EXTPROC.
   3. Restrict access to the Oracle listener for PL/SQL EXTPROC only. Use a separate $TNS_ADMIN/sqlnet.ora file for this Oracle listener. Store this file in any directory other than the one in which the database listener.ora and sqlnet.ora files are located. Copy the listener.ora with the configuration of the Oracle listener for PL/SQL EXTPROC into this other directory as well. Before starting the Oracle listener for PL/SQL EXTPROC, set the TNS_ADMIN environment variable (or Windows Registry parameter) to specify the directory in which the new configuration files for PL/SQL EXTPROC are stored.

   EXTPROC Listener Configuration

   See below for the format of the dedicated EXTPROC listener. The parameters appear in $TNS_ADMIN/listener.ora . Replace the $ORACLE_SID with the name of the Oracle database instance (SID), $ORACLE_HOME with the value of ORACLE home directory for this listener, and $TNS_ADMIN with the directory location of the listener parameter files.

   $ORACLE_SID_EXTPROC = (ADDRESS_LIST = (ADDRESS= (PROTOCOL= IPC)(KEY= EXTPROC$ORACLE_SID)) ) SID_LIST_$ORACLE_SID_EXTPROC = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = $ORACLE_HOME) (PROGRAM = extproc) ) ) STARTUP_WAIT_TIME_$ORACLE_SID_EXTPROC = 0 CONNECT_TIMEOUT_$ORACLE_SID_EXTPROC = 10 TRACE_LEVEL_$ORACLE_SID_EXTPROC = OFF LOG_DIRECTORY_$ORACLE_SID_EXTPROC = $TNS_ADMIN LOG_FILE_$ORACLE_SID_EXTPROC = $ORACLE_SID_EXTPROC TRACE_DIRECTORY_$ORACLE_SID_EXTPROC = $TNS_ADMIN TRACE_FILE_$ORACLE_SID_EXTPROC = $ORACLE_SID_EXTPROC

   The configuration below should appear in $TNS_ADMIN/tnsnames.ora . Replace $ORACLE_SID with the name of the Oracle database instance (SID).

   extproc_connection_data = (DESCRIPTION= (ADDRESS_LIST = (ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC$ORACLE_SID)) ) (CONNECT_DATA= (SID=PLSExtProc) (PRESENTATION = RO) ) )

   Example: EXTPROC Listener Configured Separately

   This example shows how to configure EXTPROC listener services. In it, the LISTENER NAME is VSEC_EXTPROC and ORACLE_SID is VSEC.

   VSEC_EXTPROC = (ADDRESS_LIST = (ADDRESS= (PROTOCOL= IPC)(KEY= EXTPROCVSEC)) ) SID_LIST_VSEC_EXTPROC = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = /u01/oracle/vsecdb/10.2.0.5) (PROGRAM = extproc) ) ) STARTUP_WAIT_TIME_VSEC_EXTPROC = 0 CONNECT_TIMEOUT_VSEC_EXTPROC = 10 TRACE_LEVEL_VSEC_EXTPROC = OFF LOG_DIRECTORY_VSEC_EXTPROC = /u01/oracle/vsecdb/10.2.0.5/network/admin LOG_FILE_VSEC_EXTPROC = VSEC_EXTPROC TRACE_DIRECTORY_VSEC_EXTPROC = /u01/oracle/vsecdb/10.2.0.5/network/admin TRACE_FILE_VSEC_EXTPROC = VSEC_EXTPROC

   Example: The tnsnames.ora Parameter That Corresponds to EXTPROC Listener

   extproc_connection_data = (DESCRIPTION= (ADDRESS_LIST = (ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROCVSEC)) ) (CONNECT_DATA= (SID=PLSExtProc) (PRESENTATION = RO) ) )

   EXTPROC Testing Procedure

   This section explains a procedure to test if EXTPROC is enabled. The EXTPROC listener must be configured and working for the Oracle Multimedia option to run. Perform the following to test whether or not Oracle Multimedia is working:

   Create a user to work with Oracle Multimedia text:

   create user textuser identified by default tablespace users temporary tablespace temp;

   grant connect, resource, ctxapp to textuser;

   connect textuser/ drop table quick; create table quick ( quick_id number constraint quick_pk primary key, text varchar2(80) 0; insert into quick ( quick_id, text ) values ( 1, 'The cat sat on the mat' ); insert into quick ( quick_id, text ) values ( 2, 'The quick brown fox jumps over the lazy dog' ); insert into quick ( quick_id, text ) values ( 3, 'The dog barked like a dog' ); commit; create index quick_text on quick ( text ) indextype is ctxsys.context; col text format a45 col s format 999 select text, score(42) s from quick where contains ( text, 'dog', 42 ) >= 0 order by s desc;

   If the above query works without any error, the Oracle Multimedia option is enabled and the EXTPROC listener is properly configured.

   Cleanup the test user ( textuser ) created during this test.

   Network

   Adding IP Restrictions / Enable Valid Node Checking

   Valid Node Checking allows or denies access from specified IP addresses to Oracle services. Oracle recommends using an allowlist of IP addresses that are authorized to make a TCP connection to the database listener. To enable Valid Node Checking, set the following parameters in $TNS_ADMIN/sqlnet.ora :

   tcp.validnode_checking = YES tcp.invited_nodes = ( x.x.x.x, hostname.domain, . )

   The first parameter turns on Valid Node Checking. The next parameter specify the IP addresses or host names that are permitted to make network connections to the database. Replace x.x.x.x with the application tiers' IP addresses. Application tier components include web servers, forms servers, concurrent managers, terminal servers, central administrator machines, and any remote monitoring tool that uses SQL*Net.

   Note: The use of SQLNet desktop clients such as sqlplus, sqldeveloper, toad, or ADI from a windows desktop is not recommended on production databases. If implemented, the desktop cannot use DHCP (unless the DHCP server is configured with address reservation). Oracle recommends that only trusted servers be allowed to make direct database connections.

   AutoConfig supports automated configuration of this setting. If the profile option "SQLNet Access" (FND_SQLNET_ACCESS) is set to "ALLOW_RESTRICTED" at the site level when AutoConfig is run on the database server, AutoConfig will add IP restrictions to sqlnet.ora . The list of host will be all those from the FND_NODES table that are registered as an Oracle E-Business Suite node.

   For more information, refer to the "Technical Configuration" chapter of the Oracle E-Business Suite Setup Guide, Release 12.2.

   The easiest way to verify this is to implement a manual check from a node not in the allowlist. You should not be able to connect (by using Ncat, for example) to the database listener port. When connecting through an untrusted node, it should look like this:

   # nc -v db.example.com 1521 Ncat: Version 7.70 ( https://nmap.org/ncat ) Ncat: Connected to X.X.X.X:1521. Ncat: Broken pipe.

   The listener log will show this for a connection attempt from a client that is not "invited".

   . Incoming connection from Y.Y.Y.Y rejected . TNS-12546: TNS:permission denied TNS-12560: TNS:protocol adapter error TNS-00516: Permission denied

   Specifying Connection Timeout

   In $TNS_ADMIN/listener.ora , set the following parameter:

   Where PRD12 is the value of the ORACLE_SID in this example.

   Use the parameter CONNECT_TIMEOUT to specify the amounts of time, in seconds, for the Oracle listener to wait for the connection from a client to complete.

   Enabling Encryption of Network Traffic

   This section describes configuration options and recommendations for enabling encryption of database network traffic.

   The following table is a summary of the three available configurations for encrypting traffic to the Oracle E-Business Suite database, which are described in more detail in the sections to follow.

   Configuration Options for Encrypting Network Traffic to the Oracle E-Business Suite Database

   Configuration Option	Database	Oracle E-Business Suite Application Tier Connections	Other Client Connections
   Configuration 1: Enable Native Network Encryption on the Database Listener and Use TCP for All Client Connections	TCP with Native Network Encryption (NNE)	TCP	TCP
   Configuration 2: Enable Native Network Encryption on the Database Listener and Enable TCPS for Non-Oracle E-Business Suite Application Tier Client Connections	TCP with NNE	TCP	TCPS
   Configuration 3: Enable TCPS for All Client Connections	TCPS	TCPS using Oracle Connection Manager (CMAN)	TCPS

   Configuration 1: Enable Native Network Encryption on the Database Listener and Use TCP for All Client Connections

   In this configuration, native network encryption (NNE) is enabled on the database listener and a TCP connection is used for both Oracle E-Business Suite and non-Oracle E-Business Suite clients.

   For most environments, NNE in conjunction with following guidance for Oracle E-Business Suite secure configuration deployment is sufficient for securing connections to your database. Oracle E-Business Suite secure configuration deployment provides additional protection for your Oracle E-Business Suite application and database tiers and includes the use of subnets, firewalls, and DMZs.

   To set up Configuration 1, perform the following steps:

   1. Deploy your Oracle E-Business Suite environment per the recommendations outlined in Restricting Network Access to Critical Services in "Overview of Secure Configuration."
   2. Enable NNE for the database using the following steps:
      1. Add the following lines to the $TNS_ADMIN/sqlnet_ifile.ora in your database Oracle home:

      SQLNET.ENCRYPTION_SERVER=REQUIRED SQLNET.ENCRYPTION_TYPES_SERVER=(AES128,AES192,AES256) SQLNET.CRYPTO_CHECKSUM_SERVER=REQUIRED SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER=(SHA256,SHA1) SQLNET.CRYPTO_SEED= SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS=TRUE

      SQLNET.ALLOW_WEAK_CRYPTO_CLIENTS=TRUE

      Configuration 2: Enable Native Network Encryption on the Database Listener and Enable TCPS for Non-Oracle E-Business Suite Application Tier Client Connections

      If you determine that encryption of database client connections other than the Oracle E-Business Suite application tier node database connections is a requirement for your environment, in addition to NNE you may enable TCPS for these client connections to the Oracle E-Business Suite database.

      To set up Configuration 2, perform the following steps:

      1. Enable NNE for the database using the instructions in step 2 of Configuration 1.
      2. Enable TCPS for non-Oracle E-Business Suite application tier client connections. For more information, see My Oracle Support Knowledge Document 2867473.1, Enable TCPS (TLS1.2) for Clients Outside the Oracle E-Business Suite Application Tier.

      Configuration 3: Enable TCPS for All Client Connections

      If you determine that encryption of all database client connections including Oracle E-Business Suite application tier connections is a requirement for your environment, you may enable TCPS for all database client connections to the Oracle E-Business Suite database. Refer to My Oracle Support Knowledge Document 2787151.1, Enable TCPS (TLSv1.2) for SQL*Net Traffic in Oracle E-Business Suite Release 12.2.

      Authorization

      Enabling Admin Restrictions

      You should configure the database listener with ADMIN_RESTRICTIONS set to ON. When ADMIN_RESTRICTIONS is ON, all the set commands in lsnrctl are disabled and the only way to change the configuration is to edit the listener.ora file.

      In $TNS_ADMIN/listener.ora , set the following parameter:

      where VIS12 is the name of the listener (equal to ORACLE_SID in Oracle E-Business Suite)

      AutoConfig can set this if you set the AutoConfig variable s_admin_restrictions to ON and run AutoConfig on the database server.

      Audit

      Enabling TNS Listener Logging

      To enable logging, in $TNS_ADMIN/listener.ora set the following parameters:

      LOG_STATUS = ON LOG_DIRECTORY_$ORACLE_SID = $TNS_ADMIN LOG_FILE_$ORACLE_SID = $ORACLE_SID

      LOG_STATUS = ON LOG_DIRECTORY_VIS12 = /u/db/tech_st/10.2.0/network/admin/VIS12_dbs01 LOG_FILE_VIS12 = VIS12

      Where VIS21 is the LISTENER_NAME .

      This is done by default in Release 12.

      Notice that newer database versions use the richer ADR log settings. This silently overrides/ignores the older LOG settings. See Oracle Database documentation for more details.

      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

      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

      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

      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

      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

      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.

      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:

      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 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:

      
      GIOP as the presentation layer rather than Two-Task Common

      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

      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.

      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

      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.

      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

      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:

      
      The listener is started and listens on either a default address or the addresses specified in its configuration file.

      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.

      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:

      
      The client connects to the listener with the network address.

      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

      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.

      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 listener is started and listens on an address specified in a listener configuration file.

      In a partial address listen, the server process listens, but informs the underlying protocol stack that it has no preference as to the specific address it will listen on. As a result, many protocol stacks will choose a free listening address and automatically assign this to the requesting server process.

      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:

      
      The listener is started and listens on an address specified in a listener configuration file (LISTENER.ORA).

      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.

      When an instance is started, initialization parameters are read from the INIT SID .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.

      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.

      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.

      Implementing connect-time failover does not allow use of static service configuration parameters in the LISTENER.ORA file. However, static configuration is required for Oracle8 i 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.

      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:

      
      A database registering its service with an Oracle Names server.

      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.

      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.

      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.

      
      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.

      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.

      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.

      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

      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 connections 1 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.

      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.

      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.

      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

      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

      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

      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

      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.

      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

      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.

      
      Copyright © 1999 Oracle Corporation.
      All Rights Reserved.

      Похожие публикации:

      1. Как пушить в гитлаб
      2. Как работает функция смещение в excel
      3. Как увеличить разрядность мультиплексора
      4. Как увеличить шрифт в выпадающем списке excel