CKPT,SCN

 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