The concepts of tasks (that is, processes in Oracle terminology) and memory structures (areas) are not BS2000 specific.
Refer to the chapter 'Memory Structures and Processes' in the Oracle Database Concepts manual for detailed information.
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.
Note:Both the BS2000/OSD operating system and the Oracle Database perform input and output efficiently in units called blocks. A block is simply the basic unit of data storage. An Oracle Database block can be in one of the following formats:
2K, 4K, 6K, 8K, 16K, 32K when using BS2000 2K pubset format
4K, 8K, 16K, 32K when using BS2000 4K pubset format
Oracle Database and redo log files are BS2000 PAM files, and Oracle Database uses UPAM to access them.
The following are the additional Oracle Database files:
The server parameter file (
SPFILE) is a binary server-side initialization file, which cannot be edited using a text editor. It is initially built from a traditional text initialization file using the
CREATE SPFILE statement.
Every Oracle Database utility and product uses the Oracle Database environment definition file, which is referenced as
ORAENV. This file contains the Oracle Database environment variables, which are used to describe the operating environment for each Oracle Database task. The database administrator also uses the
ORAENV file to define BS2000-specific parameters necessary for database configuration.
These files contain the information required by Oracle Database to identify the instance and are specified in the initialization file.
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:
|permanent tablespace files, data file copies||destOMD.tsn.tttttttt|
|temporary tablespace files||destOMT.tsn.tttttttt|
|archive log files||destOMA.Tnnn.Snnnnnn.tttttttt|
|data file or archivelog backup piece||destOMB.Lnnn.tttttttt|
|rman autobackup piece||destOMX.xnnnnnnn.tttttttt|
|block change tracking files||destOMR.tttttttt|
|flashback log files||destOMF.tttttttt|
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
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_FILE_DEST, 29 characters on
DB_RECOVERY_FILE_DEST. In these limits the
userid are included, which may occupy up to 16 characters.
See Also:"Using Oracle-Managed Files" chapter in the Oracle Database Administrator's Guide
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.
In two-task mode, a user task connects to a server task, which runs Oracle Database code on behalf of the user task. The user task does not have access to the SGA. Communication between a user task and a server task is through Oracle Net Services.
The Oracle Database uses a number of data and code areas, which must be at the same virtual addresses in all server and background tasks. Typically, the default values provided with Oracle Database are sufficient. Address space planning (explicit placement of the Oracle Database data areas) may be required in some special situations, when you encounter address space conflicts. For example, dynamic subsystems may occupy the default address ranges, which may require you to relocate the Oracle Database areas.
ORAENV variables control explicit placement of the Oracle Database data areas:
The order of the areas in the address space is not significant. The
_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.
_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
In general, Oracle administrators should be aware of conflicts between Oracle pool placements and other pool placements in the system.
ORAENV text file has the format of a BS2000 command procedure that runs the
/SET-FILE-LINK ORAENV command for itself. Each line contains an Oracle Database environment variable and its assigned value. When reading this file, the Oracle Database ignores all lines, which have a slash (/) or an asterisk (*) in column 1.
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.
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.
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 is the database system identifier). For example, to set the environment variables for database DEMO using the example
ORAENV file, run the following command:
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
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
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.
ORALOAD library (
$ORAC1020.ORALOAD.LIB by default) is required to run any Oracle Database 10g release 2 program. The Oracle Database uses this library to load executables and subroutines dynamically when required. The link name
ORALOAD must identify the
ORALOAD library before calling any Oracle Database program. If the link name is missing, you get a
BLS (BS2000/OSD loader) error message. Usually, this link name is set when the
ORAENV procedure is called.
ORAMESG library (
$ORAC1020.ORAMESG.LIB) is required for dynamically loading tables, such as message files, by an Oracle task when required. The link name
ORAMESG must identify the
ORAMESG library before calling any Oracle program. If the link name is missing, you get a
BLS (BS2000/OSD loader) error message. Usually, this link name is set when the
ORAENV procedure is called.
Review the following section to know about the user ID requirements.
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.
Other data files, such as.SQL files for the DEMO tables
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
Port-specific installation utilities, such as programs, command procedures, and so on
Default configuration files such as the default
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.
This user ID does not require any special BS2000 privileges.
You must not use the BS2000/OSD System Administrator user ID
TSOS as an Oracle Database installation user ID.
ORAUID does not require any specific
Only the installation phase requires a BS2000 LOGIN under this user ID.
As this user ID functions as a library user ID, most files should be cataloged as follows:
You do not need to define 'write' access for any file after running
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).
DBA user ID needs specific /JOIN privileges to run an Oracle Database. These privileges include:
The right to start jobs immediately, preferably in a
JOBCLASS reserved for Oracle Database background jobs. Failure to do this may cause delays when starting the database and when creating the two-task server.
The right to start jobs with no time limit (
TIME=NTL). Failure to do this may cause database tasks to terminate.
The right to set jobs to TP state. Failure to do this may reduce database performance.
The right to set Common Memory Pools as read-only. Failure to do this may reduce shared-code security.
The BS2000/OSD System Administrator user ID
TSOS should not, under any circumstances, be used as an Oracle Database
DBA user ID.
File access rights set under the
DBA user ID should be:
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.
These user IDs do not require any special BS2000 privileges.
No file owned by a normal user needs any specific access attributes, as Oracle Database programs access such files locally from within that user ID. For example,
LOGIN.SQL data files.
/JOIN privileges are needed.