LOG_FILE_NAME_CONVERT

Property	Description
Parameter type	String
Syntax	LOG_FILE_NAME_CONVERT = 'string1' , 'string2' , 'string3' , 'string4' , ... Where: · string1 is the pattern of the primary database filename · string2 is the pattern of the standby database filename · string3 is the pattern of the primary database filename · string4 is the pattern of the standby database filename You can use as many pairs of primary and standby replacement strings as required. You can use single or double quotation marks. The following are example settings that are acceptable: LOG_FILE_NAME_CONVERT = '/dbs/t1/','/dbs/t1/s_','dbs/t2/ ','dbs/t2/s_'
Default value	There is no default value.
Modifiable	ALTER SESSION
Basic	No

LOG_FILE_NAME_CONVERT converts the filename of a new log file on the primary database to the filename of a log file on the standby database. If you add a log file to the primary database, you must add a corresponding file to the standby database.

If you specify an odd number of strings (the last string has no corresponding replacement string), an error is signalled during startup. If the filename being converted matches more than one pattern in the pattern/replace string list, the first matched pattern takes effect. There is no limit on the number of pairs that you can specify in this parameter (other than the hard limit of the maximum length of multivalue parameters).

When the standby database is updated, this parameter converts the log file name on the primary database to the log file name on the standby database. The file must exist on the standby database and must be writable or the recovery process will halt with an error.

The first string is the pattern found in the log file names on the primary database. The second string is the pattern found in the log file names on the standby database.

You should also use LOG_FILE_NAME_CONVERT to rename the logfiles in the clone control file when setting up the clone database during tablespace point-in-time recovery.

Note:

1. Query for the current value of the parameter

select name, value, isdefault, isses_modifiable, issys_modifiable,

isinstance_modifiable, isdeprecated, description

from v$parameter

where upper(name) = ‘LOG_FILE_NAME_CONVERT’;

NAME	VALUE	IS DEFAULT	ISSES_ MODIFIABLE	ISSYS_ MODIFIABLE	ISINSTANCE_ MODIFIABLE	IS DEPRECATED	DESCRIPTION
log_file_name_convert		TRUE	FALSE	FALSE	FALSE	FALSE	logfile name convert patterns and strings for standby/clone db

Oracle initializatoin parameters

LOG_CHECKPOINTS_TO_ALERT

Property	Description
Parameter type	Boolean
Default value	false
Modifiable	ALTER SYSTEM
Range of values	true | false
Basic	No

LOG_CHECKPOINTS_TO_ALERT lets you log your checkpoints to the alert file. Doing so is useful for determining whether checkpoints are occurring at the desired frequency.

Note:

1. Prior to Oracle9i this parameter was STATIC.

   Oracle generally advises this be set to TRUE as the overhead is negligible but the information in the alert log may be useful.

2. Query for the current value of the parameter

select name, value, isdefault, isses_modifiable, issys_modifiable,

isinstance_modifiable, isdeprecated, description

from v$parameter

where upper(name) = ‘LOG_CHECKPOINTS_TO_ALERT’;

NAME	VALUE	IS DEFAULT	ISSES_ MODIFIABLE	ISSYS_ MODIFIABLE	ISINSTANCE_ MODIFIABLE	IS DEPRECATED	DESCRIPTION
log_checkpoints_to_alert	FALSE	TRUE	FALSE	IMMEDIATE	TRUE	FALSE	log checkpoint begin/end to alert file

Oracle initializatoin parameters

LOG_CHECKPOINT_TIMEOUT

Property	Description
Parameter type	Integer
Default value	1800
Modifiable	ALTER SYSTEM
Range of values	0 to 231 - 1
Basic	No
Real Application Clusters	Multiple instances can have different values.

LOG_CHECKPOINT_TIMEOUT specifies (in seconds) the amount of time that has passed since the incremental checkpoint at the position where the last write to the redo log (sometimes called the tail of the log) occurred. This parameter also signifies that no buffer will remain dirty (in the cache) for more than integer seconds.

Specifying a value of 0 for the timeout disables time-based checkpoints. Hence, setting the value to 0 is not recommended unless FAST_START_MTTR_TARGET is set.

· A checkpoint scheduled to occur because of this parameter is delayed until the completion of the previous checkpoint if the previous checkpoint has not yet completed.

· Recovery I/O can also be limited by setting the LOG_CHECKPOINT_INTERVAL parameter or by the size specified for the smallest redo log. For information on which mechanism is controlling checkpointing behavior, query the V$INSTANCE_RECOVERY view.

Note:

1. Parameter: FAST_START_IO_TARGET

   Parameter: FAST_START_MTTR_TARGET

   View: V$INSTANCE_RECOVERY

2. Query for the current value of the parameter

