2 Architecture and Implementation

Database Files and Log Files

One or more database files contain the data dictionary, the user data, and indexes.

The Oracle Database requires a minimum of two log files, which need not be the same size, although on BS2000/OSD, the recommended minimum is 10000 PAM blocks. Note that the size of a log file is set in BS2000 blocks and not Oracle Database blocks.

Other Oracle Database Files

The following are the additional Oracle Database files:

Oracle-Managed Files

The following is a list of the INIT.ORA parameters for oracle-managed files:

• DB_CREATE_FILE_DEST for data files, temp files and block change tracking files

• DB_CREATE_ONLINE_LOG_DEST_n for redo log files and control files

• DB_RECOVERY_FILE_DEST for backups, archive log files and flashback log files

On BS2000, these parameters are used as a prefix for file names.

Oracle tablespace names can be up to 30 characters long. If you want to be able to associate an OMF-created file name with its owning tablespace, then you must use tablespace names that are distinct in the first eight characters. Oracle allows underscores(_) in tablespace names, and any underscores(_) that are present are changed to hyphens(-) for use in the generated file name.

File names for Oracle-managed files have the following format on BS2000:

where:

• dest is the destination string (_DEST) in the OMF parameter.

• tttttttt is the encoded timestamp (which looks like a random mix of letters and numerals)

• lll is a three-digit log-group number

• tsn is up to eight characters for the tablespace name

• Tnnn is the letter "T" followed by a three-digit thread number

• Snnnnnn is the letter "S" followed by a six-digit sequence number

• Lnnn is the letter "L" followed by a three-digit incremental level

• x is the letter P, if the database has an SPFILE, or the letter T if the database does not have an SPFILE

• nnnnnnn is a seven-byte timestamp

Given the 54 character limit on BS2000 file names, the preceding file name formats impose a limit of 39 characters on DB_CREATE_ONLINE_LOG_DEST_n and DB_CREATE_FILE_DEST, 29 characters on DB_RECOVERY_FILE_DEST. In these limits the catid and userid are included, which may occupy up to 16 characters.

Bigfile Tablespaces

Oracle Database 10g release 2 on BS2000/OSD supports bigfile tablespaces. The single data file of a bigfile tablespace must reside on a BS2000 pubset with the following attributes

LARGE_VOLUMES=*ALLOWED and LARGE_FILES=*ALLOWED

Refer to the Fujitsu Siemens BS2000/OSD Manual "Files and Volumes Larger than 32 GB" for more information about handling large objects on BS2000/OSD.

Oracle Database Data Area Placement

The following ORAENV variables control explicit placement of the Oracle Database data areas:

• COM_BASE

• KNL_BASE

• PGA_BASE

• SGA_BASE

The order of the areas in the address space is not significant. The xxx_BASE variable is evaluated only during STARTUP processing.

After the database is started, users attaching to it do not need to specify the values in the ORAENV files, as they are automatically supplied with the common values during connection. This means that the settings in the user's ORAENV file are ignored. Figure 2-1 gives an example of the placement of data areas.

Figure 2-1 Placement of Data Areas in Background, Server and User Tasks

The xxx_BASE values must be compatible with the BS2000/OSD value SYSBASE (defined by BS2000/OSD generation and delimiting the user's address space).

Starting with Oracle Database 10g, user programs use a separate shared code pool for common services such as Core, Globalization Support, and Net Services. The name of this pool is Client Common Pool and its placement can be controlled by the ORAENV parameter CLN_BASE.

In general, Oracle administrators should be aware of conflicts between Oracle pool placements and other pool placements in the system.

Generating ORAENV

The INSTALL.P.DBA procedure automatically creates a copy of the ORAENV file. This file provides a default configuration for an Oracle Database. You can edit this file to adapt it to local needs. Users can also generate an ORAENV file specific to their own environment. This is described in the chapter "Getting Started" in the Oracle Database User's Guide for Fujitsu Siemens BS2000/OSD.

ORAENV VARIABLES

The Appendix B, "ORAENV Variables" contains a list of ORAENV variables that the database administrator can use. Most users will only need to set a few of these variables. Any DBA-specific variables that are placed in a user's ORAENV file are ignored.

Running ORAENV

To set environment variables, simply run a CALL-PROCEDURE command on the ORAENV file containing the environment variables for the database you want to use. The name of the ORAENV file is sid.P.ORAENV (where sid is the database system identifier). For example, to set the environment variables for database DEMO using the example ORAENV file, run the following command:

/CALL-PROCEDURE DEMO.P.ORAENV

You can also generate an ORAENV file and run the /SET-FILE-LINK command before calling any Oracle Database program:

/SET-FILE-LINK ORAENV, filename

Where filename is the name of a file having the same format as DEMO.P.ORAENV and which defines at least the ORASID environment variable.

Note the following:

• The database administrator should not modify the ORAENV file while the Oracle Database is running.

• Users may modify their ORAENV file at any time.

You can run several Oracle Databases simultaneously on your BS2000 system; even within the same Database Administrator account. A unique system identifier provides a globally unique name for the database so that a user can select a particular database by setting the ORASID environment variable. The user does this by activating the ORAENV file sid.P.ORAENV.

Whenever an Oracle Database product (for example, SQL*Plus) is started, it checks if the link name ORAENV is defined and reads the related file, storing the variable assignments for later use. If no link name ORAENV is set (or the related file cannot be read), the sid remains undefined. Oracle recommends that a link name ORAENV is always defined prior to a call to an Oracle Database program.

Installation User ID (ORAUID)

During installation the complete Oracle Database software is installed into this user ID, which should be empty. This installation user ID (referred to as ORAUID) includes:

• Executable programs (such as SQL*Plus, the background and network programs)

• Load libraries, in particular, ORALOAD.LIB, from which modules are loaded during program execution. For example, the shared KERNEL module, and the precompiler run-time modules.

• Message files

• Other data files, such as.SQL files for the DEMO tables

• The INCLUDE files, application demo files and system configuration files specifying default precompiler options for precompiler users

• Object libraries required to link-edit precompiler applications, such as PRO.LIB

• Port-specific installation utilities, such as programs, command procedures, and so on

• Default configuration files such as the default ORAENV file

A separate ORAUID is required for each separate Oracle Database release. However, multiple databases using the same version can, and should, refer to the same installation user ID.

DBA User ID

The DBA user ID is a BS2000 user ID that is used as the owner of one or more of the Oracle databases. All the files for a specific Oracle database are owned by this user ID.

All tasks making up the running database, background tasks, and server tasks started for two-task Oracle Database, execute under the DBA user ID. These tasks refer to the executable programs and libraries, which are available under the installation user ID (ORAUID). These programs and libraries need not, and should not be copied into the DBA user ID. It is possible to use the installation user ID (ORAUID) as a DBA user ID. However, it is recommended that you use separate user IDs. The DBA user ID can also be used as a normal user ID.

Multiple databases can be created under the same, or under different DBA user IDs. If installed under different BS2000 user IDs, then the databases are separated and protected from each other, subject to the BS2000 protection mechanisms. In particular, a Database Administrator cannot administer a database running under a different BS2000 user ID (there is no global DBA privilege in Oracle Database for BS2000/OSD).

User IDs for Oracle users

An Oracle user accesses and uses the database through Oracle utilities, such as SQL*Plus, and through the precompiler application programs. The user can connect to an Oracle Database through the Oracle Net Services facilities.

The BS2000 user ID can also be used as Oracle Database connect user ID by means of the OPS$ generic facility.