影响增量检查点的参数，相对完全检查点，增量检查点只更新控制文件的checkpoint scn

•             FAST_START_MTTR_TARGET

--推荐使用，如果设置此参数则下面的参数必须设为0

Since Oracle 9i FAST_START_MTTR_TARGET parameter is the preferred method

of tuning incremental checkpoint target. FAST_START_MTTR_TARGET enables you

to specify the number of seconds the database takes to perform. crash recovery

of a single instance. Based on internal statistics, incremental checkpoint

automatically adjusts the checkpoint target to meet the requirement of

FAST_START_MTTR_TARGET.

V$INSTANCE_RECOVERY.ESTIMATED_MTTR shows the current estimated mean time to

recover (MTTR) in seconds. This value is shown even if FAST_START_MTTR_TARGET

is not specified.

V$INSTANCE_RECOVERY.TARGET_MTTR shows the effective MTTR target in seconds

enforced by the system.

V$MTTR_TARGET_ADVICE shows the number of I/Os resulted by the current workload

under the current MTTR setting and the estimated number of I/Os that would be

resulted by the current workload under other MTTR settings. This view helps

the user to assess the trade-off between runtime performance and setting

FAST_START_MTTR_TARGET to achieve better recovery time.

•             LOG_CHECKPOINT_INTERVAL

--代表redo block的块数

LOG_CHECKPOINT_INTERVAL parameter specifies the maximum number of redo blocks

the incremental checkpoint target should lag the current log tail.

If FAST_START_MTTR_TARGET is specified, LOG_CHECKPOINT_INTERVAL should not

be set or set to 0.

On most Unix systems the operating system block size is 512 bytes.

This means that setting LOG_CHECKPOINT_INTERVAL to a value of 10,000 would

mean the incremental checkpoint target should not lag the current log tail

by more than 5,120,000 (5M) bytes. .  If the size of your redo log is 20M, you are taking 4

checkpoints for each log.

•             LOG_CHECKPOINT_TIMEOUT

--达到此时间阈值即执行增量检查点

The LOG_CHECKPOINT_TIMEOUT parameter specifies the maximum number of seconds

the incremental checkpoint target should lag the current log tail.

In another word, it specifies how long a dirty buffer in buffer cache can

remain dirty.

Checkpoint frequency impacts the time required for the

database to recover from an unexpected failure.  Longer intervals between

checkpoints mean that more time will be required during database recovery.

Oracle recommends using LOG_CHECKPOINT_INTERVAL to control the checkpoint

interval rather than LOG_CHECKPOINT_TIMEOUT, which will initiate a checkpoint

every "n" seconds, regardless of the transaction frequency.  This can cause

unnecessary checkpoints in cases where transaction volumes vary.  Unnecessary

checkpoints must be avoided whenever possible for optimal performance.

•             ARCHIVE_LAG_TARGET

控制primary log switch的频率

When you set the ARCHIVE_LAG_TARGET initialization parameter, you cause the database to examine the current redo log of the instance periodically. If the following conditions are met, then the instance will switch the log:

The current log was created prior to n seconds ago, and the estimated archival time for the current log is m seconds (proportional to the number of redo blocks used in the current log), where n + m exceeds the value of the ARCHIVE_LAG_TARGET initialization parameter.

The current log contains redo records.

In an Oracle Real Application Clusters environment, the instance also causes other threads to switch and archive their logs if they are falling behind. This can be particularly useful when one instance in the cluster is more idle than the other instances (as when you are running a 2-node primary/secondary configuration of Oracle Real Application Clusters).

The ARCHIVE_LAG_TARGET initialization parameter provides an upper limit for how long (in seconds) the current log of the database can span. Because the estimated archival time is also considered, this is not the exact log switch time. The following initialization parameter setting sets the log switch interval to 30 minutes (a typical value). ARCHIVE_LAG_TARGET = 1800

A value of 0 disables this time-based log switching functionality. This is the default setting.

You can set the ARCHIVE_LAG_TARGET initialization parameter even if there is no standby database. For example, the ARCHIVE_LAG_TARGET parameter can be set specifically to force logs to be switched and archived.

ARCHIVE_LAG_TARGET is a dynamic parameter and can be set with the ALTER SYSTEM SET statement.

•             LOG_CHECKPOINTS_TO_ALERT

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.

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.

此外，RAC环境中即便某 节点比较空闲，也会定期产生archive log，即所谓的force archive SCN

当任意节点切换日志时，控制文件的database entry的force scn都会被更新，且比日志的high SCN多1，如果当前日志的low scn落后于force scn，则会强制产生日志切换；

Log switches may also be forced automatically in relatively idle threads of an Oracle parallel server database, to secure recoverability. Whenever a log file is reused in any thread, the force SCN recorded in the database entry of the controlfile is advanced to 1 beyond the high SCN of the reused log file (unless the force SCN was already higher). If the low SCN for the current log file in any enabled thread thereby falls behind the force SCN, a log switch is forced in that thread. This allows that log file to be archived. Until that log file is archived, newer redo in the archived copy of the recently reused log file might not be able to be applied in some recovery scenarios, or to a standby database.

If a thread requiring a forced log switch is not open, the instance that raised the force SCN will perform. the log switch on behalf of the closed thread, and the first available ARCn process in any instance will archive the log file. However, if the thread is open, its instance is prompted to perform. these actions itself. This is done by taking a KK instance lock. The LGWR process in each instance holds the KK instance lock on its own thread. The id2 field identifies the thread number. When this lock is taken by another instance, LGWR recognizes that a forced log switch is required. "

reference http://www.ixora.com.au/notes/log_switch_triggers.htm

redo wastage

一般redo块大小为512字节，写入方式为块对齐512 align，即如果一个redo entry为1025，占用3个块，最后一个块只占用1字节；

SQL> select max(l.lebsz) log_block_size_kccle from sys.x$kccle l where l.inst_id = userenv('Instance') ;

LOG_BLOCK_SIZE_KCCLE

--------------------

                 512

SQL> select name,to_char(value) from v$sysstat where name like '%wastage%';

NAME                                                             TO_CHAR(VALUE)

---------------------------------------------------------------- ----------------------------------------

redo wastage                                                     17433513660

http://www.oracledatabase12g.com/archives/%E9%87%8D%E5%81%9A%E6%97%A5%E5%BF%97%E6%B5%AA%E8%B4%B9redo-wastage.html

查看增量检查点引发的脏块写数量

SQL> select indx,reason from x$kcbbes where indx=4;

      INDX     REASON
---------- ----------
         4    4912284