Release 2 (9.2.0.2) for hp OpenVMS Alpha
Part Number B10506-01
 Contents |
 Index |
| Oracle9i Administrator's Reference Release 2 (9.2.0.2) for hp OpenVMS Alpha Part Number B10506-01 |
|
This chapter provides general conceptual information about Oracle Net in the HP OpenVMS Alpha environment.
It contains the 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 a centralized configuration, the Oracle9i 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 Oracle Shared Servers, you must configure Oracle Net even in centralized configurations.
In a Client-Server configuration, the Oracle9i 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, 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 OpenVMS, you can choose to install the Oracle Net TCP/IP adapter.
In addition, the OpenVMS Mailbox protocol adapter is installed automatically, as is the bequeath adapter, which allows mailbox connections without a network configuration.
Refer to the Oracle9i Installation Guide Release 2 (9.2.0.2) for hp OpenVMS Alpha for instructions on installing Oracle Net. Also refer to 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 HP OpenVMS Alpha Release 2 (9.2.0.2).
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.
The OpenVMS computer holds the physical Oracle9i database and a client workstation, as well as an Oracle Forms application that needs to access the Oracle9i database. The HP OpenVMS Alpha computer is the server and the workstation 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 Server side, the interface unbundles the messages received from TNS and passes them to the Oracle9i 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.
The relationship between TNS (the network NT layer), TCP/IP (the network NT layer - in this case, /NTT adapter), and the OpenVMS TCP/IP layer, is as follows: the 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, refer to the following manuals:
This section gives information about the following protocol adapters on HP OpenVMS Alpha:
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 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:
PROTOCOL is 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, and
KEY is the logical name used to connect to the listener via the Mailbox adapter.
This example shows the two fields for the HP OpenVMS Alpha 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 (refer to the Oracle9i Installation Guide Release 2 (9.2.0.2) for hp OpenVMS Alpha for more information).
Oracle Net on OpenVMS is developed and certified using Hewlett-Packard'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.1 ECO 4 TCP/IP Services for HP OpenVMS Alpha 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 HP OpenVMS Alpha will 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)
Following the syntax above:
PROTOCOL is the 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, and
HOST is the host name or IP address, and
PORT# is the 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 protocol 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.
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:[<home.ORADATA.<db_name>] - PROD PRODDB
On OpenVMS, the Bequeath Listener is used as a default to provide dedicated server connections for a local client. 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.
This section details the things you can do to resolve problems with Bequeath Listener.
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, perform the following tasks:
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. However, you do need to start it through x, where x is the value of that logical.
The Bequeath Listener must have the OpenVMS privileges listed in Table 9-1 to be able to perform the associated functions listed in the table.
|
Note: Before attempting to start the Bequeath Listener or the TNS Listener, the process that starts the Bequeath Listener must have the privileges in Table 9-1 or be able to have them set. Refer to"TNS Listener Privileges" for more information about setting TNS Listener privileges. |
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 Oracle Shared 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 Servers. The Oracle Shared Server parameters are not the same as in Oracle8i. 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 TNS Listener and its configuration can be found in the generic Oracle Net documentation. This section provides only information about the TNS Listener that is specific to HP OpenVMS Alpha. The sections are as follows:
The LSNRCTL utility is used to start and stop the TNS 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_ROOT:[BIN]LSNRCTL.EXE.
The main function of the command procedure is to check that the privileges required to start the TNS Listener are present (as detailed in the next section "TNS 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 TNS Listener runs must have the OpenVMS privileges listed in Table 9-1 to be able to perform the associated function.
|
Note: Before attempting to start the TNS Listener, the process that starts the Listener must have the privileges in Table 9-1 or be able to have them set. As noted above, the LSNRCTL command file will attempt to set these privileges and warn the user if it was unable to do so. |
Process quotas for the TNS Listener and for the Server processes which the TNS 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, BIOLM, BYTLM, CPULM, DIOLM, ENQLM, FILLM, JTQUOTA, PGFLQUOTA, PRCLM, TQELM, WSQUOTA, WSDEFAULT or WSEXTENT.
Several of the logical names are defined in LSNRCTL.COM and control the quotas of the TNS Listener process. They are defined in user mode so that they are not present after exiting LSNRCTL. If your TNS 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 TNS Listener creates, specify the logical names in the file ORA_NETWORK:TNSLSNR.COM, the command file that runs in the TNS 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.
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 TNS 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.
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) ) )
When the TNS 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 TNS Listener need not contain the above-mentioned SID_LIST_<listener> section. The Oracle Shared Server dispatchers registers with the TNS 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).
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 TNS 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 OpenVMS. It covers the following topics:
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 (refer to the section "Names Server Privileges" for more information). 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 OpenVMS privileges in Table 9-2 to be able to perform the associated function.
|
Note: Before attempting to start the Names Server, the process that starts the Names Server must have the privileges in Table 9-2 or be able to have them set. As noted above, the NAMESCTL command file will attempt to set these privileges and warn the user if it was unable to do so. |
The Oracle Intelligent 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 on HP OpenVMS Alpha. Read this section carefully and completely before beginning to install and use the Oracle Intelligent Agent on HP OpenVMS Alpha.
This section covers the following topics:
The Oracle Intelligent Agent requires that a supported TCP/IP implementation be installed on your OpenVMS system. In addition, you must enable TCP/IP support for Oracle Net in the NetConfig configuration screen.
For more information, refer to "TNS Listener" in this chapter.
The Oracle Intelligent Agent may be installed at the same time as other products or it may be installed later.
Installation of the Oracle Intelligent 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 Oracle Intelligent Agent files will reside.
If you are using the same Oracle Installation from more than one node in an OpenVMS cluster, you can only run the Oracle Intelligent Agent from this installation on one of the nodes. If you attempt to run the Oracle Intelligent 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 Oracle Intelligent Agent, you must perform a client-only installation for the Oracle Intelligent Agent (installing AGENT, NETCONFIG, and UTIL) and run the Oracle Intelligent Agent from this client-only installation.
To correctly set up the Oracle Intelligent Agent environment, the following two kinds of files need to be created:
Once the Oracle Intelligent Agent has been successfully installed, create the following two files:
To create this file, modify AGENT_START_COM.SAMPLE to replace the definition of symbol ORA_ROOT with the correct path for your installation and save it appropriately as a .COM file. When you startup the Oracle Intelligent Agent, AGENT_START.COM is run as a Detached Process.
At startup, and when requested by the OEM console thereafter, the Oracle Intelligent Agent runs a tcl script called NMICONF.TCL, which resides in the ORA_ROOT:[NETWORK.AGENT.CONFIG] directory. This script starts by reading LISTENER.ORA and TNSNAMES.ORA 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 Oracle Intelligent 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 TNS Listener that matches our SID becomes the listener active for that database.
The configuration files SNMP_RO.ORA and SNMP_RW.ORA are created and should reside at TNS_ADMIN, the same location as the TNS config files.
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 Oracle Intelligent 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 Oracle Intelligent Agent is running and issue the following command, to verify that the account is not disabled and that it has the ORA_AGENT_ID identifier:
$ show process/right
This section explains how to startup, shutdown, and status query the Oracle Intelligent Agent.
The Oracle Intelligent 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 Oracle Intelligent Agent:
$ AGENTCTL startup
This command creates a detached process with a process name of ORA_AGENTWORK.
If a nonzero trace level is specified, then the Oracle Intelligent Agent creates a trace file with the name DBSMP_<pid>.TRC in the ORA_ROOT:[NETWORK.TRACE] directory.
Use the following command to shut down the Oracle Intelligent Agent:
$ AGENTCTL STOP
Use the following command to verify whether the Oracle Intelligent Agent is running:
$ AGENTCTL STATUS
Unlike the TNS Listener process, the Oracle Intelligent 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.
This section provides OpenVMS-specific installation information for the current release of Advanced Security Option (ASO) for Security and Single Sign-On.
This section covers the following topics:
In the database server's local INIT.ORA file, set the following parameters:
remote_os_authent = false os_authent_prefix = ""
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
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.
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|
