CKPT进程：完全检查点
ckpt进程的作用，触发全局检查点，通过DBWR将buffer_cache中的所有脏块写入数据文件中；由于DBWR的机制，因此lgwr会先写，然后dbwr后写。
当完全检查点被触发时，也就是ckpt被触发，经常触发会造成，大量集中的IO操作，影响性能。
为什么要这个CKPT这个进程，数据一致性关库情况下，默认触发次进程，为了保存数据；如果数据库突然掉电了，内存中的大量脏块数据没了，Oracle数据库启动后会检测，开启实例恢复，实例恢复的起点，就是最近一次的检查点事件；
也就是说，如果长时间未执行CKPT进程，那么实例恢复需要超长的时间，这显然是不科学的；
因此Oracle引入了增量检查点的概念，增量检查点，通知DBWR写脏块，将上次检查点至今的脏块，放入buffer_cache中的脏队列中，等到DBWR进程自动触发条件写（详细DBWR什么时候写，请看上篇博客DBWR写进程），然后每隔3S，CKPT进程检查脏队列，最近一次的增量检查点记录SCN往前移动，减少实例恢复的前滚时间；
检查点有什么作用？ 定位从何时 开始recover操作；
检查点区分： 全局检查点：所有数据块的修改，从Buffer_cache中写入datafiles文件中，造成大量集中的磁盘IO；
增量检查点：阶段性的保存被修改的块，作用为了减少实例恢复的时间，让实例恢复的起点从完全检查点转为最近的一次增量检查点；
部分检查点：定位从什么时候开始备份，用于恢复使用时从备份点开始恢复；
检查点，如何记录，通过SCN，SCN是什么是系统改变号，为何不用时间，因为时间是可以修改的，而SCN号，唯一不重复，作为Oracle数据库的内部时钟；
SCN有几种？ 控制文件记录的SCN，数据文件头部记录的SCN，日志文件记录的SCN，最新的SCN号；
-----一直在说检查点，如何查看呢？
SQL> show parameter alert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_checkpoints_to_alert boolean FALSE
SQL> alter system set log_checkpoints_to_alert=true; 修改参数后，生成的检查点会写入告警日志
System altered.
完全检查点：手动触发： alter system checkpoint;
被动触发：数据库一致性关库时，会触发一次CKPT进程；
影响完全检查点的参数：
SQL> show parameter fast_start_mttr_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target integer 600 （s）
-Oracle检查600秒没有发生一个完全检查点，则触发检查点；
-如果是0，不是说不触发了，而是Oracle自己根据数据库的运行情况自动判断，来自主选择执行时间；
SQL> show parameter log_checkpoint_timeout--距离上一次的检查点，1800秒后，触发增量检查点
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_checkpoint_timeout integer 1800
SQL> show parameter log_checkpoint_inter --距离上一次的检查点，A/512=B=操作系统块数，当日志文件写到了A的大小时，触发条件
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_checkpoint_interval integer 0 =A
----修改参数后，切换日志可以在alter.log日志中查看到增量检查点触发提示：
alter system set log_checkpoints_to_alert=true;
--通知DBWR写脏块，都放在检查点队列中，等待写出
Beginning log switch checkpoint up to RBA [0x13.2.10], SCN: 412322
Thread 1 advanced to log sequence 19 (LGWR switch)
日志切换到央行开始检查点SCN：[ 0x13.2.10 ]，412322
线程1先进的日志序列19（LGWR开关）
部分检查点：
Oracle锁定数据文件头，不会锁表空间，不影响dml操作；
把更备份表空间相关的脏块写入数据文件；
备份期间，表空间的数据块被修改，Oracle会把数据块的镜像写入redolog,一般情况只写入数据块写入redo，备份期间，操作系统cp等uman操作，因为备份期间可以DML操作，如果拷贝的数据块，版本变化如何处理？不一致的备份，orale使用redo记录整体块的镜像；因此导致redo文件增加；
--发生一个检查点：alter system checkpoint; 数据文件+控制文件都会更新SCN；
--备份的表空间SCN不会更新，数据文件头被锁定；
-表空间offline;
操作验证：
SQL> select NAME,CHECKPOINT_CHANGE# from v$datafile;
/picclife/app/hukou/data/undotbs01.dbf 436567
/picclife/app/hukou/data/users01.dbf 436567
SQL> select NAME,CHECKPOINT_CHANGE# from v$datafile_header;
/picclife/app/hukou/data/undotbs01.dbf 436567
/picclife/app/hukou/data/users01.dbf 436567
SQL> alter tablespace users offline;
SQL> alter system checkpoint;
SQL> select NAME,CHECKPOINT_CHANGE# from v$datafile;
/picclife/app/hukou/data/undotbs01.dbf 436623
/picclife/app/hukou/data/users01.dbf 436592
SQL> select NAME,CHECKPOINT_CHANGE# from v$datafile_header;
/picclife/app/hukou/data/undotbs01.dbf 436623
0
-以上对比：在数据库表空间离线后，控制文件记录的数据文件SCN，离线的数据文件不变，数据文件头部的SCN转为0，因为在此时，做了部分检查点操作；
alter tablespace users online; 以下，数据库表空间转为在线后，控制文件记录与数据文件SCN保持一致，且超出普通的表空间的SCN号；
/picclife/app/hukou/data/undotbs01.db 436623
/picclife/app/hukou/data/users01.dbf 436658 --
SQL> select NAME,CHECKPOINT_CHANGE# from v$datafile_header;
/picclife/app/hukou/data/undotbs01.db 436623
/picclife/app/hukou/data/users01.dbf 436658