Skip Headers
Oracle® Database Installation and Administration Guide
11g Release 2 (11.2) for Fujitsu BS2000/OSD

E27508-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

2 Architecture and Implementation

This chapter describes the Oracle Database system architecture for Fujitsu BS2000/OSD. The chapter includes the following topics:

2.1 Operating System Environment

Oracle Database 11g Release 2 runs on the BS2000/OSD operating system.

Oracle Database uses not only the interfaces of the native BS2000, but also the POSIX interfaces. This section includes the following:

2.1.1 File Systems

Oracle Database 11g Release 2 operates on two file systems, namely, BS2000 Data Management System (DMS) and the POSIX file system.

The POSIX file system is hierarchically structured and consists of directories and files.

As in earlier releases, most of the database files for Oracle Database 11g reside in the BS2000 DMS. For example, data files, control files, online and archive redo log files are placed in the BS2000 DMS.

Automatic Diagnostic Repository (ADR), the new feature, requires a hierarchical file system to create a file-based repository for database diagnostic data. So, the directories and files of ADR reside in the POSIX file system.

Therefore, Oracle Database 11g Release 2 for BS2000/OSD requires the POSIX file system. While in Oracle Database 10g the use of the POSIX file system was optional, it is mandatory in Oracle Database 11g Release 2.

During the installation of the Oracle Database software executables, libraries and other files are installed both in the BS2000 DMS and in the POSIX file system.

You must provide access to the POSIX file system. Refer to Chapter 3, " Oracle Database Installation and Deinstallation" for information about access to the POSIX file system.

2.1.2 POSIX Shell

Starting with Oracle Database 11g Release 2, you can start a subset of Oracle Database utilities not only in the BS2000 environment by using SDF commands, but also in the POSIX shell by using shell commands.

The diagnostic data in ADR can be viewed with the command line utility ADRCI. Start this utility in the POSIX shell.

Set the environment variable ORACLE_HOME, prior to starting utilities in the POSIX shell.

2.1.3 Processes

All processes of an Oracle Database instance, for example, dedicated server processes and background processes, run as BS2000 tasks.

If you start a client utility, such as SQL*Plus, in the BS2000 environment by using SDF commands, then the corresponding program is executed in the BS2000 login task.

If you start a client utility in the POSIX shell, then a new POSIX process is created.

Client processes running in the POSIX shell connect to an instance, such as clients in the BS2000 environment. The server process always starts in the BS2000 environment. For more information about processes in the BS2000 environment, refer to Chapter 9, " Oracle Net Services".

2.2 Basic Structures

The concepts of tasks (that is, processes in Oracle terminology) and memory structures (areas) are not BS2000 specific.

Refer to "Memory Architecture" in Oracle Database Concepts and "Process Architecture" in Oracle Database Concepts for detailed information.

This section includes the following:

2.2.1 Database Files and Log Files

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

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

Note:

Both the BS2000/OSD operating system and Oracle Database perform input and output efficiently in units called blocks. A block is 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.

2.2.2 Other Oracle Database Files

The following are the additional Oracle Database files:

2.2.2.1 Initialization File

The initialization file, INIT.ORA, contains a set of parameters that are read when an instance is started.

See Also:

Oracle Database Reference and Oracle Database Administrator's Guide for more information about the initialization file

2.2.2.2 Server Parameter File

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.

2.2.2.3 ORAENV File

Oracle Database utilities and products running in the native BS2000 environment use 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.

2.2.2.4 Control Files

These files record the physical structure of a database and are specified in the initialization file.

2.2.2.5 Message Files

Message texts are stored in table modules, which are dynamically loaded from the ORAMESG library at execution time.

2.2.3 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. To associate an OMF-created file name with its tablespace, 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:

File type Format
control files destOMC.tttttttt
log files destOMLlll.tttttttt
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

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. This file name character limit includes the catid and userid, that may occupy up to 16 characters.

See Also:

Refer to "Using Oracle Managed Files" in Oracle Database Administrator's Guide for more information about file name formats

2.2.4 Bigfile Tablespaces

Oracle Database 11g 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

See Also:

Refer to "Files and Volumes Larger than 32 GB" for more information about handling large objects on BS2000/OSD at
http://manuals.ts.fujitsu.com/file/9118/dv32.pdf

2.3 Two-Task Mode

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.

2.4 Address Space Planning

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 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 Oracle Database areas.

2.4.1 Oracle Database Data Area Placement

The following ORAENV variables control explicit placement of 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

This figure is an example of the placement of data areas

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.

2.5 Oracle Database Environment Definition File

This section describes the ORAENV file, how it is used, and how you use the environment variables to specify the default database.

The 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.

This section describes the following:

2.5.1 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 Oracle Database User's Guide for Fujitsu BS2000/OSD.

2.5.2 Oracle Environment Variables

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

2.5.3 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 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), then the SID remains undefined. Oracle recommends that a link name ORAENV is always defined prior to a call to an Oracle Database program.

2.5.4 POSIX Environment and ORAENV File

