Figure 1 - 1. Oracle7 Server architecture
The code also consists of two other images linked during installation: shared core and shared UPI. For more information about shared core and shared UPI, refer to the Oracle7 for OpenVMS Installation Guide for your platform.
Code for the Oracle7 server is built to use 64-bit pointers to support very large SGAs. The code for clients, however, is built to use 32-bit pointers to maintain compatibility with existing client code. There are, therefore, both 32-bit and 64-bit versions of the object and shareable libraries installed. Oracle only supports 32-bit clients. Client applications may not be built with 64-bit pointers.
Occasionally, you will need to relink the shareable image, such as when new code is distributed or when a new version of OpenVMS is installed. You might occasionally need to relink the executable images that access the shareable image.
Because many instances can exist on one system or in one OpenVMS Cluster, you must assign every instance a unique one-to-six character system ID (SID). During the installation procedure, you create an instance when you create the initial database. The SID that you assign to this instance becomes the default value of ORA_SID. The SID must be assigned to the logical name ORA_SID before the instance starts.
The size of the SGA is based on the values of the variable INIT.ORA parameters. These parameters determine:
Oracle7 Version 7.3.3 includes support for the Very Large Memory (VLM) 64-bit feature. This allows a large SGA that is limited only by the amount of physical memory available.
By default the SGA is not pageable. Once the SGA is created, the system cannot reclaim any of the memory that the SGA uses.
Additional Information: Refer to the Oracle7 for OpenVMS Installation Guide for your platform for information about making the SGA pageable.
Data retrieved or inserted by user transactions is temporarily buffered in the SGA. Because this data resides in an area of memory accessible to all ORACLE processes, disk I/O is reduced and transaction time is significantly improved. The most significant structures in the SGA are the shared pool, database buffer pool, and redo log buffer.
During the installation procedure, you create one database file, typically in the ORA_ROOT:[DB_<dbname>] directory, where <dbname> is the name you assign to the database. You can specify any directory for the first data file, and this directory does not necessarily need to be under ORA_ROOT. This initial file contains the data dictionary tables and all data entered by Oracle users (until you expand your database by creating tablespaces and adding data files).
Oracle Corporation recommends that the cluster size on the disk drive that will contain the database files be an integer multiple of the Oracle7 Server block size. For example, if the blocks are 2 Kb, then the cluster size should be 4Kb, 8Kb, 12Kb, etc. Keep in mind, though, that cluster sizes are specified in terms of disk blocks (where one block = 512 bytes). Thus, a 4Kb cluster is an 8-block cluster.
A disk cluster size is the minimum unit of disk allocation. You determine the size when you initialize a disk.
Modified data is written from the database buffers to the database files when the current redo log fills or when the number of blocks in the redo log equals the value set by the INIT.ORA parameters LOG_CHECKPOINT_INTERVAL. Any event that causes the database buffers to be written is known as a checkpoint. The default value of the LOG_CHECKPOINT_INTERVAL parameter is 10,000 OpenVMS blocks.
Caution: If you are using NOARCHIVELOG mode when a media failure occurs, you cannot perform media recovery. You must use ARCHIVELOG mode in order to recover from media failure.
When a redo log file fills, the DBA must back up the log file to an offline file before the redo log file can be reused. (If it is not archived by the time all other redo log files are filled, then ORACLE operations are suspended until archiving is completed.) The DBA can back up the redo logs either manually or automatically.
In NOARCHIVELOG mode, data in the log file is overwritten when a redo log file must be reused. However, data is never overwritten until data in the database buffer has been written to the database file. Using the redo log files in NOARCHIVELOG mode ensures data recovery for software and system failure only.
The redo log files must be at least 50Kb (100 OpenVMS blocks). During the Oracle Server installation procedure, you will create two redo log files named ORA_LOG1.RDO and ORA_LOG2.RDO. By default, these go into the ORA_DB directory, but you can choose an alternate directory. These log files are used in NOARCHIVELOG mode by default. You can change the mode to ARCHIVELOG. These files are also 500 Kb each by default; you can alter this size and specify different file names during the installation procedure if you want.
For more information, refer to the Oracle7 Server Administrator's Guide and to Chapter 6 and Chapter 7 in this guide.
Control files store logical filenames as their translated equivalents, but do not translate concealed logical names. Never use process-level concealed logical names to name any ORACLE database, redo log, or control file. You can rename these files by using the ALTER DATABASE and ALTER TABLESPACE commands.
Note: Be careful if you plan to rename the files. Be sure you have sufficient knowledge of the ALTER DATABASE and ALTER TABLESPACE commands as discussed in the Oracle7 Server Administrator's Guide.
| Oracle + Option | Exclusive Mode | Shared Mode | |
| Single Node | Multiple Nodes | ||
| OPS not installed | Yes: default | No | No |
| OPS installed | Yes: default | Yes: Single Shared | Yes: Multiple Shared |
| Table 1-1 Running in Exclusive or Shared Mode | |||
In shared mode, one or more instances of a parallel server mount the same database. All instances mount the database in shared mode and read from and write to the same datafiles. Single shared mode describes an Oracle Parallel Server configuration in which only one instance is running. Global operations exist, but are not needed at the moment. The instance operates as though it is in a cluster (with Distributed Lock Manager overhead, and so on), although there is no contention for resources. Multiple shared mode describes an Oracle Parallel Server configuration with multiple instances running.
Note: "Shared" mode is also known as "parallel" mode. There is no difference between the options PARALLEL and SHARED in either the ALTER DATABASE statement or the STARTUP command.
Figure 1 - 2 illustrates a typical configuration of Oracle running in shared mode with three instances on separate nodes accessing the database.
Figure 1 - 2. Shared Mode Sharing Disks
When you directly access a database with a single instance, you are running in exclusive mode. When you directly access a database with two or more instances, you are running in parallel mode. The Parallel Server technology enables you to run in parallel mode.
Note: A database created on a VAX cannot be opened on an Alpha and vice-versa. Furthermore, a parallel server configuration can consist of any number of instances so long as they are on the same type of node (either all Alpha or all VAX).
The challenge in implementing a DBMS to fully utilize an OpenVMS Cluster configuration is the use of buffer caches by the DBMS. Each node on an OpenVMS Cluster configuration has its own memory, which is not shared with any other node. The difficulty with implementing a DBMS that fully uses OpenVMS Cluster technology is efficiently coordinating buffer caches between nodes on an OpenVMS Cluster without sacrificing functionality or performance. The Oracle7 Parallel Server technology achieves efficient buffer cache coordination using parallel cache management.
The Oracle7 Parallel Server technology coordinates multiple buffer caches by using the OpenVMS Distributed Lock Manager to keep track of the state and location of the data in each cache. If one instance needs to modify data that has been modified in another instance's buffer cache, the Lock Manager causes the second instance to write the data to disk so that the first instance can access it.
The Oracle7 Parallel Server technology uses its own internal mechanisms for concurrence control (for example, to lock database objects such as rows and tables). The OpenVMS Distributed Lock Manager is used only for communication and cache coordination between instances. The Oracle Parallel Server technology reads only data blocks from disk that are not already in the buffer cache of the instance that needs the data. Modified data blocks are written to disk only when they are needed by another instance, when the buffer cache space they occupy is needed by more recently requested data, or for periodic checkpoints. When a transaction commits, at most one I/O to the redo log file is needed to ensure data integrity. Thus, fast commits, group commits, and deferred writes are fully supported in the Oracle7 Parallel Server technology.
CI-based The CI bus bandwidth is 70 megabits per second. A CI-based OpenVMS Cluster is the recommended OpenVMS Cluster type when using the Oracle7 Parallel Server technology.
Dual Host (DSSI-based) The data I/O bus bandwidth is 16 megabits per second maximum. Because Ethernet latency affects Distributed Lock Manager operations latency (Lock Manager messages are sent through Ethernet rather than through the DSSI bus), response time can slow. If Ethernet latency does not have a huge impact on response time, this configuration will perform adequately.
NI Cluster or LAVC Several different NI cluster or LAVC configurations are possible. Since all possible arrangements cannot be covered, the following paragraphs outline what to look for in an evaluation of an NI cluster environment.
If network bandwidth is too low, Ethernet traffic can result in a bottleneck when large amounts of data are transported. Because Ethernet latency affects Lock Manager operations latency, response time may also slow.
Depending on the type of application, block pinging (lock manager messages between Oracle instances requesting that one instance free or release data blocks needed by another instance) can reduce transaction throughput dramatically.
Mixed Interconnect The bandwidth varies depending on your configuration. This OpenVMS Cluster type is a combination of any other type of OpenVMS Cluster. All comments made previously also pertain to this OpenVMS Cluster type. The ORACLE instances should run on nodes connected to the CI-based OpenVMS Cluster configuration. Ethernet-based nodes should run the client side of the application.
Memory Channels Memory channel clusters are a very new technology providing an extremely fast cluster interconnect.
Cluster Comparison The following table shows a matrix of the four base OpenVMS Cluster types and their suitability regarding data I/O and DLM lock traffic.
| NI/LAVC | Dual Host | CI Cluster | Memory Channels | |
| DLM Locks | OK | OK | Better | Best |
| Data I/O | Worst | OK | Better | N/A |
| Table 1-2 Data I/O and DLM Lock Traffic Suitability for OpenVMS Cluster Types | ||||