Release 1 (9.0.1) for Alpha OpenVMS
Part Number A90868-01
 |  Contents |
 Index |
| Oracle9i Administrator's Reference Release 1 (9.0.1) for Alpha OpenVMS Part Number A90868-01 |
|
This chapter provides general conceptual information about Oracle Net in the Alpha OpenVMS environment.
It contains he following topics:
Oracle Net is a communications software product that allows you to create a data management environment to share information stored in Oracle databases. Oracle Net uses the communications protocols supported by various operating systems to provide a distributed processing and distributed database environment for Oracle. Oracle Net also refers to a set of products or adapters that support industry-standard protocols such as TCP/IP.
An Oracle database management system can be configured in one of the following ways:
In Figure 1-1, Ethernet is an example only. Oracle Net works with other network types.
In a centralized configuration, the Oracle9i Enterprise Server and Oracle tool are located on the same machine. This machine is not necessarily on a network and you can access the application through terminals. If you use a centralized configuration, you may use a simple Oracle Net adapter called the bequeath adapter, which requires no Oracle Net configuration. However, if you wish to use multithreaded servers, you must configure Oracle Net even in centralized configurations.
In a Client/Server configuration as shown in Figure 1-1, the Oracle9i Enterprise Server resides on a multi-tasking server system, and the client side of the applications resides on another computer, such as a workstation or personal computer. Both the client and server are connected by a physical network and communicate via a network protocol such as TCP/IP. In a Client/Server environment, the Oracle application built with an application development tool makes database requests to the server over the network.
In a distributed database configuration as shown in Figure 1-1, users query separate databases as a single database. The major advantage of a distributed database is that users and applications are not required to know where the data resides. You can query database tables by name, regardless of how the network protocols work together to access the appropriate remote database containing the table. Therefore, Oracle Net users can communicate and share database information stored in different locations, on different computers, with different operating systems. Distributed databases allow local administration of data and can reduce network traffic if the data that is accessed most often at a location can be stored locally.
Oracle Net allows the client and server to communicate over a variety of media and protocols. A client/server configuration allows DBAs to distribute CPU-intensive user interfaces to low-cost workstations. It also allows application users to be greeted with the graphical user interface (GUI) with which they are most familiar.
When installing Oracle Net on Alpha OpenVMS, you can choose to install the Oracle Net TCP/IP adapter.
In addition, the Alpha OpenVMS Mailbox adapter is installed automatically, as is the bequeath adapter, which allows mailbox connections without a network configuration.
See the Oracle9i for Alpha OpenVMS Installation Guide for instructions on installing Oracle Net. Also see the file ORA_RDBMS:READMEVMS.DOC and ORA_NETCONFIG:README_NETCONFIG.DOC for more installation details.
This section introduces Oracle Net in general terms and describes the components that make up Oracle Net for Alpha OpenVMS Release 1 (9.0.1)
Oracle Net connects dissimilar networks together and allows client/server transactions to occur transparently. An end user does not have to know that a network exists, because Oracle Net hides the complexity of machine-level interactions by presenting a layer of interconnectivity to the user through its client/server architecture. This layer is called the Transparent Network Substrate, or TNS.
Figure 1-2 shows a client/server configuration using Oracle Net.
Figure 1-2 shows an Alpha OpenVMS computer that holds the physical Oracle9i database and a client workstation with an Oracle Forms application that needs to access the Oracle9i database. The Alpha OpenVMS computer (A in the Figure 1-2) is the server and the workstation (B in the Figure 1-2) is the client.
The transaction proceeds as follows:
Oracle Net consists of the following components:
The Oracle Net interface bundles or unbundles messages received from TNS. The Oracle Net interface code resides on all nodes that use Oracle Net. On the client (application program) side, the interface bundles the messages received from the application and passes them to TNS for delivery. On the Oracle9i Enterprise Server side, the interface unbundles the messages received from TNS and passes them to the Oracle9i Enterprise Server.
TNS allows peer-to-peer connectivity where no machine-level connectivity can occur. It provides a user-transparent layer that enables a heterogeneous network consisting of different protocols to function as a homogeneous network. TNS forms a transparent layer to which different network protocols are connected. It provides a network of applications above the existing networks of computers.
The Oracle Protocol Adapters allow TNS and its services to communicate over existing network communication protocols. The Protocol Adapters map the functions of the underlying protocol into the equivalent functions within TNS. This mapping of communication functions allows calls to or from TNS to be nonspecific protocol.
Figure 1-3 shows how TNS and the Oracle Protocol Adapters interface with existing network protocols. For any TNS client running an industry-standard protocol, the Oracle Protocol Adapter interfaces between the unique API of the underlying protocol and the consistent interface of Oracle's TNS.
A single machine can support multiple protocols and protocol adapters simultaneously. A node that supports multiple protocols and protocol adapters is said to be a member of multiple TNS communities, one for each protocol installed.
A TNS client belonging to multiple communities is common in two cases:
For more information about Oracle Net, see the following manuals:
This section gives information about the following protocol adapters on Alpha OpenVMS:
The Mailbox protocol adapter, or IPC adapter, is automatically configured for use when you install Oracle Net. It can be used for Client/Server connections when both client and server are on the same Alpha OpenVMS node. If the client and server are on different machines, then the connection must take place using TCP/IP.
When configuring the TNS listener to listen for mailbox connections, you need to specify a KEY value in LISTENER.ORA for the IPC protocol. The listener then creates a mailbox which listens for connections and creates a system-wide logical name (the same as the KEY value) which translates to this mailbox device. It is via this logical name that clients find the listener's mailbox.
The following fields must be defined:
(PROTOCOL=IPC) (KEY=<IPC logical name>)
where:
The keyword that identifies the specific protocol adapter used; for this protocol, the value is IPC. The value can be entered in either uppercase or lowercase.
The logical name used to connect to the listener via the Mailbox adapter.
This example shows the two fields for the Alpha OpenVMS Mailbox adapter.
(PROTOCOL=IPC) (KEY=ORA_IPC)
The TCP/IP protocol adapter provides support for Client/Server connections using TCP/IP as a protocol. You can turn Oracle Net support for TCP/IP on or off via the NetConfig configuration screen (see the Oracle9i for Alpha OpenVMS Installation Guide).
Oracle Net on Alpha OpenVMS is developed and certified using Compaq's TCP/IP Services for OpenVMS (UCX). If you wish to use the TCP/IP protocol adapter for Oracle Net, you should have Version 5.0a TCP/IP Services for Alpha OpenVMS installed. TCP/IP protocol stacks from other vendors may work with Oracle, but customers use these products at their own risk. Any TCP/IP problems that can not be reproduced using TCP/IP Services for Alpha OpenVMS will simply be referred to the TCP/IP vendor.
The following fields must be defined:
(PROTOCOL=TCP) (HOST=hostname) (PORT=port#)
The following field is optional:
(QUEUESIZE=n)
Keyword that identifies the specific protocol adapter used; for this protocol, the value is TCP. The value can be entered in either uppercase or lowercase.
Host name or IP address.
TCP/IP port number.
Parameter to increase the queue size. This parameter is optional; if it is not specified, the default value is 20. If simultaneous connections are made to the listener, some connection requests may not be received if the listener socket queue size is too small.
In this example, the TCP/IP connect descriptor specifies a listener on the ALPHA1 host.
(PROTOCOL=TCP) (HOST=ALPHA1) (PORT=1526)
Each database that you wish to connect with the bequeath adapter must have a command file named ORASRV_BEQ_<sid>.COM in ORA_ROOT:[NETWORK.ADMIN]. For databases created with the Oracle7 RDBMS Release 7.3.2 or later, this command file is generated when you create the database. You must create this command procedure manually for pre-existing databases. Edit the ORA_ROOT:[NETWORK.ADMIN]ORASRV_BEQ_COM.SAMPLE file or execute the command procedure ORA_NETWORK:CREATE_ORASRV_BEQ.COM as follows:
$ @ORA_NETWORK:CREATE_ORASRV_BEQ <ora_db> <sid> <dbname>
where:
<ora_db> is the database administration directory;
<sid> is the SID of the database, and
<dbname> is the NAME of the database.
For example:
$ @ORA_NETWORK:CREATE_ORASRV_BEQ DKA400:[Oracle9.DB_PROD] -
PROD PRODDB
The Bequeath Listener, running as a detached process, creates detached server processes to service clients on the same machine, using the bequeath adapter. This allows the Oracle server to run in a suitably privileged process. The alternative would be to have the server installed with privileges and run in a subprocess of the client. However, that would require the server to be linked without traceback information, making server trace information unusable if problems are encountered.
For each request from the client, the Bequeath Listener creates a detached server process and two mailboxes. It then sends the mailbox names to the client and the client establishes a connection to the server using these mailboxes.
By default, these mailboxes are created with a buffer quota of 8192 bytes and a maximum message size of 2048 bytes. You can change these parameters by defining logical names in the file ORASRV_BEQ_<SID>.com with other values. For example:
$ define ORA_BEQ_MBXSIZ n $ define ORA_BEQ_MBXBFQ n
The maximum value for the mailbox buffer quotas is 60000 bytes. You should adjust these values carefully, and you should adjust them for performance reasons only.
The Bequeath Listener uses a known mailbox name to listen for client requests. This mailbox name is in the format:
ORA_BEQ_READ_MBX_xxxxxxxxxx_n
where:
xxxxxxxxxx is the Oracle image ID unique to the system (padded with zeroes).
n is a single-digit number (0-9) that is the Bequeath Listener number.
The Bequeath Listener starts automatically when INSORACLE is invoked (at installation time or later, usually during system startup). Unless you decide to invoke the REMORACLE command, the Bequeath Listener should be up and running all the time.
If the Bequeath Listener is down and you want to start it, execute the command:
BEQLSNR START
You can issue a status command to determine whether the Bequeath Listener is up and running. Issue the command:
BEQLSNR STATUS [n]
If you do not provide the optional numeric parameter, then Bequeath Listener 0 is queried. To query Bequeath Listeners 1 through 9, if they exist, supply the number on the command line.
To stop the Bequeath Listener issue the command:
BEQLSNR STOP [n]
If you do not provide the optional numeric parameter, then all Bequeath Listeners for the installation are stopped. To stop a particular Bequeath Listener, provide its number in the command line.
The Bequeath Listener writes some trace information, but because the output of the detached processes is set to the null device (NL:), normally you will not see it.
To get the trace information from the Bequeath Listener, you should do the following:
To change the quota, modify the file BEQLSNR.COM and remove the comments for the quota parameter that you want to change. Be sure to STOP/START the Bequeath Listener after modifying this file.
Be sure that the image identifier string is present in the ORA_BEQ_READ_MBX system logical name. It must be the same as the equivalence - name for the ORA_BEQ process logical.
To verify this, issue the command:
$ show logical *beq*
The results displayed will look similar to the following:
(LNM$PROCESS_TABLE) "ORA_BEQ" = "Z910000000" (LNM$SYSTEM_TABLE) "ORA_BEQ_READ_MBX_Z910000000_0" = "MBA6839:"
If you experience this problem, issue the command BEQLSNR STATUS to determine whether the Bequeath Listener is up and running. If the Bequeath Listener does not respond, use the command BEQLSNR STOP to stop the Bequeath Listener and use the command BEQLSNR START to restart it.
Choose one of the following solutions:
or
With this method, you can increase the number of connections that the Bequeath Listeners can handle at one time. Each time that a client requests a connection, it will randomly pick one of the Bequeath Listeners that are running to serve it with the connection request. Note that you do not need to STOP/START the Bequeath Listener after defining this logical name. This logical name determines the number of Bequeath Listeners.
The process in which the Bequeath Listener runs must have the OpenVMS privileges in the table below to be able to perform the associated function:
The function of the TNS Listener is to receive connection requests from local or remote clients and to provide the client with a Server process to which to connect. The Listener can service multiple instances. For each instance, the Listener keeps a list of services that provide access to that instance. If multi-threaded servers are being used, the Listener may direct a client connection to a dispatcher. Otherwise, for dedicated servers, the Listener will direct the client connection to an existing multithreaded server or will create a new server process to service the connection.
In Oracle9i, there is a major change in the way the listener is configured for Oracle Shared and Multithreaded Servers. The Oracle Shared Server parameters are no longer the same as in Oracle9i. When you configure for Oracle Shared Server, a request for a "Dedicated Server" is no longer handled using the parameters from the LISTENER.ORA file. This now happens as part of the dispatcher registration. The PMON process registers dispatchers with the listener for Oracle Shared Server connections. The SID_LIST_<listener> section is no longer used to establish dedicated server connections. These are now automatically handled by the listener, which directly uses the script ORA_ROOT:[NETWORK.ADMIN]ORASRV_NETV2_<SID>.COM to launch the dedicated server process. This script is automatically created when a new database/instance is created.
General information about the Listener and its configuration can be found in the generic Oracle Net documentation. This section provides only information about the Listener that is specific to Alpha OpenVMS.
The LSNRCTL utility is used to start and stop the Listener and to query its status or services. The LSNRCTL command executes the command procedure ORA_NETCONFIG:LSNRCTL.COM, which provides a shell to the executable program ORA_NETCONFIG:LSNRCTL.EXE.
The main function of the command procedure is to check that the privileges required to start the Listener are present (see the next section"Listener Privileges"). If a LSNRCTL START command is entered and the required privileges are not present, an error is displayed and LSNRCTL exits.
The process in which the Listener runs must have the Alpha OpenVMS privileges in the table below to be able to perform the associated function.
Process quotas for the Listener and for the Server processes which the Listener creates can be controlled by logical names. The logical names are:
ORA_LSNR_<quotaname>
where:
<quotaname> can be either or one of these, ASTLM, BIIOLM, BYTLM, CPULM, DIOLM, FILLM, PGFLQUOTA, PRCLM, TQELM, WSQUOTA, WSDEFAULT, ENQLM, WSEXTENT, or JTQUOTA.
Several of the logical names are defined in LSNRCTL.COM and control the quotas of the Listener process. They are defined in user mode so that they are not present after exiting LSNRCTL. If your Listener supports an especially large number of services, some of these quotas may need to be increased. For the quotas you determine to be deficient or under direction of Oracle Support, you can edit the quota values in LSNRCTL.COM.
To control the quotas of the processes that the Listener creates, specify the logical names in the file ORA_NETWORK:TNSLSNR.COM, the command file that runs in the Listener process. Statements to define these logical names are in TNSLSNR.COM, but are commented out.
If, for example, a very large file backed SGA requires that Server processes have larger quotas, you can uncomment the appropriate logical name definition in TNSLSNR.COM and specify the quota value. Starting with release 7.3.2.3.2 and the VLM feature, a file backed SGA is created when the INIT.ORA parameter VLM_BACKING_STORAGE_FILE is set to TRUE.
Quotas can also be specified for the Server processes in the LISTENER.ORA file on a SID-by-SID basis. This is done in the SID_DESC section for a Listener. For example:
SID_LIST_LISTENER =
(SID_DESC =
(SID_NAME = <name>)
(PROGRAM = <disk:>[<directory>]ORASRV_NETV2_<SID>.COM)
(OSDS=
(PRIORITY=<number>)
(QUOTA=
(ASTLM=<number>)
(BYTLM=<number>)
(PGFLQUOTA=<number>)
)
)
)
There are no restrictions on the number of quotas that you can specify in the QUOTA list. However, if any quota is specified in the QUOTA list, then none of the quotas specified by logical name will be used and quotas that are not specified in the list will assume the system default.
|
Warning: The process priority of the Server process can also be specified, as in the example above, but this is not recommended. |
The file ORASRV_NETV2_<SID>.COM is automatically created for each SID during creation of the new database/instance.
In an non-Oracle Shared Server situation, the behavior is the same as seen in earlier releases. The "PROGRAM=" parameter should point to this script in the LISTENER.ORA. Here's an example:
(SID_LIST_LISTENER = (SID_DESC = (SID_NAME = PROD) (PROGRAM = DK:[O901.NETWORK.ADMIN]ORASRV_NETV2_PROD.COM) ) )
When the listener starts a dedicated server process, it extracts the PROGRAM= parameter from the LISTENER.ORA file to identify which command procedure to run in the dedicated process.
In an Oracle Shared Server configuration, the listener need not contain the above-mentioned SID_LIST_<listener> section. The Oracle Shared Server dispatchers registers with the listener directly, including specifying the command procedure to run for a "Dedicated Procedure".
This command procedure is currently hard-coded to be ORA_ROOT:[NETWORK.ADMIN]ORASRV_NETV2_<SID>.COM which is created automatically. The location and name-syntax of this file cannot be changed. Even if a SID_LIST section is specified in listener.ora that might point to the same or different script, it is completely ignored.
Make sure that your Oracle Net task file defines any logical names used by the INIT.ORA parameters USER_DUMP_DEST and BACKGROUND_DUMP_DEST (if defined).
If you define these logical names by calling ORA_DB:ORAUSER_<database_name>.COM, make sure that ORA_UTIL:ORAUSER.COM runs RDBMSUSER.COM after PROGINTUSER.COM.
PROGINTUSER.COM also defines ORA_SLAX, making it into a search list with ORA_PROGINT_MESG and ORA_RDBMS.
The function of the Names Server is to resolve connection addresses in a homogeneous and centralized location. As a client issues a connection request, the Names Server is responsible for directing the client connection request to the appropriate listener for the specified SID. TNSNAMES.ORA can also resolve the listener address. However, the benefits of the centralized list of connection addresses that Oracle Names provides greatly eases the maintenance of large network definitions.
This section provides information about Oracle Names on Alpha OpenVMS. It covers the following topics:
|
Note: This section assumes that Oracle Names and all related Oracle Net products have been installed at your site. |
The NAMESCTL utility is used to start and stop the Names Server and to query its status or services. The NAMESCTL command executes the command procedure ORA_NETCONFIG:NAMESCTL.COM, which provides a shell to the executable program ORA_NETCONFIG:NAMESCTL.EXE.
The main function of the command procedure ORA_NETCONFIG:NAMESCTL.COM is to check that the privileges required to start the Names Server are present (see the section "Names Server Privileges"). If a NAMESCTL START command is entered and the required privileges are not present, an error is displayed and NAMESCTL exits.
The process in which the Names Server runs must have the Alpha OpenVMS privileges in the table below to be able to perform the associated function.
Before you can use Oracle Names, the following configuration files must be in the ORA.ROOT:[NETWORK.NAMES] directory of the system that calls Oracle Names:
The SDNS.ORA file contains a list of preferred names servers. This file is updated to reflect the names and addresses of all the known servers that Names Server is running. The initial startup requires that SDNS.ORA identifies, at a minimum, the specifics for its own address. For example, to start a Names Server to set up at port 1575 the SNDS.ORA file should contain the following:
NAMES.PREFERRED_SERVERS =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = avms04)
(Port = 1575)
)
)
The easiest way to facilitate this is to simply modify the provided SDNS_ORA.SAMPLE file to suit your purposes. Additionally, the NAMESCTL REORDER_NS will generate the SDNS.ORA file.
The Names Server environment can be more tightly controlled through the following (optional) files in the TNS_ADMIN directory:
The SQLNET.ORA file is read by both the client, as part of a connection request, and by NAMESCTL, for all operations other than server startup. This file identifies the Names service to be used to resolve the connection. Within SQLNET.ORA, the NAMES.PREFERRED_SERVERS list specifies to the client the address of the Names Server with which to connect.
The NAMES.ORA file describes the Names Server and is read by NAMESCTL.EXE at Server startup. NAMES.ORA identifies, among other things:
The Agent is a backend server process that communicates with the Oracle Enterprise Manager (OEM) running on a Windows or UNIX machine.
This section provides information about installing and running the Oracle Intelligent Agent (hereafter referred to as "the Agent") on Alpha OpenVMS. Read this section carefully and completely before beginning to install and use the Agent and SNMP Support on Alpha OpenVMS.
This section covers the following topics:
The Agent requires that a supported TCP/IP implementation be installed on your Alpha OpenVMS system. In addition, you must enable TCP/IP support for Oracle Net in the NetConfig configuration screen.
For more information, see Chapter 3, "TNS Listener" in this manual.
The Agent may be installed at the same time as other products or it may be installed later.
Installation of the Agent creates the directory ORA_ROOT:[OEMAGENT] as an installation directory. It also creates a directory structure under the network subdirectory ORA_ROOT:[NETWORK.AGENT...] where most of the Agent files will reside.
If you are using the same Oracle Installation from more than one node in a Alpha OpenVMS cluster, you can only run the agent from this installation on one of the nodes. If you attempt to run the agent on multiple nodes from the same installation, there will be file name and file usage conflicts. This is a generic limitation of the Oracle Intelligent Agent on Clusters for all platforms.
For each additional node on which you wish to run the Agent, you must perform a client-only installation for the Agent (installing AGENT, NETCONFIG, and UTIL) and run the Agent from this client-only installation.
To correctly set up the Agent environment, the following two kinds of files need to be created:
Once the Agent has been successfully installed, create the following two files:
To create these two files, modify AGENT_START_COM.SAMPLE and DBSNMPJ_COM.SAMPLE to replace the definition of symbol ORA_ROOT with the correct path for your installation and save them appropriately as a .COM file. When you startup the Agent, AGENT_START.COM is run as a Detached Process.
At startup, and when requested by the OEM console thereafter, the agent runs a Tcl script called NMICONF.TCL, which resides in the ORA_ROOT:[NETWORK.AGENT.CONFIG] directory. This script starts by reading ORA_RDBMS:ORA_RDBMS_SIDS.DAT to discover any locally installed Oracle databases and instances. Then it reads an optional ORATAB.ORA file, if present, in the TNS_ADMIN directory.
The ORATAB.ORA file should be as follows:
<sid_name>,<network admin directory>
For example:
ORA9,disk$d1:[Oracle9.NETWORK.ADMIN]
Note that you can specify any SID that you want the Agent to monitor that exists on this node.
Then, for each database instance found in ORATAB.ORA, the tnsnames list is searched for an address on the local host with the appropriate SID in the CONNECT_DATA. The key corresponding to the first matching address in the list becomes the name of the database. The listener.ora found in those same directories is searched for the SID of the database. Again, the first listener that matches our SID becomes the listener active for that database.
The configuration files SNMP_RO.ORA and SNMP_RW.ORA are created.
The file SNMP_RO.ORA should reside at TNS_ADMIN, the same location as the TNS config files. This file contains lines from the old SNMP.ORA that should never be touched by you:
The file SNMP_RW.ORA should reside at TNS_ADMIN, the same location as the TNS config files. This file contains the following lines from the old SNMP.ORA that are automatically generated, but you may want to modify or add to them:
|
Note: The choice of TRUE or FALSE determines whether the agent should try to register itself with Oracle Names. |
The following lines are not automatically generated, but may be added to the SNMP_RW.ORA file:
The Tcl script NMICONF.TCL can execute other Tcl scripts written specifically to discover other Oracle services. If these other scripts exist, they should be installed with NMICONF.TCL in ORA_ROOT:[NETWORK.AGENT.CONFIG].
The file ORA_OEMAGENT:SERVICES.ORA is created during the discovery phase, and will be used to tell the OEM which services the Agent is monitoring.
The preferred credentials are supported from the OEM console. To run a job on the HOST database, you must supply username/password in the preferred credentials fields in the OEM console. To check that the username/password is valid, login to the HOST node where the Intelligent Agent is running and issue the command:
$ show process/right
to see that the account is not disabled and that it has the ORA_AGENT_ID identifier.
This section explains how to startup, shutdown, and status query of the Agent.
The Agent consists of a single process DBSNMP. In addition, when a "job" is executed, it creates a new detached JOB process running DBSNMPJ.COM.
Use the following command to startup the Agent:
$ AGENTCTL start
This command creates a detached process with a process name of ORA_AGENTWORK.
If a nonzero trace level is specified, then the Agent creates a trace file with the name DBSMP_<pid>.TRC in the ORA_ROOT:[NETWORK.TRACE] directory.
Use the following command to shutdown the Agent:
$ AGENTCTL STOP
Use the following command to verify whether the Agent is running:
$ AGENTCTL STATUS
Unlike the listener process, the Agent processes are in a continuous loop, polling for incoming connections in each loop. This means that trace information is continuously being generated. Therefore, it is advisable to turn off tracing during normal operation and to turn it on only when a problem is encountered.
SNMP is supported by using Intelligent Agent as an Oracle sub-agent. To enable SNMP support, choose "Y" in the SNMP support line when configuring the Agent.
PEER master agent is currently supported. To run PEER master agent, change the following two files, as follows:
Then connect to Oracle using the SYS account to run the CATSNMP.SQL script from the ORA_OEMAGENT directory, unless it was already run when the Agent was configured.
To use SNMP Support, start the SNMP master agent before starting the TNS Listener and before starting the Intelligent Agent.
@ORA_NETWORK:STARTUP_PEERAGENT
@ORA_NETWORK:STATUS_PEERAGENT
@ORA_NETWORK:SHUTDOWN_PEERAGENT
For additional information, see the Oracle SNMP Support Reference Guide.
This section provides Alpha OpenVMS-specific installation information for the current release of Advanced Security Option (ASO) for Security and Single Sign-On.
The topics covered are as follows:
Use this section to install ASO, then see the Administrator's Guide for operating instructions. For further information about installing Oracle Net products, see the Oracle9i for Alpha OpenVMS Installation Guide.
This section details installation requirements for ASO on Alpha OpenVMS.
The topics covered in this section are:
The Advanced Security Option for Security and Single Sign-On (ASO) is the new name for the product released earlier under the name: Secure Network Services. This release of ASO Alpha OpenVMS supports the following features:
This section summarizes all the requirements necessary before installing ASO Alpha OpenVMS.
This section summarizes the hardware and software requirements for installing ASO Alpha OpenVMS.
For complete information on hardware and software requirements for Oracle9i, see the Oracle9i for Alpha OpenVMS Installation Guide.
See Chapter 1 of the Oracle9i for Alpha OpenVMS Installation Guide.
OpenVMS Version 7.2 (minimum)
The table below specifies the software requirements for ASO:
The table below specifies the software requirements for Authentication Adapters:
This section describes the steps necessary to install ASO Alpha OpenVMS.
The topics covered in this section are:
For more information about installing Oracle products using the Installer, see also the Oracle9i for Alpha OpenVMS Installation Guide.
Any reference to ASO in the following pages signifies one or more of the following options while choosing to build NETCONFIG using the Oracle Installer:
When you install ASO, the Installer automatically relinks all Oracle products.
If you do not wish to relink these executables, do not choose the options to install ASO.
$ORACLEINS
Username: ORACLE9 Password: <password>
The following build option screen is displayed:
NETCONFIG.DEF Configuration Options Option Current Value 1. System or Group Installation? [S/G] S 2. Install TCP/IP adapter? [Y/N] Y 3. Build Oracle Names Server? [Y/N] N 4. Install ASO encryption? [Y/N] N 5. Install Kerberos5 Authentication Adapter? [Y/N] N Enter (A)LL to select all options. Enter (E)XIT to exit this menu with selected options. Enter (Q)UIT to quit this menu with no action. Enter the number of the option that you want to change:
Options 4 and 5 are related to ASO.
If you are using OUI, SSL and Oracle Wallet Manager are installed with a Typical Server Installation. These and other security/encryption options may be specifically selected or excluded for installation by using the Custom Install option.
The Oracle Names executables are automatically relinked during the ASO build. To use ASO with Oracle Names, modify the file TNS_ADMIN:NAMES.ORA by adding an entry for the SQLNET.CRYPTO_SPEED parameter. You can do this by copying the line that begins with "SQLNET.CRYPTO_SPEED=" from your TNS_ADMIN:SQLNET.ORA file into your TNS_ADMIN:NAMES.ORA file.
|
Note:: The complete line must be copied exactly or you will not be able to start the Oracle Names Server using ASO. |
In the database server's local INIT.ORA file, set the following parameters:
remote_os_authent = false os_authent_prefix = ""
The logical ORA_VAR_ACE should point to the directory where the configuration file SDCONF.REC is available. By default, this logical will point to the [NETWORK.ACE] directory under ORA_ROOT. If your configuration file is located somewhere else, modify the logical definition in ORA_ROOT:[NETCONFIG]SECURID_USER.COM to point to the correct directory.
Make sure that the directory is readable by all Oracle Server processes.
The following file is required on the client side:
The following files are required on the server side:
The location of all of the above files must be specified using corresponding parameters in SQLNET.ORA.
Additionally, the Oracle Net client also creates a credential cache file whose location needs to be specified in SQLNET.ORA on the client side.
The following is an example of the parameters in SQLNET.ORA for an installation that can act as both client and server:
SQLNET.AUTHENTICATION_KERBEROS5_SERVICE=ORACLE SQLNET.AUTHENTICATION_SERVICES = (BEQ,KERBEROS5) SQLNET.KERBEROS5_KEYTAB = DISK:[TST901.NETWORK.ETC]V5SRVTAB. SQLNET.KERBEROS5_CONF = DISK:[TST901.NETWORK.KRB5]KRB.CONF SQLNET.KERBEROS5_REALMS = DISK:[TST901.NETWORK.KRB5]KRB.REALMS SQLNET.KERBEROS5_CC_NAME = DISK:[TST901.NETWORK.CCACHE]CCFILE.DAT
This section describes the steps necessary to de-install ASO from your system.
The topics covered in this section are:
|
Warning:: The de-install script does not automatically relink any of the executables linked during ASO install. You need to use ORACLEINS to relink all of these executables. |
To prepare your system to de-install ASO, do the following:
Username: ORACLE9 Password: <password>
De-installing ASO does NOT result in automatic relinking of the executables that were linked during ASO install. You need to relink these using ORACLEINS.
$ @ORACLEINS
The following build option screen is displayed:
NETCONFIG.DEF Configuration Options Option Current Value 1. System or Group Installation? [S/G] S 2. Install TCP/IP adapter? [Y/N] Y 3. Build Oracle Names Server? [Y/N] N 4. Install ASO encryption? [Y/N] N 5. Install Kerberos5 Authentication Adapter? [Y/N] N Enter (A)LL to select all options. Enter (E)XIT to exit this menu with selected options. Enter (Q)UIT to quit this menu with no action. Enter the number of the option that you want to change:
Options 4 and 5 are related to ASO. Choose N for the options that you want to de-install.
If you are using OUI, use the Custom Install option to de-install the specific products desired.
The usage notes are categorized into the following areas:
Include the following line in your LISTENER.ORA file:
SQLNET.AUTHENTICATION_SERVICES=(NONE)
The listener should not participate in the authentication service.
It is recommended that you always include BEQ as one of the authentication services in your SQLNET.ORA file. Here is an example:
SQLNET.AUTHENTICATION_SERVICES=(BEQ,KERBEROS5)
In this way, connections within the server machine through the default bequeath adapter do not have to go through the authentication. This is especially important during database startups and shutdowns.
If you expect excessive delays in your relink to access the ACE server from your client machine, use the following syntax to connect to the database, for example:
$ SQLPLUS USERNAME/"<nnnn><pppppp>+<qqqqqq>"@DATABASE
where:
<nnnn> is the PIN number of your SecurID card.
<pppppp> and <qqqqqq> are two successive codes displayed on the card.
|
 Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|