Every Oracle Database utility and product running in the POSIX shell get the environment variables from the POSIX environment. All Oracle and BS2000-specific variables can be set in the POSIX environment. The Oracle variable ORACLE_HOME, must be set. To run the utility for a particular database, you must also set the Oracle variable ORACLE_SID. The operating system environment variable PATH must be extended by the path to the Oracle binaries $ORACLE_HOME/bin. If you do not set any other Oracle variable in the POSIX environment, then the Oracle utilities use default values.The installation procedure creates a profile in the ORACLE_HOME directory which can be executed to set and expand the most important variables like ORACLE_HOME, PATH or LD_LIBRARY_PATH. You can process this profile with the command:

$ . your_oracle_home/.profile.oracle

Note:

The Oracle variable BGJPAR is not set after running the .profile.oracle. If you do not set this variable, then the default value, BGJPAR=START=IMME,CPU-LIMIT=NO,LOGGING=*NO, is used by Oracle utilities.

You can change the default value of a variable by setting this variable in the POSIX environment. For example:

$ NLS_LANG=German_Germany.WE8BS2000
$ export NLS_LANG

Oracle also provides the opportunity to use the ORAENV file which you created in the BS2000 file system. In this case, you must create a file oraenvsid in the directory $ORACLE_HOME/dbs that describes the location and name of the ORAENV file.

Let us assume that you want to use the ORAENV file $ORADATA.ORCL.P.ORAENV. Create an oraenvORCL file in $ORACLE_HOME/dbs that contains the name of the BS2000 ORAENV file as follows:

$ ORACLE_HOME=/u01/app/orac1120/db11g
$ export ORACLE_HOME
$ echo '$ORADATA.ORCL.P.ORAENV' > $ORACLE_HOME/dbs/oraenvORCL

Set the Oracle environment variable ORACLE_SID and call the utility:

$ ORACLE_SID=ORCL
$ export ORACLE_SID
$ $ORACLE_HOME/bin/sqlplus /nolog

Oracle utilities running in the POSIX shell handle the variables of the BS2000 ORAENV file as lower-ranking variables. If a variable is set in the POSIX environment and the same variable is defined in the ORAENV file, then the POSIX variable is not overwritten by the ORAENV variable. For example, if the variable NLS_LANG is set to German_Germany.WE8BS2000 in the POSIX environment and NLS_LANG is also defined as American_America.WE8BS2000 in the BS2000 ORAENV file, then the variable keeps the value German_Germany.WE8BS2000 in the program environment of the Oracle utility running in the POSIX shell.

Note:

  • The variables ORACLE_HOME and ORACLE_SID must be set.

  • The ORAENV file in the BS2000 file system must be accessible for the utility.

  • In a POSIX environment, the variables of the BS2000 ORAENV file are handled as subordinated variables.

  • To access a BS2000 ORAENV file, you must create a file oraenvsid in the ORACLE_HOME/dbs directory that contains the fully qualified name of your BS2000 ORAENV file.

  • The SID in the file name oraenvsid is case sensitive and must match the SID specified in ORACLE_SID.

2.6 The ORALOAD Library

The ORALOAD library ($ORAC1120.ORALOAD.LIB by default) is required to run any Oracle Database 11g 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, then you get a BLS (BS2000/OSD loader) error message. Usually, this link name is set when the ORAENV procedure is called.

2.7 The ORAMESG library

The ORAMESG library ($ORAC1120.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, then you get a BLS (BS2000/OSD loader) error message. Usually, this link name is set when the ORAENV procedure is called.

2.8 User ID Requirements

Review the following sections to know about the user ID requirements.

2.8.1 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 file, 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.

  • Oracle installation in the POSIX file system.

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.

2.8.1.1 Authorizations and File Access Rights

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.

  • The ORAUID does not require any specific user attributes or privileges.

  • Only the installation phase requires a BS2000 LOGIN under this user ID.

  • During installation all files are created with the file attributes:

     USER-ACC=ALL-USERS, ACCESS=READ
    
  • You do not need to define write access for any file after installation.

  • The installation in the POSIX file system requires a unique user number and group number for the installation user ID.

2.8.1.2 Default Name

The default name for the ORAUID is $ORAC1120. If you install Oracle Database 11g Release 2 under a different installation user ID, then the installation procedure changes the default value to the current installation user ID in all related files.

2.8.2 DBA User ID

The DBA user ID is a BS2000 user ID that is used as the owner of one or more 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).

2.8.2.1 Authorizations and File Access Rights

The DBA user ID needs specific user attributes and 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 spawning server tasks.

  • 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:

    USER-ACC=OWNER-ONLY, ACCESS=WRITE
    
  • the POSIX user for the DBA user ID must be initialized with a unique user number and group number.

2.8.2.2 Default Name

There is no default name for the DBA user ID.

2.8.3 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 Oracle Database through Oracle Net Services facilities.

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

2.8.3.1 Authorizations and File Access Rights

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.

  • No specific user attributes or privileges are needed.