A checkpoint corresponds to a data structure that defines a SCN in the redo thread of a database. Checkpoints are recorded in the control file and each datafile header,
and are a crucial element of recovery.
简单来说，检查点是一种数据结构，每个检查点对应着 数据库的redo thread中的一个SCN。检查点信息记录在控制文件和每个数据文件头部中。
When a checkpoint occurs, Oracle must update the headers of all datafiles to record the details of the checkpoint. This is done by the CKPT process. The CKPT process does not write blocks to disk, DBWn (DB Writer Process) always performs that task.
当检查点发生的时候，CKPT进程会更新所有数据文件头部和控制文件，记录该检查点的详细信息，同时通知DBWn进程将所有脏数据从缓存中到数据文件。
A Checkpoint is a crucial mechanism in consistent database shutdowns, instance recovery, and Oracle Database operation generally.
对于consistent数据库关闭、实例恢复和数据库正常运行来说，检查点是一个很关键的机制。
The term checkpoint has the following related meanings:
检查点具有以下相关含义：
1：A data structure that indicates the checkpoint position, which is the SCN in the redo stream where instance recovery must begin. The checkpoint position is determined by the oldest dirty buffer in the database buffer cache. The checkpoint position acts as a pointer to the redo stream and is stored in the control file and in each data file header.
包含的数据结构指明了检查点位置，检查点位置对应着一个记录在redo stream中的SCN，实例恢复必须从此SCN开始。(可以理解为实例恢复是从最近的检查点对应的SCN开始的)
检查点位置由缓存中最老的脏缓存决定的，相当于一个指向redo stream 中的指针，检查点相关信息记录在控制文件盒每个数据库文件头部中。
2：The writing of modified database buffers in the database buffer cache to disk.
将缓存中的数据写入磁盘
The checkpoint process (CKPT) updates the control file and data file headers with checkpoint information and signals DBWn to write blocks to disk.
Checkpoint information includes the checkpoint position, SCN, location in online redo log to begin recovery, and so on.
CKPT进程负责更新控制文件和数据文件头部中的检查点信息，通知DBWn进行写操作，检查点信息包括检查点位置，SCN，在线重做日志中开始恢复的位置等。
-----检查点的作用，什么时候发生检查点
Purpose of Checkpoints
Oracle Database uses checkpoints to achieve the following goals:
Oracle数据库使用检查点来达到以下几个目的：
A: Reduce the time required for recovery in case of an instance or media failure
减少执行实例恢复或者介质恢复需要的时间
B: Ensure that dirty buffers in the buffer cache are written to disk regularly
确保脏缓存能有规律的写入硬盘
C: Ensure that all committed data is written to disk during a consistent shutdown
确保所有已提交的数据在数据库一致关闭时能写入硬盘。
When does a checkpoint happen
什么时候发生检查点？ 以下几种情况下(包括但不限于)会发生检查点
A: At each switch of the redo log files. 每次日志切换时候
B: When the delay for LOG_CHECKPOINT_TIMEOUT is reached.
LOG_CHECKPOINT_TIMEOUT 规定的时间达到
C: When the size in bytes corresponding to (LOG_CHECKPOINT_INTERVAL* size of IO OS blocks) is written on the current redo log file.
当LOG_CHECKPOINT_INTERVAL* size of IO OS blocks 这么多字节重做日志写入 当前重做日志文件
D: When ALTER SYSTEM SWITCH LOGFILE command is issued.
E: When ALTER SYSTEM CHECKPOINT command is issued.
当上述命令执行时候发生检查点
-----有哪些类型的检查点
The checkpoint process (CKPT) is responsible for writing checkpoints to the data file headers and control file. Checkpoints occur in a variety of situations. For example, Oracle Database uses the following types of checkpoints:
Thread checkpoints ------线程检查点，也就是数据库检查点
也可以这样理解：这是数据库级别上的检查点，针对整个数据库
The database writes to disk all buffers modified by redo in a specific thread before a certain target. The set of thread checkpoints on all instances in a database is a database checkpoint. Thread checkpoints occur in the following situations:
A: Consistent database shutdown
B: ALTER SYSTEM CHECKPOINT statement
C: Online redo log switch
D: ALTER DATABASE BEGIN BACKUP statement
Tablespace and data file checkpoints
表空间和数据文件级别上的检查点 ，这种检查点发生在数据库的部分表空间和数据文件级别上；
The database writes to disk all buffers modified by redo before a specific target. A tablespace checkpoint is a set of data file checkpoints,
one for each data file in the tablespace. These checkpoints occur in a variety of situations,
including making a tablespace read-only or taking it offline normal, shrinking a data file, or executing ALTER TABLESPACE BEGIN BACKUP.
Incremental checkpoints
An incremental checkpoint is a type of thread checkpoint partly intended to avoid writing large numbers of blocks at online redo log switches.、
增量检查点是一种线程检查点，主要是避免当线日志发生切换时候，出现大量的数据写操作。
DBWn checks at least every three seconds to determine whether it has work to do.
DBWn每三秒钟醒来查看是否有工作要做，有数据需要写入硬盘
When DBWn writes dirty buffers, it advances the checkpoint position, causing CKPT to write the checkpoint position to the control file, but not to the data file headers.
当DBWn在写脏缓存时候，它同时将检查点位置前移，促使CKPT将检查点位置写入控制文件，但是不写入数据文件头部。
Other types of checkpoints include instance and media recovery checkpoints and checkpoints when schema objects are dropped or truncated.
------检查点相关的参数
Checkpoint Parameters
LOG_CHECKPOINT_INTERVAL
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.
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.
Default Value : 0
LOG_CHECKPOINT_TIMEOUT
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.
Default value : 1800 sec
FAST_START_MTTR_TARGET
FAST_START_MTTR_TARGET enables you to specify the number of seconds the database takes to perform crash recovery of a single instance. When specified, FAST_START_MTTR_TARGET is overridden by LOG_CHECKPOINT_INTERVAL.
Note:
You must disable or remove the FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL, and LOG_CHECKPOINT_TIMEOUT initialization parameters when using FAST_START_MTTR_TARGET. Setting these parameters interferes with the mechanisms used to manage cache recovery time to meet FAST_START_MTTR_TARGET.
FAST_START_MTTR_TARGET 非零则 将会启动自动checkpointing
FAST_START_IO_TARGET in 9i is replaced by FAST_START_MTTR_TARGET parameter from 10g.
Default Value : 0
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.
True则将checkpoint相关信息记录在alert_$ORACLE_SID.log中
Default Value - False
------自动检查点
Automatic Checkpointing
Oracle Database 10g supports automatic checkpoint tuning which takes advantage of periods of low I/O usage to advance checkpoints and therefore improve availability. Automatic checkpoint tuning is in effect if the FAST_START_MTTR_TARGET database initialization parameter is set to a nonzero value.
FAST_START_MTTR_TARGET 非零则 将会启动自动checkpointing
Observe the following recommendations to take advantage of automatic checkpoint tuning.
If it is necessary to control the time to recover from an instance or node failure, then set FAST_START_MTTR_TARGET to the desired MTTR in seconds. If targeting a specific MTTR is unnecessary, then set FAST_START_MTTR_TARGET to a nonzero value to enable automatic checkpoint tuning.
Fast-start checkpointing can be disabled by setting FAST_START_MTTR_TARGET=0. Disable fast-start checkpointing only when system I/O capacity is insufficient with fast-start checkpointing enabled and achieving a target MTTR is not important.
Enabling fast-start checkpointing increases the average number of writes per transaction that DBWn issues for a given workload (when compared with disabling fast-start checkpointing). However, if the system is not already near or at its maximum I/O capacity, then fast-start checkpointing has a negligible impact on performance.
The percentage of additional DBWn writes with very aggressive fast-start checkpointing depends on many factors, including the workload, I/O speed and capacity, CPU speed and capacity, and the performance of previous recoveries.
If FAST_START_MTTR_TARGET is set to a low value, then fast-start checkpointing is more aggressive, and the average number of writes per transaction that DBWn issues is higher in order to keep the thread checkpoint sufficiently advanced to meet the requested MTTR.
Conversely, if FAST_START_MTTR_TARGET is set to a high value, or if automatic checkpoint tuning is in effect (that is, FAST_START_MTTR_TARGET is set to a nonzero value), then fast-start checkpointing in less aggressive, and the average number of writes per transaction that DBWn issues is lower.
Fast-start checkpointing can be explicitly disabled by setting FAST_START_MTTR_TARGET=0. Disabling fast-start checkpointing leads to the fewest average number of writes per transaction for DBWn for a specific workload and configuration, but also results in the highest MTTR.
-----检查点相关等待时间
Checkpoint related Wait Events
Checkpoint Completed
A session is waiting for checkpoint to complete. This could happen for example during a close database or a local checkpoint. A Local Checkpoint is one that is initiated by the user (for example, performed by ALTER SYSTEM CHECKPOINT LOCAL statements).
Wait Time: 5 seconds
Parameters: None
Log File Switch (checkpoint incomplete)
Waiting for a log switch because the session cannot wrap into the next log. Wrapping cannot be performed because the checkpoint for that log has not completed.
Wait Time: 1 second
Parameters: None
----检查点与实例恢复
Checkpoints and Instance Recovery
Instance recovery uses checkpoints to determine which changes must be applied to the data files.
The checkpoint position guarantees that every committed change with an SCN lower than the checkpoint SCN is saved to the data files.
During instance recovery, the database must apply the changes that occur between the checkpoint position and the end of the redo thread.
Some changes may already have been written to the data files. However, only changes with SCNs lower than the checkpoint position are guaranteed to be on disk.
实例恢复使用检查点来决定恢复从哪个CHANGE/SCN开始，每个检查点都对应一个时间戳，实例恢复从实例崩溃前最后一个checkpoint对应的SCN SCN_1开始，SCN小于SCN_1而且已经
提交的事务所做的修改都已经写入数据文件。
------------检查点性能
Checkpoint Performance
Frequent checkpoints will enable faster recovery, but can cause performance degradation. A Checkpoint might be a costly operation when the number of files are huge since it has to freeze the datafile headers during the process. There is a performance trade-off regarding frequency of checkpoints.
频繁发生检查点会是实例恢复或者介质恢复更快，但是也会导致性能下降。当文件数量多的时候，checkpoint可能是一个昂贵的操作，因为它必须在此过程中必须冻结数据文件头部。
More frequent checkpoints enable faster database recovery after a crash. This is why some customer sites which have a very low tolerance for unscheduled system downtime will often choose this option. However, the performance degradation of frequent checkpoints may not justify this philosophy in many cases. Let's assume the database is up and running 95% of the time, and unavailable 5% of the time from frequent instance crashes or hardware failures requiring database recovery. For most customer sites, it makes more sense to tune for the 95% case rather than the rare 5% downtime.
Checkpoint occurs at every log switch. Hence frequent log switches will start the checkpoints and may degrade the performance. If a previous checkpoint is already in progress, the checkpoint forced by the log switch will override the current checkpoint. This necessitates well-sized redo logs to avoid unnecessary checkpoints as a result of frequent log switches. A good rule of thumb is to switch logs at most every twenty minutes. Having your log files too small can increase checkpoint activity and reduce performance. Oracle recommends the user to set all online log files to be the same size, and have at least two log groups per thread.
Set the value of FAST_START_MTTR_TARGET to 3600. This enables Fast-Start checkpointing and the Fast-Start Fault Recovery feature, but minimizes its effect on run-time performance while avoiding the need for performance tuning of FAST_START_MTTR_TARGET.