Oracle® Database Installation and Administration Guide 11g Release 2 (11.2) for Fujitsu BS2000/OSD Part Number E27508-02 |
|
|
PDF · Mobi · ePub |
Every time SQL*Plus starts an Oracle Database instance, it uses a set of parameters which specify the characteristics of the instance's operation. These parameters are kept in a file, typically named sid
.DBS
.INIT
.ORA
.This appendix lists unsupported parameters, and lists other parameters that you may need to change to customize the Oracle Database for the system. Refer to the Oracle Database Reference manual for general descriptions of the parameters listed in this Appendix.
The $ORAC1120.DEMO.DBS.INIT.ORA
parameter file is created upon initial installation and can be edited as a text file.
The following initialization file parameters, described in the generic documentation are not supported by Oracle Database 11g for BS2000/OSD.
MAX_DUMP_FILE_SIZE
OS_ROLES
AUDIT_SYSLOG_LEVEL
MEMORY_MAX_TARGET
MEMORY_TARGET
Specifying these parameters in the initialization file results in an Oracle Database error during startup. The workaround is to remove such lines from the file.
This section contains additional information about initialization parameters.
This parameter specifies the path name (directory or prefix) where debugging trace files for the background processes (LGWR, DBWn, and so on.) are written during Oracle operations. Furthermore, it specifies the path name for the alert file. The default value for this parameter is the current BS2000 user ID of the Oracle background processes. You can specify a prefix for the trace and alert files in the following format:
BACKGROUND_DUMP_DEST=BDD
You can also specify a POSIX directory for this parameter, if you have enabled the POSIX subsystem.
Note:
This parameter is ignored by the new diagnosability infrastructure introduced in Oracle Database 11g, which places trace and core files in a location controlled by theDIAGNOSTIC_DEST
initialization parameterThis parameter specifies the path name (directory or prefix) where the server writes debugging trace files on behalf of a user process. The default value for this parameter is the current BS2000 user ID of the Oracle Database processes.
You can specify a prefix for the trace files as follows:
USER_DUMP_DEST=UDD
You can also specify a POSIX directory for this parameter, if you have enabled the POSIX subsystem.
Note:
This parameter is ignored by the new diagnosability infrastructure introduced in Oracle Database 11g, which places trace and core files in a location controlled by theDIAGNOSTIC_DEST
initialization parameterThis parameter specifies the path name (directory or prefix) into which the audit trail is written when the AUDIT_TRAIL
initialization parameter is set to OS
. Usually this value is used as a prefix for BS2000 file names. You can also specify a POSIX directory for this parameter, if you have enabled the POSIX subsystem. The default value for this parameter is SID
. ADUMP. The name of the audit files is tsn-seqno
. AUD
, where tsn
is the task sequence number of the current task and seqno
is a sequence number. Bear in mind that regardless of whether database auditing is enabled, Oracle/BS2000 always records some database-related actions into the operating system audit file: instance startup, shutdown and connections with administrator privileges.
This parameter can have one of the following values:
2K, 4K, 6K, 8K, 16K, 32K, if you use BS2000 2K pubset format.
4K, 8K, 16K, 32K, if you use BS2000 4K pubset format.
The default value of this parameter is 64K/DB_BLOCK_SIZE
, which is also the maximum value. Setting this parameter beyond this limit has no effect.
If you plan to create a large database, then you must set this value to the maximum of 2044 before creating the database.
This parameter is ignored on Oracle Database 11g for BS2000/OSD. Buffers in the SGA are page fixed only during I/O operations. Otherwise, the SGA on BS2000 is pageable.
This parameter should not be specified on Oracle Database 11g for BS2000/OSD. Because the SGA is not permanently pagefixed as it is on some other systems, there is little benefit in reserving SGA expansion space with the SGA_MAX_SIZE parameter. It defaults to the actual SGA size.
The value of this parameter should always be set so that when multiplied by the value of SF_PBLKSIZE
the result equals 32K.