Checkpoint (CKPT)检查点进程
存盘点
触发 dbwn，写脏数据块
更新数据文件头，更新控制文件
Ckpt 进程会下降数据库性能，但是提高数据库崩溃的时候，自我恢复的性能！可以理
解为阶段性的保存数据，一定的条件满足就触发，就存盘！
检查点有增量检查和完全检查两种：
- 完全检查
1.一致性shutdown数据库的时候。
2.alter system checkpoint;
结果为：
所有的脏数据块都写入数据文件
改写文件的头
- 增量检查
除了完全检查点以外的所有其它检查点都是增量检查点，增量检查是查找检查点列表，将某
一个时间点做标记，该时间点前的脏块写入到数据文件，增量检查不一定马上执行，根据脏
的块多少来决定，这就出现了检查点滞后的情况。
参数log_checkpoints_to_alert决定是否将检查点的信息写入报警日志。默认为假，不写
日志。 可以将这个参数改为真，可以看到检查点的信息。
Fri Jul 06 12:30:52 2007
ALTER SYSTEM SET log_checkpoints_to_alert=TRUE SCOPE=BOTH;
Fri Jul 06 12:31:15 2007
Beginning log switch checkpoint up to RBA [0xb9.2.10], SCN: 3334816
Thread 1 advanced to log sequence 185
Current log# 2 seq# 185 mem# 0: D:\ORACLE\ORADATA\ORA10\REDO02.LOG
Beginning log switch checkpoint up to RBA [0xba。2.10], SCN: 3334818
Thread 1 advanced to log sequence 186 system change number(scn)，数据库的更改号码，如果不懂SCN就绝对不懂数据库，这
句话一点都不夸张，因为数据库中的一切运转都离开不了SCN，SCN的地位在数据库中就向
生活中的时间一样，觉察不到，但又处处离不开。SCN存在于数据块的块头，文件头，
也可以建立特殊的表，使SCN存在于表的行头，SCN存在内存中，它是维护数据库的运行基
本保证。备份和恢复更是根据SCN来决定要重做那些操作和交易。SCN的发生机制在不
同版本会不同，也不用去关心，可以理解为数据库的一切进程操作都要有一个时间
的标志，这就是SCN。Select ,update,delete,insert数据库的一切操作都有SCN。
数据库内的任何操作都产生scn。SCN小的就是先操作的，SCN大的就是后操作的，数据库
使用SCN来维护因果关系。可以将SCN理解为数据库的内部时间。
数据文件头会保存一个特殊的SCN
Stop scn记录在数据文件头上。当数据库处在打开状态时，stop scn被设成最大值0xffff
ffffffff。在数据库正常关闭过程中，stop scn被设置成当前系统的最大scn值。在数据库打
开过程中，Oracle会比较各文件的stop scn和checkpoint scn，如果值不一致，表明数据
库先前没有正常关闭，需要做恢复。
--查看数据库当前scn
select current_scn from V$database;(10g才有)
select dbms_flashback.get_system_change_number() from dual;（9i以后才有） 检查点的scn，检查点是一个特殊的SCN，小于该号码的块都已经存盘了，数据库的恢复只
需要恢复该SCN号码以后的操作就可以了。
--SCN号码和物理的时间有对照表 SMON_SCN_TIME
select * from SMON_SCN_TIME;select name,checkpoint_change# from v$datafile; 日志记录的范围
select GROUP#,sequence#,STATUS,FIRST_CHANGE#,
to_char(FIRST_TIME,'yyyy/mm/dd:hh24:mi:ss') time from V$log;
GROUP# SEQUENCE# STATUS FIRST_CHANGE# TIME
---------- ---------- ---------------- ------------- -------------------
1 13 CURRENT 1176883 2024/11/14:08:47:32
2 11 INACTIVE 1115265 2024/11/12:08:40:01
3 12 INACTIVE 1153044 2024/11/14:05:13:48
11号日志记录了1115265到1153044之间的数据库变化。
12号日志记录了1153044到1176883之间的数据库变化。
13号日志记录了1176883到最后的SCN之间的数据库变化。
select current_scn,CHECKPOINT_CHANGE#,
current_scn-CHECKPOINT_CHANGE# need_reover_change from v$database;
CURRENT_SCN CHECKPOINT_CHANGE# NEED_REOVER_CHANGE
----------- ------------------ ------------------
1193823 1191394 2429 可以看到,数据库的存盘点为 1191394,这个号码以后的变化都不保证正确的存储在
数据库中。这个号码到当前的 1193823 之间存在着 2429 个 SCN 的改变,当然这里含了所
有的 SCN 改变,有的操作产生了 SCN 但并没有改变数据库,如 SELECT 操作,要有 SCN 标记,但
不记录在日志文件中。
select GROUP#,SEQUENCE#,STATUS,FIRST_CHANGE# from v$log;
GROUP# SEQUENCE# STATUS FIRST_CHANGE#
---------- ---------- ---------------- -------------
1 13 CURRENT 1176883
2 11 INACTIVE 1115265
3 12 INACTIVE 1153044上面的2429 个变化都存储在第1组中,日志号码为 13 号。也就是说如果现在数据库崩溃了,
使用 13号日志就可以完成数据库的恢复。