select name, value, isdefault, isses_modifiable, issys_modifiable,

isinstance_modifiable, isdeprecated, description

from v$parameter

where upper(name) = ‘LOG_CHECKPOINT_TIMEOUT’;

NAME	VALUE	IS DEFAULT	ISSES_ MODIFIABLE	ISSYS_ MODIFIABLE	ISINSTANCE_ MODIFIABLE	IS DEPRECATED	DESCRIPTION
log_checkpoint_timeout	1800	TRUE	FALSE	IMMEDIATE	TRUE	FALSE	Maximum time interval between checkpoints in seconds

Oracle initializatoin parameters

LOG_CHECKPOINT_INTERVAL

Property	Description
Parameter type	Integer
Default value	0
Modifiable	ALTER SYSTEM
Range of values	0 to 231 - 1
Basic	No
Real Application Clusters	Multiple instances can have different values.

LOG_CHECKPOINT_INTERVAL specifies the frequency of checkpoints in terms of the number of redo log file blocks that can exist between an incremental checkpoint and the last block written to the redo log. This number refers to physical operating system blocks, not database blocks.

Regardless of this value, a checkpoint always occurs when switching from one online redo log file to another. Therefore, if the value exceeds the actual redo log file size, checkpoints occur only when switching logs. Checkpoint frequency is one of the factors that influence the time required for the database to recover from an unexpected failure.

· Specifying a value of 0 (zero) for LOG_CHECKPOINT_INTERVAL has the same effect as setting the parameter to infinity and causes the parameter to be ignored. Only nonzero values of this parameter are considered meaningful.

· Recovery I/O can also be limited by setting the LOG_CHECKPOINT_TIMEOUT parameter or by the size specified for the smallest redo log. For information on which mechanism is controlling checkpointing behavior, query the V$INSTANCE_RECOVERY view.

Note:

1. Query for the current value of the parameter

select name, value, isdefault, isses_modifiable, issys_modifiable,

isinstance_modifiable, isdeprecated, description

from v$parameter

where upper(name) = ‘LOG_CHECKPOINT_INTERVAL’;

NAME	VALUE	IS DEFAULT	ISSES_ MODIFIABLE	ISSYS_ MODIFIABLE	ISINSTANCE_ MODIFIABLE	IS DEPRECATED	DESCRIPTION
log_checkpoint_interval	0	TRUE	FALSE	IMMEDIATE	TRUE	FALSE	# redo blocks checkpoint threshold

Oracle initializatoin parameters

LOG_BUFFER

Property	Description
Parameter type	Integer
Default value	512 KB or 128 KB * CPU_COUNT, whichever is greater
Modifiable	No
Range of values	Operating system-dependent
Basic	No

LOG_BUFFER specifies the amount of memory (in bytes) that Oracle uses when buffering redo entries to a redo log file. Redo log entries contain a record of the changes that have been made to the database block buffers. The LGWR process writes redo log entries from the log buffer to a redo log file.

In general, larger values for LOG_BUFFER reduce redo log file I/O, particularly if transactions are long or numerous. In a busy system, a value 65536 or higher is reasonable.

Note:

1. Related:    

   Parameter: LOG_ENTRY_PREBUILD_THRESHOLD

   Parameter: LOG_SIMULTANEOUS_COPIES

   Values above 1Mb are unlikely to yield significant benefit.

   The memory set aside for the log buffer may also be surrounded by 'guard' pages to help protect the redo buffer, hence the size of 'Redo Buffers' shown at instance startup may differ from the value of LOG_BUFFER set in the init.ora file.                

   The redo buffer helps absorb processing spikes. The memory-to-memory transfer (SGA/PGA to REDO BUFFER via SERVER) is much faster than memory-to-disk transfer (REDO BUFFER to REDO LOG via LGWR).  So if a process is making a lot of changes, the redo it generates will be written to a memory buffer. As the buffer fills up, the output process (LGWR) is awakened to empty the buffer. LGWR will need some lead time, since a sufficiently large transaction can generate redo faster than LGWR can write it to disk.  Hence the 1/3 full threshhold trips LGWR into action. 

   If you have small transactions each transaction COMMIT causes redo to be flushed to disk before the COMMIT returns control to the user.

2. Query for the current value of the parameter

select name, value, isdefault, isses_modifiable, issys_modifiable,

isinstance_modifiable, isdeprecated, description

from v$parameter

where upper(name) = ‘LOG_BUFFER’;

NAME	VALUE	IS DEFAULT	ISSES_ MODIFIABLE	ISSYS_ MODIFIABLE	ISINSTANCE_ MODIFIABLE	IS DEPRECATED	DESCRIPTION
log_buffer	14266368	FALSE	FALSE	FALSE	FALSE	FALSE	redo circular buffer size

Oracle initializatoin parameters