Friday, October 17, 2008

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