Release 3 (8.1.7) for Alpha OpenVMS
Part Number A86712-01
 Library |
 Contents |
 Index |
| Oracle8i Server and Tools Administrator's Guide Release 3 (8.1.7) for Alpha OpenVMS Part Number A86712-01 |
|
This chapter introduces the Oracle8i products in the Alpha OpenVMS environment. It consists of the following sections:
Oracle8i Alpha OpenVMS Release 3 (8.1.7) provides the following new features:
DBJAVA allows Java programs to access the Oracle8i database.
Oracle Parallel Server mode is now supported with the Oracle8i Enterprise Edition Release 3 (8.1.7) for Alpha OpenVMS 7.2 or higher.
Parallel Server mode can be used on any cluster node, and can take advantage of any cluster communications media, including Memory Channel, FDDI, and Galaxy Shared Memory.
Oracle Parallel Server mode uses the Oracle Group Membership Services facility. Please see the Oracle8 Parallel Server Concepts and Administration guide, version 8.1.6 or later, for more information on Oracle GMS.
Please refer to the READMEVMSOPS.DOC in the ORA_RDBMS directory for more information about Oracle Parallel Server.
The JServer is an integrated Java Virtual Machine within the Database Server process that allows execution of Java code within the server. It supports loading of Java stored procedures into the database, and allows calls between Java and plsql in either direction.
SQLJ provides embedded-SQL extension to the Java language.
Figure 1-1 shows an overview of the Oracle8i Enterprise Edition architecture.
Oracle8i code consists of several object libraries that are used to form the Oracle8i image during installation; you must link this image with the C runtime libraries provided by Compaq, to produce the executable Oracle8i code.
The code also consists of a shared Oracle client image linked during installation. For more information about shared Oracle client image, refer to the Oracle8i for Alpha OpenVMS Installation Guide.
Code for the Oracle8i Enterprise Edition 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.
When the Oracle8i Enterprise Edition is linked and installed, these routines reside as shareable code in Alpha OpenVMS global memory.
Occasionally, you will need to relink the image, such as when new code is distributed or when a new release of Alpha OpenVMS is installed.
An Oracle8i instance is a combination of Oracle Server processes and memory buffers, as shown in Figure 1-1 .
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.
All ORACLE operations use data stored in an area of shared memory called the System Global Area, commonly known as the SGA, that is allocated to each ORACLE instance. The size of the SGA is determined by the INIT.ORA file start-up parameters. After you create an instance, you can change the size of its SGA by shutting down the instance with the Server Manager utility and modifying the values set in the INIT.ORA file as needed.
The size of the SGA is based on the values of the variable INIT.ORA parameters. These parameters determine:
Consequently, parameter settings also determine the memory space needed to support these requirements. Increasing the value of these parameters can improve performance, but performance might also decrease if the SGA is so large that it consumes enough of the system memory that the system is forced to page portions of processes in and out of memory.
Oracle8i Release 2 (8.1.7) 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.
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.
The shared pool contains shared cursors, stored procedures, SQL, PL/SQL blocks, and trigger code. The size of the shared pool is specified by the initialization parameter SHARED_POOL_SIZE. Larger values of this parameter improve performance in multi-user systems. Smaller values use less memory. The limit for this parameter is determined by the size of your SGA. The shared pool must be at least 3.6 MB.
Blocks of data retrieved by user transactions are read from the database file and then cached in the database buffer pool in the SGA. This data remains in the buffer pool (even after changes are committed) until more buffers are required; then, if the data has been modified, it is written to the database file.
The number of blocks that can be maintained in the buffer pool is determined by the initialization parameter DB_BLOCK_BUFFERS. For more information, see the Oracle8i Server Administrator's Guide.
When data is modified, a record of the change (known as a redo entry) is generated in the redo log buffer. When changes to the data are committed, the redo entries in the buffer are written to the current redo log file. Redo log files provide for data recovery if media or system failure occurs before modified data is written from the database buffer to the database file.
The number of bytes that can be maintained in the redo log buffer is determined by the initialization parameter LOG_BUFFER. For more information, see the Oracle8i Server Administrator's Guide.
Data is stored in database files. Each database must have at least one database file. Whenever you create a database, an initial database file is also created for the database.
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 Oracle8i Enterprise Edition block size. For example, if the blocks are 2 KB, then the cluster size should be 4 KB, 8 KB, 12 KB, etc. Keep in mind, though, that cluster sizes are specified in terms of disk blocks (where one block = 512 bytes). Thus, a 4 KB 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.
Changes made to the database are logged in the shared database buffers and in a file called a redo log. The changes recorded in the redo log provide for data recovery if media, software, or system failure occurs before the database buffers are written to the database files. Every database must have at least two redo log files so that another redo log will be available when the current log is filled.
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.
You can specify one of two modes for writing redo log files: ARCHIVELOG and NOARCHIVELOG. Using the redo logs in ARCHIVELOG mode allows data recovery in the event of media, software, and system 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 2000 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 Oracle8i Server Administrator's Guide and to Chapter 6 and Chapter 7 in this guide.
You can use logical names to specify the names of the database, redo log, and control files. Oracle Corporation recommends that you use system or group level logical names (based on whether you used system or group installation) to name the devices where the database and redo log files reside, and that you specify full directory and filename paths for these files. You may fully specify the control file names with logical names, as with the ORA_CONTROL1 and ORA_CONTROL2 logical names.
Control files store logical filenames as their translated equivalents, but do not translate concealed logical names.
You can rename these files by using the ALTER DATABASE and ALTER TABLESPACE commands.
Oracle datafiles may be placed in any location on any disk subject to the following restrictions:
You can identify your datafiles by logical names rather than fully qualified filenames in your CREATE DATABASE or ALTER TABLESPACE statements. However, these logical names must be defined at the GROUP level or above, preferably at the SYSTEM level. Logical names at the PROCESS or JOB level CANNOT be used to identify datafiles. If you identify your datafiles by logical names, make sure these logical names are defined during system startup before you restart your databases after a reboot.
|
 Copyright © 2000 Oracle Corporation. All Rights Reserved. |
|