CKPT,SCN

时间:2021-11-20 15:00:50

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