ORACLE 隐含参数

以下有一些常见参数说明 ,  要在Oracle Support下才能更改。

a、_ALLOW_RESETLOGS_CORRUPTION -- May be only way to start a db backed up
open without setting backup on tablespaces, will result in unsupported system. See the
detailed section for how to use this in a recovery situation.
b、_CORRUPTED_ROLLBACK_SEGMENTS -- Only way to startup with corrupted public
rollback segments. Can be used without fear of desupport.
c、_ALLOW_READ_ONLY_CORRUPTION – Allows you to open a database even if it has
corruption. This should only be used to export as much data from a corrupted database
as is possible before recreating a database. You should not use a database for normal
use that has been opened in this manner as it will not be supported.
d、_SPIN_COUNT -- Sets the number of spins a process will undergo before trying to get a
latch. If CPU is not fully loaded a high value may be best, for a fully loaded CPU a
smaller value may help. Usually defaults to 2000. Can be changed without fear of
desupport. This parameter flips from being undocumented to documented depending on
database version.
e、_LOG_ENTRY_PREBUILD_THRESHOLD – This parameter was documented at one time, now it is undocumented. It is the minimum size of entry in blocks that will be prebuilt for redo log entries, usually set to 30.
f、_LATCH_SPIN_COUNT -- Shows how often a latch request will be taken
g、_DB_BLOCK_WRITE_BATCH – This parameter was documented at one time, but is now undocumented. It is the number of blocks that the db writers will write in each batch, defaults to 512 or DB_FILES*DB_FILE_SIMULTANEOUS_WRITES/2 up to a limit of [$frac14]
of the value of DB_BLOCK_BUFFERS.
h、_CPU_COUNT – This is another parameter that flips from undocumented to
documented. Should be set automatically but on some platforms it doesn't work, set to the number of CPUs. This determines several other parameters.
i、_INIT_SQL_FILE -- This is the initialization SQL script. run by Oracle when a db is
created. This should be sql.bsq, if you change it, you may not be supported.
j、_TRACE_FILES_PUBLIC -- Changes the privileges on trace files such that everyone can read them. Should be OK to change at will.
k、_FAST_FULL_SCAN_ENABLED -- Enables fast full index scans (or disables them) if only indexes are required to resolve the queries. Change this at will.
l、_CORRUPT_BLOCKS_ON_STUCK_RECOVERY -- Can sometimes get a corrupted db up, you probably won't be supported if done without Oracle supports blessing, if you use it, immediately export the tables you need and rebuild the db.
m、_ALWAYS_STAR_TRANSFORMATION -- Helps to tune data warehouse queries if you have a properly designed data warehouse.
n、_SMALL_TABLE_THRESHOLD -- Sets the size of table considered a small table, a small table is automatically pinned into the buffers when queried. Defaults to 2% in Oracle9i

_log_checkpoint_recovery_check

Check redo log after checkpoints. Add debugging code to check the red log after a checkpoint. This code is intended to help find a problem that is generating ora-600 [3020] during recovery. This code is enabed with a new init.ora parameter:

_log_checkpoint_recovery_check=XXX, where XXX is the number of redo blocks to check. This is called in LGWR after every checkpoint. If the init.ora parameter "_log_checkpoint_recovery_check" is zero (default) it does nothing. If it is a positive value then that many blocks of redo are scanned to see that the data file blocks on disk could be recovered if there was an immediate crash. This code was introduced to catch an elusive bug that results in OERI(3020) errors occasionally during crash recovery.

_switch_on_stuck_recovery

REdo generation has been changed so that we should never encounter a change in the feature of the Applying redo logs in SCN order now insures that changes are applied in incarnation/sequence number order. There is a lot of code in recovery that is no longer needed because of this change. This includes the code to backup and rescan after reparing corruptions. The code is being left in to avoid large changes just before v7.0 production release. The following will insure the unneeded code is never excuted unless redo was generated by a beta release or the secret init.ora parameter _switch_on_stuck_recovery=TRUE

Check redo Log contents after checkpoint. This is called in LGWR after every checkpoint. If this parameter is zero (default) it does nothing. If it is a positive value then that many blocks of redo are scanned to see that the data file blocks on disk could be recovered if there was an immediate crash. This code was introduced to catch an elusive bug that results in OERI(3020) errors occasionally during crash recovery.

Checkpoint recovery check: this is the number of redo blocks that kcracl will verify after every LGWR generated checkpoint. Defaults to zero for no checking. When opening the named offline log for redo application and to recalculate future change thread switching this parameter is used.

_log_io_size=redo

log I/O chunk size (blocks/write) related to the OS parameter: I/O chunk size. This value is OS dependent and if left at 0, the value will be automatically determined for each log file.

_log_buffers_debug

/* debugging: fill redo buffers with [well known] junk after writes */ "debug redo buffers (slows things down)"

_log_debug_multi_instance

This parameter is used for debugging purposes. It pretend of multi-instance

_log_entry_prebuild_threshold

This parameter setup the redo entry pre-build threshold. It is a bad idea for a uniprocessor , and is only helpful for a multiprocessor when there is latch contention.

LOG_ENTRY_PREBUILD_THRESHOLD determines the maximum size of a redo entry to prebuild before the copy to the log buffer. Increasing this parameter reduces the time that the redo copy latch is held. This parameter should not be modified if it is a single processor environment or there will be memory contention.

_disable_logging

If this is true, redo records will not be generated no recovery is possible if the instance crashes. It is mainly used for getting good benchmarking results. Default value is FALSE

_log_blocks_during_backup

TRUE value implies before any change is made to a db_block in the buffer cache, a *complete image* of the block is copied to the redo redo log. (This explains why excessive redo would be generated for datafiles excessive redo would be generated for datafiles in hot backup mode.) There is a new init.ora parameter, LOG_BLOCKS_DURING_BACKUP, that controls whether block images ar written to the redo log during hot backup.

Default is TRUE for VM, but port specific with the default defined in sparams.h. This may beset to FALSE if the Oracle block size equals the O/S physical sector sie or if it is otherwise ensured that hot backup reads consistent versios of blocks even if those blocks are being written at the time. Put anther way, this may be set to FALSE on machines that can guarantee the aomicity of a single block I/O request. Default is TRUE Problem is due to split blocks.

_allow_resetlogs_corruption

Added new secret init.ora parameter to override error 1138. When set to TRUE the resetlogs option will be allowed even if there are hot backups that need mor redo applied. Unless you are certain that absolutely all redo, includig the online logs, has been applied, then a full export and import must be done to insure the database is internally consistant.

from 6.0 code

/* if we crashed/shutdown during a hot backup it is over now and we are no longer logging blocks. If they did a manual recovery followed by a NORESETLOGS then the hot backup recovery flag can be cleared. The hot backup recovery flag may alsoneed clearing if RESETLOGS was allowed because of _allow_resetlogs_corruption
parameter. */

from the c file kcv.c 7.0 code

/* if the resetlogs option is in effect we save the highest checkpoint SCN that we see, to be used as the incomplete recovery scn. It only gets used if a resetlogs is done without any recovery. Only backup control file recovery will be allowed and it always rewrites the incomplete recovery scn. We use the highest SCN we can find so that new resetlogs SCN will be greater than anything in the database. This may not be strictly true if the user sets _allow_resetlogs_corruption, and there is a fuzzy file. Note that since resetlogs does not look at the log file headers, datafile checkpoints are all we have to look at.

。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-430224/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-430224/