Lewis Carroll, Alice's Adventures in Wonderland
This chapter describes the steps you must perform before installing your Oracle products. The following topics are presented:
Note: A separate license is required to use ANO.
In addition to the SecurID and Kerberos5 authentication adapters that were previously supported by ANO, the Identix (Biometric) authentication adapter is now also supported.
Additional Information: Refer to Chapter 7 in SQL*Net for OpenVMS Configuration and User's Guide, Version 2.3.3 (part number: A55207)
Additional Information: Refer to Chapter 3 in SQL*Net for OpenVMS Configuration and User's Guide, Version 2.3.3 (part number: A55207)
The enhancements are the following:
By installing ConText Option with an Oracle server, client tools such as SQL*Plus, Oracle Forms, and Pro*C are able to retrieve and manipulate text in an Oracle database. Most tools that can call an Oracle stored procedure can perform text queries and other text operations.
ConText Option manages textual data in conjunction with traditional datatypes in an Oracle database. When text is inserted, updated, or deleted, ConText Option automatically manages the change.
Additional Information: See Chapters 3 and 4 and Appendix A
Additional Information: Refer to documentation for ConText Option 2.0.4 for Oracle7 Version 7.3.3
Additional Information: Refer to Chapter 6 in SQL*Net for OpenVMS Configuration and User's Guide, Version 2.3.3 (part number: A55207)
Note: Oracle software is not interchangeable between VAX OpenVMS and Alpha OpenVMS. In addition, note that object files, object libraries, and executables are larger on Alpha OpenVMS than they are on VAX OpenVMS.
| Oracle7 Product | Hardware Required |
| Oracle Server Manager (GUI interface) | Bitmapped display running Motif |
| National Language Support (NLS) | Native language fonts and keyboard |
Note: 1 OpenVMS disk block = 512 bytes.
The image names are in the form of: UPISHR<imageid>.EXE, UPISHR<imageid>_64.EXE, SQLLIBSHR<imageid>.EXE, CORE<imageid>.EXE, CORE<imageid>_64.EXE, ORACLE<imageid>.EXE, ORACLE<imageid>_64.EXE, and SRV2.EXE, where <imageid> is the same as the identifier appended to the end of the Oracle shared image.
When the image names are installed, they have the logical names: UPISHR<imageid>, UPISHR<imageid>_64, SQLLIBSHR<imageid>, CORE<imageid>, CORE<imageid>_64, ORACLE<imageid>, ORACLE<imageid>_64, and SRV2, where <imageid> is the same as the identifier appended to the end of the Oracle shared image.
The command procedure INSORACLE.COM installs these images along with the shared RDBMS image; REMORACLE.COM removes them.
| Protocol Service | Earliest Supported Version | Latest Certified Version |
| DECnet Phase IV | same version as your OS | same version as your OS |
| DECnet-Plus | 7.1 | 7.1 |
| DEC TCP/IP Services (formerly UCX) | 4.0 | 4.0 |
| TGV MultiNet TCP/IP | 4.0 | 4.0 |
| TCPware for OpenVMS | 5.1 | 5.1 |
Note: Pathway 3.0 from Attachmate is supported with SQL*Net 2.3.3.
$ SET HOST <nodename>
where <nodename> is the name of the host system to which you are trying to connect. Log on by providing a valid username and password. If this command works, DECnet is working.
Additional Information: For more information, see the DECnet for OpenVMS Guide to Networking. If you are unable to initiate a remote session, contact your system administrator to ensure that the remote node is defined and that the network is functioning properly.
TELNET connects to the target system, and PING tests the remote host to see if it is responding. The following syntax is used for the commands where <host_name> is the server (defined in the HOSTS file) whose connection you want to test.
$ TELNET <host_name>
$ PING <host_name>
For example, if you enter the following line from an OpenVMS server, you should receive a "Username" prompt for logging onto the host HQVMS.
$ TELNET HQVMS
If you receive this prompt, the hardware and software are working. Use [CTRL-Z] to cancel the logon procedure and return to the DCL prompt. If you receive an error message, consult your vendor documentation or your vendor customer support service.
If you enter the following line, you should receive the message "HQVMS is alive," usually within 20 seconds.
$ PING HQVMS
Note: TCP/IP can be installed without TELNET support. If TELNET does not work, consult your system administrator. TELNET does not need to be installed for Oracle products to work. Some TCP/IP vendors may not supply a PING command directly. For instance, if you are using Digital TCP/IP Services for OpenVMS, you would first have to define PING as:
$ PING :== UCX PING
before giving the $ PING HQVMS command previously specified.
| Programmatic Interfaces | Certification Version |
| Pro*Ada | DEC Ada V3.0 |
| Pro*C and SQL*Module for C | DEC C Version 5.5 DEC C++ Version 5.3 |
| Pro*Cobol | DEC COBOL V2.0 |
| Pro*Fortran | DEC Fortran V6.1 |
| Pro*Pascal | DEC Pascal V5.1 |
| Pro*PLI | DEC PL/I V4.0 |
| If you want to install | then you need to install |
| Any Oracle product | UTIL and NETCONFIG |
| Server Manager | UTIL and NETCONFIG Motif 1.2-4 to use the GUI Version |
| Oracle7 Server | UTIL, NETCONFIG, and Server Manager |
Note: To install NLS, build all Oracle products first. Then install NLS. The product directories must exist before NLS message files can be copied into them.
Review the compatibility issues given in this section:
Change the following logical names by appending the /JOB qualifier to the appropriate DEFINE commands in the following command procedures:
In ORA_DB_<dbname>.COM:
ORA_DB
ORA_CONTROL1
ORA_CONTROL2
ORA_PARAMS
ORA_INITSQL
ORA_ARCHIVE
In ORAUSER_<dbname>.COM:
ORA_SID (two occurrences)
ORA_INSTANCE
ORA_DUMP
SQL*Net Version 2.3 provides the following adapters:
| Client/Server | Distributed DBMS | |||
| Client Tool | RDBMS Server | Client | Server | |
| SQL*Net DECnet | Yes | Yes | Yes | Yes |
| SQL*Net TCP/IP | Yes | Yes | Yes | Yes |
| SQL*Net OpenVMS Mailbox | Limited* | Limited* | Limited* | Limited* |
Setting up an Oracle7 account is the same as setting up any other OpenVMS user account. The following are the steps to set up an Oracle7 account:
Additional Information: See Digital's VMS Authorize Utility Manual for more information about running the AUTHORIZE utility.
The Oracle7 account will own the runtime libraries and executable images for every Oracle product. Therefore, the database administrator (DBA) should manage this account and install all Oracle products from it.
$ WRITE SYS$OUTPUT F$GETSYI("MAXSYSGROUP")
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF> ADD ORACLE7 /PASSWORD=ORACLE/UIC=[277,100]-
/DEVICE=<device>/DIRECTORY=[ORACLE7]/OWNER="ORACLE DBA"
In this example, the account name is ORACLE7. Note that the UIC GROUP number is 277. The UIC GROUP number must be larger than MAXSYSGROUP.
After adding the account, you must alter the account privileges and quotas. Although this can be done in any order, usually the account privileges are set before the account quotas.
Use the AUTHORIZE utility to set the account privileges for the Oracle7 database administrator's account.
At the UAF prompt, use the MODIFY command to add the required default and authorized privileges as follows:
UAF> MODIFY ORACLE7 -
/PRIVILEGE=(CMKRNL,NETMBX,PFNMAP,PRMGBL,PRMMBX,SYSGBL, -
SYSNAM,TMPMBX,IMPERSONATE,DETACH,LOG_IO,WORLD,SYSLCK) -
/DEFPRIVILEGE=(CMKRNL,NETMBX,PFNMAP,PRMGBL,PRMMBX,SYSGBL -
SYSNAM,TMPMBX,IMPERSONATE,DETACH,LOG_IO,WORLD,SYSLCK)
UAF> MODIFY ORACLE7/ENQLM=150
Note: These quotas depend on the number of logfiles, the number of databases, the number of network connections, and other variables on your system. You might need to customize them.
| Account Quotas | Minimum Value | Quota Name |
| ASTLM | 250 (the default) | Asynchronous System Trap limit |
| BYTLM | 150,000 | Buffered I/O limit |
| ENQLM | 2000 (the default) | Enqueue quota |
| FILLM | 100 | Open file quota |
| JTQUOTA | 8192 | Job table quota |
| MAXDETACH | 0 (the default) | Max detached processes |
| MAXJOBS | 0 (the default) | Max active jobs |
| PGFLQUO | 250,000 | Paging file quota |
| WSEXTENT | 8192 | Working set extent |
| WSDEFAULT | 2048 | Working set limit |
| WSQUOTA | 4096 | Working set quota |
| Adding... | and Granting... | Allows Control of... |
| ORA_DBA | ORA_DBA | Any database instance (provided it does not also have an ORA_<sid>_DBA identifier defined for it) |
| ORA_<sid>_DBA | ORA_<sid>_DBA | Database instance <sid> only |
| ORA_<sid>_DBA | ORA_DBA | All database instances except <sid> |
UAF> ADD/IDENTIFIER ORA_TEST_DBA
Then grant the rights identifier to the Oracle7 account as follows:
UAF> GRANT/IDENTIFIER ORA_TEST_DBA ORACLE7
If you add the ORA_TEST_DBA rights identifier, but grant only ORA_DBA to ORACLE7, the account would have insufficient privileges to administer the instance TEST.
The third line of the table shows that you can add and grant different identifiers, thereby restricting control of a particular instance while still granting control to other instances.
You can grant database maintenance privileges (for example, privileges to start up and shut down the database) to accounts in addition to the Oracle7 account. (However, as with the Oracle7 account, the user's UIC GROUP number must be greater than MAXSYSGROUP.) By granting the ORA_<sid>_DBA identifier, you can similarly restrict a user's privileges to an instance named <sid>.
Before bringing up a database later than 7.3.2.3.0, add a rights identifier to the User Authorization File (UAF). Have your system manager follow these directions.
At the UAF> prompt, type:
UAF > ADD/IDENTIFIER ORA_SGA
Warning: DO NOT GRANT THE RIGHTS IDENTIFIER TO ANY USER. Oracle takes care of assigning it when it starts the database.
UAF > ADD/IDENTIFIER ORA_AGENT_ID
All users that will submit jobs to the Intelligent Agent must have ORA_AGENT_ID. Use the following:
UAF > GRANT/IDENTIFIER ORA_AGENT_ID <user name>
For security reasons, Oracle Corporation recommends that the OpenVMS system administrator handle these tasks. This person should be responsible for starting Oracle7 instances from a controlled account with a UIC group greater than MAXSYSGROUP. If this is not possible, at least one Oracle7 database administrator must have the CMKRNL privilege.
If the user account that you modified was logged on at the time, this user must log out and log back in before the changes take effect.
$ SHOW PROCESS/PRIVILEGE
You can display the current values of SYSGEN parameters from the DCL command line. For example, to determine the current setting of GBLPAGES, issue the following command:
$ WRITE SYS$OUTPUT F$GETSYI("GBLPAGES")
If you use Oracle7 in exclusive mode (the default), you only need to set the three parameters described in Step 2 in this section. If you use Oracle7 in parallel mode, you must also set the parameters described in the next section, "Parallel Mode Parameters".
For each installed Oracle7 shareable image, do the following:
| Required OpenVMS Parameter | Current Value |
| GBLPAGES | |
| GBLSECTIONS | |
| MAXBOBMEM | |
| Parameter | Minimum Value Needed by Oracle7 |
| MIN_GBLPAGES | <gblpages> + (22,000 * <code trees>) + (2 * <total SGA size>) |
| MIN_GBLSECTIONS | <gblsections> + (23 * <instances>) |
| MIN_MAXBOBMEM | <gblpages> + (22,000 * <code trees>) + (2 * <total SGA size>) |
| <gblpages> | Is the current value of the GBLPAGES parameter. |
| <gblsections> | Is the current value of the GBLSECTIONS parameter. |
| <instances> | Is the number of instances. |
| <code trees> | Is the number of copies of the Oracle Server installed on your system. |
| <total SGA size> | Is the total size (in kilobytes) of all SGAs of all instances on the node. |
If Oracle is unable to create the buffer object at startup, it will be unable to use OpenVMS Fast I/O. In this case, the instance will startup and the following message will appear in the Alert Log:
** Unable to create SGA Buffer Object - Fast I/O will not be used. non-fatal error = <OpenVMS error code> **
The following examples show how to calculate the number you need to add to GBLPAGES to get the value of MIN_GBLPAGES.
Example 1:
One Oracle code tree (single ORA_ROOT) supporting two single-instance databases with SGAs of 10 MB and 20 MB respectively:
(22,000 * <code trees>) + (2 * <SGA size>) =
(22,000 * 1) + [2 * (10,000 + 20,000)] = 82,000 contiguous pages
Example 2:
A development code tree supporting a single-instance default database with an SGA of 30 MB and a production code tree supporting two databases. The first production database has a single instance on this node with an 8 MB SGA. The second production database has two instances on this node, each having a 15 MB SGA:
(22,000 * <code trees>) + (2 * <SGA size>) =
(22,000 * 2) + [2 * (30,000 + 8,000 + 15,000 + 15,000)] =
44,000 + (2 * 68,000) =
180,000 contiguous pages
Additional Information:
For more information about the SGA, see the Oracle7 for OpenVMS Server and Tools Administrator's Guide.
The following sections describe how to calculate and how to estimate the SYSGEN parameters for running in parallel mode:
| <current_val> | Current value of parameter |
| <total_instances> | Number of instances in the cluster |
| <locks> | Number of locks (described below in Step 1 of "Estimating SYSGEN Parameters and Locks") |
| <n> | An integer (2 or greater) |
| SYSGEN Parameter | How to Calculate |
| LOCKIDTBL | <current_val> + ( <locks> * <total_instances> ) |
| LOCKIDTBL_ MAX | ( <n> * LOCKIDTBL ) + 1 |
| LOCKDIRWT | Depends on system type and lock manager activity. |
| NPAGEDYN | <locks> * 384 |
| NPAGEVIR | <locks> * 384 |
To do this, you must make an initial estimate of SYSGEN parameter values, start a database instance, and then check if the number of locks is sufficient. If the number is not sufficient, shut down the database and perform the procedure again with different SYSGEN parameters.
Step 1
Set your SYSGEN parameters by estimating the number of locks your system will use. The number of locks depends on certain database parameters, specifically on those that begin with GC_ (henceforth referred to as GC_*).
Note: Database parameters and SYSGEN parameters refer to different things. Database parameters are those that are found in files such as INIT.ORA and INITPS.ORA.
The GC_* parameters directly affect OpenVMS distributed lock manager use. For most systems, buffer management locks (GC_DB_LOCKS) are the largest contributor to the lock manager locks and resources that Oracle7 uses in parallel mode.
Note: Make sure that you conserve and partition locks across files. Refer to the Oracle7 Parallel Server Concepts and Administration for more information about using locks across files.
The GC_* parameters, in turn, vary depending on the size of your system. You can check the INITPS.ORA file to see suggested values for these parameters for small, medium, and large SGAs. Large GC_* values accommodate most Oracle7 systems and should not be increased.
Step 2
Using the number of locks you estimated in Step 1, determine an estimated value for the SYSGEN parameters. Refer to the previous table for formulas. You also need to supply the total number of instances that your system will be running.
Step 3
The LOCKDIRWT SYSGEN parameter affects the number of lock manager directory entries maintained by a given node. This value depends on the type of system and the amount of lock manager activity on each node in the OpenVMS Cluster environment. Refer to Digital OpenVMS documentation for appropriate values of LOCKDIRWT, and consider its impact on Oracle7 (and any other applications that use the lock manager).
Step 4
To determine the number of locks your system is using, enter the following line:
$ MONITOR LOCK
The number you want appears in the "Current value" field of the row entitled "Total locks."
To determine the number of locks used clusterwide, use the MONITOR DLOCK command. To get more information on locks, use the $GETLKI system service in your own program.
Step 5
When you are satisfied with your estimated SYSGEN parameters, start the database in parallel mode and repeat Step 4. This gives you a higher value for the number of locks. The difference between the two values tells you the approximate number of locks that Oracle7 by itself uses.
Step 6
Check whether your estimated SYSGEN parameters provide sufficient system resources to run Oracle7. That is, substitute the number of Oracle7 locks (from Step 5) back into the SYSGEN parameter formulas. If the new calculations produce much higher numbers, increase the SYSGEN parameters accordingly.
The advantages to reserving memory for an SGA are as follows:
$ MCR SYSMAN
SYSMAN> RESERVED_MEMORY ADD ORA_VLM1_SGA/SIZE=6144/ALLOCATE/ZERO/PAGE
SYSMAN> EXIT
Note: 1 GB = 1024 MB
Then run AUTOGEN and reboot the system to allow AUTOGEN to adjust other system parameters for the reduced amount of memory available to the rest of the system.
Memory for multiple SGAs may be reserved. Any change to the name or size of a piece of reserved memory may require rebooting the system. During instance startup, Oracle compares the size of the reserved memory, if any, with the size of the SGA. If appropriate, one of the following messages will be included in the Alert log:
** Reserved memory size = <size> greater than created SGA size = <size>** ** Please reduce reserved memory size to avoid wasting memory. **
** Memory was not reserved for the SGA. SGA size = <size> ** ** There might be performance advantages to allocating memory for the SGA in the VMS reserved memory registry. **
If memory is reserved for an SGA but not enough memory is reserved, the instance startup will fail. In this case, the amount of reserved memory should be adjusted, AUTOGEN should be run, and the system should be rebooted. For example, to expand the SGA to 6.5 GB for the VLM1 instance, use the following commands:
$ MCR SYSMAN
SYSMAN> RESERVED_MEMORY REMOVE ORA_VLM1_SGA
SYSMAN> RESERVED_MEMORY ADD ORA_VLM1_SGA/SIZE=6656/ALLOCATE/ZERO/PAGE
SYSMAN> EXIT
Then run AUTOGEN and reboot the system.
To avoid rebooting the system, SYSMAN can be used to free the memory reservation. Then you may start the instance. The risk is that the system may not have enough fluid pages to create the SGA. Also, the performance advantages of using reserved memory are not available.
Additional Information: See OpenVMS Alpha Guide to 64-Bit Addressing and VLM Features for more information about the reserved memory registry.
For setting or modifying SYSGEN parameters, OpenVMS provides the AUTOGEN utility. You can also use SYSGEN, but this is an older utility whose use is discouraged, except perhaps for checking current values. You must have SYSPRV or BYPASS privilege to run these utilities.
AUTOGEN provides a permanent way of setting parameters, and it documents all changes. AUTOGEN also lets you recalculate any parameters that depend on other parameters you might have changed. Remember to record parameter values before changing them, and determine beforehand what results you expect from your changes. If the expected changes do not occur, restore the old values before trying again.
$ @SYS$UPDATE:AUTOGEN GETDATA AGEN$FEEDBACK.DAT
$ @SYS$UPDATE:AUTOGEN SAVPARAMS GETDATA
MIN_GBLSECTIONS=300
MIN_GBLPAGES=30000
$ @SYS$UPDATE:AUTOGEN GENPARAMS REBOOT
Warning: The REBOOT parameter in this example will cause the system to automatically reboot when the SYSGEN is complete.
Note: You should perform a cold backup of your database and all associated datafiles before doing this migration.
If you plan to configure the 7.3.3 RDBMS to run with Spatial Data (SD), the SYSTEM tablespace will need to have a minimum of 10 MB of free space.
Note: If you plan to configure both Advanced Replication and Spatial Data, you will need a minimum of 30 MB of free space.
The default size of the SYSTEM tablespace for 7.1.5 was 10 MB, which is insufficient to support AR and/or SD. You will need to add a datafile to the SYSTEM tablespace that is large enough to accommodate the increased requirements of 7.3.3. Please refer to the Oracle7 Server Administrator's Guide for instructions on how to add datafiles to a tablespace.
You must insure that the 7.1.5 database has at least 20 MB of free working space in the SYSTEM tablespace. The tablespace changes must be made in 7.1.5 before attempting to upgrade to 7.3.3.
The following SQL query will assist you in determining if you need to add a datafile to increase the size of the SYSTEM tablespace:
SELECT tablespace_name, file_id,
COUNT (*) "PIECES",
MAX(blocks) "MAXIMUM",
MIN(blocks) "MINIMUM",
AVG(blocks) "AVERAGE,
SUM(blocks) "TOTAL"
FROM sys.dba_free_space
WHERE tablespace_name = 'SYSTEM'
GROUP BY tablespace_name, file_id;
| TABLESPACE_NAME --------------- | FILE_ID ------- | PIECES ------ | MAXIMUM ------- | MINIMUM ------- | AVERAGE ------- | TOTAL ----- | |
| SYSTEM 1 row selected. | 1 | 1 | 4891 | 4891 | 4891 | 4891 | |
Please refer to the Oracle7 Server Administrator's Guide for instructions on how to manage tablespaces.
Note: The following assumptions must be met for MIGRATE715.COM to be usable:
Please have the database name and the translation of the logical names ORA_ROOT, ORA_SID, and ORA_DB available.
The migration script, ORA_RDBMS:MIGRATE715.COM, must be run in the 7.3.3 code tree, with the 7.1.5 database shutdown. Before running this script, you must perform a complete cold backup against the database and all datafiles. Please refer to the Oracle7 Server Administrator's Guide for backup procedures.
The migration script will modify installation files in the 7.3.3 instance, and the ORA_DB directory of the database you are migrating. When this script finishes, your database will have its ORA_SID, database name, and location registered with the 7.3.3 instance. This involves updates to the following files:
ORA_RDBMS:ORA_RDBMS_SIDS.DAT
ORA_RDBMS:UPGRADE715.SQL
ORA_UTIL:DATABASE.TXT
ORA_UTIL:RDBMSDB_<ORA_SID>_<DATABASE_NAME>.FIG
The file, ORA_RDBMS:UPGRADE715.SQL, will be written while running the migration script. It will contain commands to install options selected during RDBMS configuration. If you change the RDBMS configuration, you must run appropriate SQL scripts to enable the option added. Please refer to the documentation regarding the installed option. For example, if AR was not configured at initial RDBMS build time and was added later, then you must run SVRMGR> @ORA_RDBMS:CATREP.SQL.
@ORA_DB:STARTUP_EXCLUSIVE_<DBNAME>.COM
After starting the server, you will need to complete the migration by running the ORA_RDBMS:UPGRADE715.COM. This script will execute the appropriate SQL scripts against the 7.1.5 database. When it succeeds, you will have migrated your 7.1.5 database successfully to 7.3.3.