| Oracle8i Reference Release 8.1.5 A67790-01 |
|
This chapter contains detailed descriptions of the database initialization parameters, and includes the following topics:
The initialization parameter file is a text file that contains a list of parameters and a value for each parameter. The file should be written in the client's default character set. Specify values in the parameter file which reflect your installation.
The following are sample entries in a parameter file:
PROCESSES = 100 OPEN_LINKS = 12 GLOBAL_NAMES = TRUE
The name of the parameter file varies depending on the operating system. For example, it can be in mixed case or lowercase, or it can have a logical name or a variation on the name INIT.ORA. As the database administrator, you can choose a different filename for your parameter file. There is also an INITDW.ORA file which contains suggested parameter settings for data warehouses and data marts.
See your Oracle operating system-specific documentation for the default locations and filenames for these parameter files. The INIT.ORA file is read by the client-side tool which is being used to start the server (e.g., SQL*Plus).
Sample parameter files are provided on the Oracle Server distribution medium for each operating system. A distributed sample file is sufficient for initial use, but you will want to make changes in the file to tune the database system for best performance. Any changes will take effect after completely shutting down the instance and then restarting it.
Database administrators can use initialization parameters to do the following:
Many initialization parameters can be fine-tuned to improve database performance. Other parameters should never be altered or only be altered under the supervision of Oracle Corporation Worldwide Support staff.
Note: If you are using Trusted Oracle, see the Trusted Oracle documentation information for more details.
This section describes several aspects of setting parameter values in the parameter file. The following topics are included:
The following rules govern the specification of parameters in the parameter file:
PROCESSES = 100 CPU_COUNT = 1 OPEN_CURSORS = 10
ROLLBACK_SEGMENTS = (SEG1, SEG2, SEG3, SEG4, SEG5)
Or, you can enter multiple values without parentheses and commas. For example:
ROLLBACK_SEGMENTS = SEG1 SEG2 SEG3 SEG4 SEG5
Either syntax is valid.
Note: If you choose to enter values over several lines, make sure the parameters are contiguous. If they are not, the first line will not be processed properly. For example, in:
ROLLBACK_SEGMENTS = SEG1 SEG2 OPEN_CURSORS = 10 ROLLBACK_SEGMENTS = SEG3 SEG4
SEG1 and SEG2 will not be set correctly.
ROLLBACK_SEGMENTS = (SEG1, SEG2, \ SEG3, SEG4, SEG5)
NLS_TERRITORY = "CZECH REPUBLIC"
Suggestion: Listing parameters in alphabetical order in the parameter file is a good idea. That makes it easier to find them and helps ensure that each parameter is specified only once.
See your operating system-specific Oracle documentation for more information on parameter files.
If a parameter value contains a special character, then either the special character must be preceded by an escape character or the entire parameter value must be contained in double quotes. For example:
DB_DOMAIN = "JAPAN.ACME#.COM"
or
DB_DOMAIN = JAPAN.ACME\#.COM
Table 1-1 lists the special characters.
Wherever a special character must be treated literally in the initialization parameter file, it must be either prefaced by the escape character or the entire string that contains the special character must be surrounded by single or double quotes.
As described in "Rules", the escape character (\) can also signify a line continuation. If the escape character is followed by an alphanumeric character, then the escape character is treated as a normal character in the input. If it is not followed by an alphanumeric, then the escape character is treated either as an escape character or as a continuation character.
Quotes can be nested in any of three ways. One method is to double the quotes in the nested string. For example:
NLS_DATE_FORMAT = """Today is"" MM/DD/YYYY"
Another method is to alternate single and double quotes. For example:
NLS_DATE_FORMAT = '"Today is" MM/DD/YYYY'
The third method is to escape the inner quotes. For example:
NLS_DATE_FORMAT = "\"Today is\" MM/DD/YYYY"
To change a parameter's value, edit the parameter file. The next time the instance starts, it uses the new parameter values in the updated parameter file. Note that the change does not take effect until the instance is shut down and restarted.
Some initialization parameters are dynamic, that is, they can be modified using the ALTER SESSION, ALTER SYSTEM, or ALTER SYSTEM DEFERRED commands while an instance is running.
Use this syntax for dynamically altering the initialization parameters:
ALTER SESSION SET parameter_name = value ALTER SYSTEM SET parameter_name = value ALTER SYSTEM SET parameter_name = value DEFERRED
Whenever a dynamic parameter is modified using the ALTER SYSTEM, or ALTER SYSTEM DEFERRED command, then the command that modifies the parameter is also recorded in the alert log.
The ALTER SESSION command changes the value of the parameter specific to the session that invokes this command. The value of this parameter does not change for other sessions in the instance. The value of the initialization parameters listed in Table 1-2 can be changed with ALTER SESSION.
The ALTER SYSTEM command modifies the global value of the parameter until the database is shut down. The ALTER SYSTEM command does not always change the parameter value for the current session. Use the ALTER SESSION command to change the parameter value for the current session. The value of the initialization parameters listed in Table 1-3 can be changed with ALTER SYSTEM.
The ALTER SYSTEM DEFERRED command does not modify the global value of the parameter for existing sessions, but the value will be modified for future sessions that connect to the database. The value of the initialization parameters listed in Table 1-4 can be changed with ALTER SYSTEM DEFERRED.
To see the current settings for initialization parameters, use the following SQL*Plus command:
SHOW PARAMETERS
This displays all parameters in alphabetical order, with their current values.
Enter the following text string to see a display for all parameters having BLOCK in their name.:
SHOW PARAMETERS BLOCK
If you display all the parameters, you might want to use the SPOOL command to write the output to a file.
Initialization parameters can be grouped by function in several different ways. For example, there are parameters that perform the following functions:
The set of variable parameters are of particular interest to database administrators because these parameters are used primarily for improving database performance.
The Oracle Server has the following types of initialization parameters:
Some initialization parameters are noted as derived. This means that their values are calculated from the values of other parameters. Normally, you should not alter values for derived parameters, but if you do, the value you specify will override the calculated value.
Initialization parameters with the prefix GC, such as GC_DEFER_TIME, apply to systems using the Oracle Parallel Server. The prefix GC stands for Global Cache. The settings of these parameters determine how the Oracle Parallel Server coordinates multiple instances. The settings you choose have an effect on the use of certain operating system resources.
Additional Information: For more information about the Parallel Server, see Oracle8i Parallel Server Concepts and Administration.
See your system release bulletins or other operating system-specific Oracle documentation for platform-specific information on Parallel Server parameters.
For some initialization parameters, the valid values or ranges depend upon the host operating system. This is denoted in the default, or range column as operating system-dependent. For example, the parameter DB_BLOCK_BUFFERS indicates the number of data buffers in main memory, and its maximum value depends on the operating system. The size of those buffers, set by DB_BLOCK_SIZE, has a system-dependent default value.
See your operating system-specific Oracle documentation for more information on operating system dependent Oracle parameters and operating system parameters.
The variable initialization parameters offer the most potential for improving system performance. Some variable parameters set capacity limits but do not affect performance. For example, when the value of OPEN_CURSORS is 10, a user process attempting to open its 11th cursor receives an error. Other variable parameters affect performance but do not impose absolute limits. For example, reducing the value of DB_BLOCK_BUFFERS does not prevent work even though it may slow down performance.
Increasing the values of variable parameters may improve your system's performance, but increasing most parameters also increases the System Global Area (SGA) size. A larger SGA can improve database performance up to a point. In virtual memory operating systems, an SGA that is too large can degrade performance if it is swapped in and out of memory. Operating system parameters that control virtual memory working areas should be set with the SGA size in mind. The operating system configuration can also limit the maximum size of the SGA.
There are a number of initialization parameters specific to Heterogeneous Services which must be set using a package called DBMS_HS.
For information about specifying these parameters, see Oracle8i Distributed Database Systems.
The following types of parameters might never have to be specified in the parameter file:
Some parameters have a minimum setting below which an Oracle instance will not start. For other parameters, setting the value too low or too high may cause Oracle to perform badly, but it will still run. Also, Oracle may convert some values outside the acceptable range to usable levels.
You may see messages indicating that a parameter value is too low or too high, or that you have reached the maximum for some resource. Frequently, you can wait a short while and retry the operation when the system is not as busy. If a message occurs repeatedly, you should shut down the instance, adjust the relevant parameter, and restart the instance.
The parameter descriptions in this chapter follow the format shown below.
The remaining paragraphs provide a textual description of the parameter and the effects of different settings.
For more information, see references to chapters or books that contain more detailed information on this subject.
Descriptions of the individual initialization parameters follow in alphabetical order.
Most initialization parameter values are global (on a database-wide basis), not per user, unless otherwise specified.
For more information, see your system release bulletins or other operating system-specific Oracle documentation.
| Parameter type: |
boolean |
| Parameter class: |
static |
| Default value: |
TRUE |
| Range of values: |
TRUE, FALSE |
O7_DICTIONARY_ACCESSIBILITY is intended to be used for migration from Oracle7 to Oracle8i. O7_DICTIONARY_ACCESSIBILITY controls restrictions on SYSTEM privileges. If the parameter is set to TRUE, access to objects in SYS schema is allowed (Oracle7 behavior). If this parameter is set to FALSE, SYSTEM privileges that allow access to objects in other schema do not allow access to objects in dictionary schema.
For example, if O7_DICTIONARY_ACCESSIBILITY=FALSE, then the SELECT ANY TABLE statement will allow access to views or tables in any schema except SYS schema (for example, dictionaries could not be accessed). The system privilege, EXECUTE ANY PROCEDURE will ALLOW ACCESS on the procedures in any other schema except in SYS schema.
If you need to access objects in the SYS schema, then you must be granted explicit object privilege. Also, the following roles, which can be granted to the database administrator, also allow access to dictionary objects: SELECT_CATALOG_ROLE, EXECUTE_CATALOG_ROLE, and DELETE_CATALOG_ROLE.
For more information on this parameter and the roles mentioned above, see the Oracle8i Administrator's Guide.
Obsoleted in 8.1.3.
| Parameter type: |
string |
| Parameter class: |
static |
| Default value: |
NESTED_LOOPS |
| Range of values: |
NESTED_LOOPS/MERGE/HASH |
ALWAYS_ANTI_JOIN sets the type of antijoin that the Oracle server uses. The system checks to verify that it is legal to perform an antijoin, and if it is, processes the subquery depending on the value of this parameter. When set to the value NESTED_LOOPS, the Oracle server uses a nested loop antijoin algorithm. When set to the value MERGE, the Oracle server uses the sort merge antijoin algorithm. When set to the value HASH, the Oracle server uses the hash antijoin algorithm to evaluate the subquery.
| Parameter type: |
string |
| Parameter class: |
static |
| Default value: |
standard |
| Range of values: |
NESTED_LOOPS/MERGE/HASH |
ALWAYS_SEMI_JOIN sets the type of semijoin that the Oracle server uses. The system checks to verify that it is legal to perform a semijoin, and if it is, processes the subquery depending on the value of this parameter. When set to the value NESTED_LOOPS, the Oracle server uses a nested loop semijoin algorithm. When set to the value MERGE, it uses the sort merge semijoin algorithm. When set to the value HASH, it uses the hash semijoin algorithm.
| Parameter type: |
integer |
| Parameter class: |
dynamic, scope= ALTER SYSTEM |
| Default value: |
0 |
| Range of values: |
0-10 |
AQ_TM_PROCESSES specifies whether a queue monitor is created. If set to 1, then one queue monitor process is created to monitor the messages. If AQ_TM_PROCESSES is not specified or is set to 0, then the queue monitor is not created.
For more information about this parameter and Advanced Queuing, see the Oracle8i Application Developer's Guide - Fundamentals .
Obsoleted in 8.1.3.
| Parameter type: |
string |
| Parameter class: |
static |
| Default value: |
$ORACLE_HOME/RDBMS/AUDIT |
AUDIT_FILE_DEST specifies the directory where auditing files are stored.
| Parameter type: |
string |
| Parameter class: |
static |
| Default value: |
NONE |
| Range of values: |
NONE (FALSE), DB (TRUE), OS |
AUDIT_TRAIL enables or disables the writing of rows to the audit trail. Audited records are not written if the value is NONE or if the parameter is not present. The OS option enables system-wide auditing and causes audited records to be written to the operating system's audit trail. The DB option enables system-wide auditing and causes audited records to be written to the database audit trail (the SYS.AUD$ table).
The values TRUE and FALSE are also supported for backward compatibility. TRUE is equivalent to DB, and FALSE is equivalent to NONE.
The SQL AUDIT statements can set auditing options regardless of the setting of this parameter.
For more information, see the Oracle8i Administrator's Guide.
Obsoleted in 8.1.3.
| Parameter type: |
string |
| Parameter class: |
static |
| Default value: |
PARTIAL |
| Range of values: |
FULL/PARTIAL |
BACKGROUND_CORE_DUMP specifies whether the SGA is dumped as part of the generated core file. When BACKGROUND_CORE_DUMP=FULL, the SGA is dumped as part of the generated core file. If BACKGROUND_CORE_DUMP=PARTIAL, then the SGA is not dumped as part of the generated core file.
| Parameter type: |
string |
| Parameter class: |
dynamic, scope = ALTER SYSTEM |
| Default value: |
operating system-dependent |
| Range of values: |
valid local pathname, directory, or disk |
BACKGROUND_DUMP_DEST specifies the pathname for a directory where debugging trace files for the background processes (LGWR, DBWn, and so on) are written during Oracle operations.
An ALERT file in the directory specified by BACKGROUND_DUMP_DEST logs significant database events and messages. Anything that affects the database instance-wide or globally is recorded here. This file records all instance start ups and shut downs, messages to the operator console, and errors that cause trace files to be written. It also records every CREATE, ALTER, or DROP operation on a database, tablespace, or rollback segment.
The ALERT file is a normal text file. Its filename is operating system-dependent. For platforms that support multiple instances, it takes the form ALERT_sid.LOG. This file grows slowly, but without limit, so the database administrator might want to delete it periodically. The file can be deleted even when the database is running.
For more information, see the Oracle8i Administrator's Guide. See your operating system-specific Oracle documentation for the default value.
Obsoleted in 8.1.3.
| Parameter type: |
boolean |
| Parameter class: |
dynamic, scope = ALTER SYSTEM DEFERRED |
| Default value: |
TRUE |
| Range of values: |
TRUE/FALSE |
BACKUP_TAPE_IO_SLAVES specifies whether I/O slaves are used by the Recovery Manager to backup, copy, or restore data to tape. When BACKUP_TAPE_IO_SLAVES = TRUE, an I/O slave process is used to write to or read from a tape device. If this parameter is FALSE (the default), then I/O slaves are not used for backups; instead, the shadow process engaged in the backup will access the tape device.
Note, as a tape device can only be accessed by one process at any given time, this parameter is a boolean, that allows or disallows deployment of an I/O slave process to access a tape device.
Typically, I/O slaves are used to "simulate" asynchronous I/O on platforms that either do not support asynchronous I/O or implement it inefficiently. However, I/O slaves can be used even when asynchronous I/O is being used. In that case, the I/O slaves will use asynchronous I/O.
In order to perform duplexed backups, this parameter needs to be enabled, otherwise an error will be signalled. Recovery Manager will configure as many slaves as needed for the number of backup copies requested whent his parameter is enabled.
| Parameter type: |
integer |
| Parameter class: |
static |
| Default value: |
1 Mb |
| Range of values: |
system-dependent value |
BITMAP_MERGE_AREA_SIZE parameter specifies the amount of memory used to merge bitmaps retrieved from a range scan of the index. The default value is 1 Mb. A larger value should improve performance because the bitmap segments must be sorted before being merged into a single bitmap. This parameter is not dynamically alterable at the session level.
| Parameter type: |
boolean |
| Parameter class: |
static |
| Default value: |
FALSE |
| Range of values: |
TRUE/FALSE |
BLANK_TRIMMING specifies the data assignment semantics of character datatypes. A value of TRUE allows the data assignment of a source character string/variable to a destination character column/variable even though the source length is longer than the destination length. In this case, however, the additional length over the destination length is all blanks. This is in compliance with SQL92 Transitional Level and above semantics.
A value of FALSE disallows the data assignment if the source length is longer than the destination length and reverts to SQL92 Entry Level semantics.
| Parameter type: |
string |
| Parameter class: |
static |
| Default value: |
none |
BUFFER_POOL_KEEP is used to improve buffer cache performance. It allows you to keep an object in the buffer cache.
For more information, see Oracle8i Tuning.
| Parameter type: |
string |
| Parameter class: |
static |
| Default value: |
none |
BUFFER_POOL_RECYCLE is used to improve buffer cache performance. It allows you to limit the size of an object in the buffer cache.
For more information, see Oracle8i Tuning.
Obsoleted in 8.1.3.
Obsoleted in 8.0.4. Use DB_FILE_DIRECT_IO_COUNT instead.
Obsoleted in 8.1.3.
Obsoleted in 8.1.3.
| Parameter type: |
integer |
| Parameter class: |
static |
| Default value: |
operating system-dependent |
| Range of values: |
0 - 255 |
COMMIT_POINT_STRENGTH specifies a value that determines the commit point site in a distributed transaction. The node in the transaction with the highest value for COMMIT_POINT_STRENGTH will be the commit point site. A database's commit point strength should be set relative to the amount of critical shared data in the database. For example, a database on a mainframe computer typically shares more data among users than one on a personal computer. Therefore, COMMIT_POINT_STRENGTH should be set to a higher value for the mainframe computer.
The commit point site stores information about the status of transactions. Other computers in a distributed transaction require this information, so it is desirable to have machines that are always available as commit point sites. Therefore, set COMMIT_POINT_STRENGTH to a higher value on your more available machines.
For more information about two-phase commit, see Oracle8i Concepts and Oracle8i Distributed Database Systems. See also your operating system-specific Oracle documentation for the default value.
| Parameter type: |
string |
| Parameter class: |
static |
| Default value: |
8.1.0 |
| Range of values: |
default release to current release |
| Multiple instances: |
must have the same value |
COMPATIBLE allows you to use a new release, while at the same time guaranteeing backward compatibility with an earlier release. This is in case it becomes necessary to revert to the earlier release. This parameter specifies the release with which the Oracle server must maintain compatibility. Some features of the current release may be restricted.
When using the standby database and feature, this parameter must have the same value on the primary and standby databases, and the value must be 7.3.0.0.0 or higher.
This parameter allows you to immediately take advantage of the maintenance improvements of a new release in your production systems without testing the new functionality in your environment.
The default value is the earliest release with which compatibility can be guaranteed.
The value of COMPATIBLE must be set to 8.1 or higher in order to use stored columns of UROWID type. ROWID pseudo-columns for index-organized tables will work irrespective of the parameter setting.
For more information, see Oracle8i Migration. See also your operating system-specific Oracle documentation for the default value.
Obsoleted in 8.1.3.
Obsoleted in 8.1.3.
| Parameter type: |
integer |
| Parameter class: |
dynamic, scope = ALTER SYSTEM |
| Default value: |
7 (days) |
| Range of values: |
0 - 365 (days) |
Records in some sections in the control file are circularly reusable while records in other sections are never reused. CONTROL_FILE_RECORD_KEEP_TIME applies to reusable sections.
It specifies the minimum age in days that a record must have before it can be reused. In the event a new record needs to be added to a reusable section and the oldest record has not aged enough, the record section expands. If CONTROL_FILE_RECORD_KEEP_TIME is set to 0, then reusable sections never expand and records are reused as needed.
Table 1-5 lists the names of reusable sections.
|
ARCHIVED LOG |
BACKUP CORRUPTION |
|
BACKUP DATAFILE |
BACKUP PIECE |
|
BACKUP REDO LOG |
BACKUP SET |
|
COPY CORRUPTION |
DATAFILE COPY |
|
DELETED OBJECT |
LOGHISTORY |
|
OFFLINE RANGE |
|
| Parameter type: |
string |
| Parameter class: |
static |
| Default value: |
operating system-dependent |
| Range of values: |
1 - 8 filenames |
CONTROL_FILES specifies one or more names of control files, separated by commas. Oracle Corporation recommends using multiple files on different devices or mirroring the file at the OS level.
For more information, see the Oracle8i Administrator's Guide.
| Parameter type: |
string |
| Parameter class: |
dynamic, scope = ALTER SYSTEM |
| Default value: |
$ORACLE_HOME/DBS/ |
CORE_DUMP_DEST specifies the directory where core files are dumped.
| Parameter type: |
integer |
| Parameter class: |
static |
| Default value: |
automatically set by Oracle |
| Range of values: |
0 - unlimited |
| OK to change: |
no |
CPU_COUNT specifies the number of CPUs available to Oracle. Oracle uses it to set the default value of the LOG_SIMULTANEOUS_COPIES parameter. On single-CPU computers, the value of CPU_COUNT is 1.
Warning: On most platforms, Oracle automatically sets the value of CPU_COUNT to the number of CPUs available to your Oracle instance. Do not change the value of CPU_COUNT.
If there is heavy contention for latches, change the value of LOG_SIMULTANEOUS_COPIES to twice the number of CPUs you have. Do not change the value of CPU_COUNT.
For more information, see the Oracle8i Administrator's Guide. See also your operating system-specific Oracle documentation for information about this parameter.
| Parameter type: |
integer |
| Parameter class: |
static |
| Default value: |
8 Mb |
| Range of values: |
operating system-dependent |
CREATE_BITMAP_AREA_SIZE specifies the amount of memory allocated for bitmap creation. The default value is 8 Mb. A larger value might lead to faster index creation. If cardinality is very small, you can set a small value for this parameter. For example, if cardinality is only 2 then the value can be on the order of kilobytes rather than megabytes. As a general rule, the higher the cardinality, the more memory is needed for optimal performance. This parameter is not dynamically alterable at the session level.
| Parameter type: |
boolean |
| Parameter class: |
static |
| Default value: |
FALSE |
| Range of values: |
TRUE/FALSE |
If CURSOR_SPACE_FOR_TIME is set to TRUE, the database uses more space for cursors to save time. It affects both the shared SQL area and the client's private SQL area.
Shared SQL areas are kept pinned in the shared pool when this parameter's value is TRUE. As a result, shared SQL areas are not aged out of the pool as long as there is an open cursor that references them. Because each active cursor's SQL area is present in memory, execution is faster. Because the shared SQL areas never leave memory while they are in use, however, you should set this parameter to TRUE only when the shared pool is large enough to hold all open cursors simultaneously.
Setting this parameter to TRUE also retains the private SQL area allocated for each cursor between executes instead of discarding it after cursor execution. This saves cursor allocation and initialization time.
For more information, see Oracle8i Concepts.
| Parameter type: |
integer |
| Parameter class: |
static |
| Default value: |
32768 buffers |
| Range of values: |
4 - operating system-specific |
| OK to change: |
yes |
| Multiple instances: |
can have different values |
DB_BLOCK_BUFFERS specifies the number of database buffers available in the buffer cache. It is one of the primary parameters which contribute to the total memory requirements of the SGA on the instance.
The DB_BLOCK_BUFFERS parameter, together with the DB_BLOCK_SIZE parameter, determines the total size of the buffer cache. Effective use of the buffer cache can greatly reduce the I/O load on the database. Since DB_BLOCK_SIZE can be specified only when the database is first created, use DB_BLOCK_BUFFERS to control the size of the buffer cache.
This parameter affects the probability that a data block will be pinged when Parallel Server is enabled: the more buffers, the more chance of pings.
Note: The checkpoint process is enabled by default if the system configuration is such that moving checkpoint processing from the logwriter to a separate process is deemed to improve performance. Currently, the criteria are DB_FILES >= 50 or
DB_BLOCK_BUFFERS >= 10000.
For more information, see Oracle8i Concepts. See also your operating system-specific Oracle documentation.
Obsoleted in 8.1.3.
| Parameter type: |
boolean |
| Parameter class: |
dynamic, scope = ALTER SESSION, ALTER SYSTEM DEFERRED |
| Default value: |
FALSE |
| Range of values: |
TRUE / FALSE |
DB_BLOCK_CHECKING is used to control whether block checking is done fro transaction managed blocks. As early detection of corruptions is ueful, and has minimal, if any, performance impact, Oracle recommends that the default setting be used. The FALSE setting is provided for compatibility with ealier releases where block checking is disabled as a default. As the parameter is dynamic, it provides more flexibility than events 10210 and 10211, which it will ultimately replace. Note that the setting of DB_BLOCK_CHECKING overrides any setting of events 10210 and 10211.
| Parameter type: |
boolean |
| Parameter class: |
dynamic, scope = ALTER SYSTEM |
| Default value: |
FALSE |
| Range of values: |
TRUE/FALSE |
If DB_BLOCK_CHECKSUM is set to TRUE, DBWn and the direct loader will calculate a checksum and store it in the cache header of every data block when writing it to disk. Checksums will be verified when a block is read only if this parameter is TRUE and the last write of the block stored a checksum.
If DB_BLOCK_CHECKSUM is set to TRUE, every log block will also be given a checksum before it is written to the current log.
Warning: Setting DB_BLOCK_CHECKSUM to TRUE can cause performance overhead.
For more information, see the Oracle8i Administrator's Guide.
Obsoleted in 8.1.3.
| Parameter type: |
integer |
| Parameter class: |
static |
| Default value: |
CPU_COUNT/2 |
| Range of values: |
1 - twice the number of CPUs |
DB_BLOCK_LRU_LATCHES specifies the upper bound of the number of LRU latch sets. Set this parameter to a value equal to the desired number of LRU latch sets. Oracle decides whether to use this value or reduce it based on a number of internal checks. If the parameter is not set, Oracle calculates a value for the number of sets. The value calculated by Oracle is usually adequate. Increase this only if misses are higher than 3% in V$LATCH.
Obsoleted in 8.1.3.
DB_BLOCK_MAX_DIRTY_TARGET specifies the number of buffers that can be dirty (modified and different from what is on disk) in the buffer cache. It indirectly specifies a rough limit on the number of blocks that must be read during crash and instance recovery.
Note that the FAST_START_IO_TARGET parameter, (available only with the Oracle Enterprise Edition), can be used to enforce a a more accurate bound on the number of IOs during recovery.)
DBWn will write out buffers to attempt to limit the number of dirty buffers in the cache below the specified value.
Setting this value to 0 disables the mechanism that limits the number of dirty buffers in the cache. All other writing activity continues as before (that is, it is unaffected by setting this parameter to 0).
DB_BLOCK_SIZE specifies the size in bytes of Oracle database blocks. Typical values are 2048 and 4096. The value for DB_BLOCK_SIZE in effect at CREATE DATABASE time determines the size of the blocks; at all other times the value must be set to the original value.
This parameter affects the maximum value of the FREELISTS storage parameter for tables and indexes. DSS (data warehouse) database environments tend to benefit from larger block size values.
For more information about block size, see Oracle8i Concepts. See also your operating system-specific Oracle documentation for the default value.
DB_DOMAIN specifies the extension components of a global database name, consisting of valid identifiers, separated by periods. Specifying DB_DOMAIN as a unique string for all databases in a domain is recommended. For example, this parameter allows one department to create a database without worrying that it might have the same name as a database created by another department. If one sales department's DB_DOMAIN = "JAPAN.ACME.COM", then their "SALES" database (SALES.JAPAN.ACME.COM) is uniquely distinguished from another database with DB_NAME = "SALES" but with DB_DOMAIN = "US.ACME.COM".
If you omit the domains from the name of a database link, Oracle expands the name by qualifying the database with the domain of your local database as it currently exists in the data dictionary, and then stores the link name in the data dictionary. See also the view GLOBAL_NAME.
The following characters are valid in a database domain name:
For more information, see the Oracle8i Administrator's Guide.
| Parameter type: |
integer |
| Parameter class: |
dynamic, scope = ALTER SYSTEM DEFERRED |
| Default value: |
64 |
| Range of values: |
operating system-dependent |
DB_FILE_DIRECT_IO_COUNT is used to specify the number of blocks to be used for I/O operations done by backup, restore or direct path read and write functions. The I/O buffer size is a product of DB_FILE_DIRECT_IO_COUNT and DB_BLOCK_SIZE. The I/O buffer size cannot exceed max_IO_size for your platform.
Assigning a high value to this parameter results in greater use of PGA or SGA memory.
Note: If you have previously used CCF_IO_SIZE and are migrating to DB_FILE_DIRECT_IO_COUNT, remember that CCF_IO_SIZE was specified in bytes while DB_FILE_DIRECT_IO_COUNT must be specified in database blocks.
| Parameter type: |
integer |
| Parameter class: |
dynamic, scope = ALTER SYSTEM, ALTER SESSION |
| Default value: |
8 |
| Range of values: |
operating system-dependent |
DB_FILE_MULTIBLOCK_READ_COUNT is used for multi-block I/O and specifies the maximum number of blocks read in one I/O operation during a sequential scan. The total number of I/Os needed to perform a full table scan depends on factors such as these:
The default is 8. OLTP and batch environments typically have values for this parameter in the range of 4 to 16. DSS (data warehouse) database environments tend to get the most benefit from maximizing the value for this parameter.
The actual maximums vary by operating system; they are always less than the operating system's maximum I/O size expressed as Oracle blocks (max_IO_size/DB_BLOCK_SIZE). Attempts to set this parameter to a value greater than the maximum will cause the maximum to be used.
For information on the optimizer, see Oracle8i Tuning. See also your operating system-specific Oracle documentation for the default value.
| Parameter type: |
string |
| Parameter class: |
static |
| Default value: |
none |
| Range of values: |
character string |
Use DB_FILE_NAME_CONVERT to convert the filename of a new data file on the primary database to a filename on the standby database.
Adding a datafile to the primary database necessitates adding a corresponding file to the standby database. When the standby database is updated, this parameter is used to convert the datafile name on the primary database to the a datafile name on the standby database. The file must exist and be writable on the standby database or the recovery process will halt with an error.
Set the value of this parameter to two strings: the first string is the pattern found in the datafile names on the primary database; the second string is the pattern found in the datafile names on the standby database.
DB_FILE_NAME_CONVERT can also be used to rename the datafiles in the clone coltrolfile when setting up the clone database during Tablespace Point-In-Time Recovery. For more information, see Oracle8i Backup and Recovery Guide.
Obsoleted in 8.1.3.
<