************************************************************************************************
二、LRUW脏链(按照访问频率进入LRUW)
=只包含一部分脏块
=挂在LRU链上的脏块在被写回磁盘前，它是不能被新读入的块覆盖的。经过一定算法会把一部分脏块转到脏LRU链(即LRUW链)中。
=挂在LRUW链中的块被dbwn写入dbfile后自动从ckptq队列中摘除
*****************************************************************************************
三、 CKPT发送CHECKPOINT信号的触发条件
1. log_checkpoint_timeout时间达到
2.当前redo日志已经写够log_checkpoint_internavl操作系统块大小
3. redo log switch :日志文件满或alter system switch logfile
4. 手工检查点操作:alter system checkpoint
5. alter tablespace XXX begin backup，end backup时
6. alter tablespace , datafile offline,
7.关闭实例（SHUTDOWN ABORT除外）。
8.direct path read时(11g全表扫描);
******************************************************************************************
四、 增量检查点
增量检查点并不会去更新数据文件头，而只是每3秒由CKPT进程去更新控制文件中的LRBA和SCN（日志切换检查点、完全检查点时写数据文件头及数据文件头）。
1.增量检查点主要包含以下步骤
①亲自物理写
CKPT每3秒心跳一次记录检查点位置的工作(更新RBA至控制文件)
②指挥别人写
CKPT定期触发DBWn去写checkpoint queue中的脏数据
2.增量检查点的意义有以下两个：
①减少发生完全检查点时DBWn进程的工作负担
②提高实例恢复的速度
*************************************************************************************
五、检查点心跳原理、检查点队列原理
检查点发生后，触发dbwr，CKPT获取发生检查点时对应的SCN，通知DBWr要写到这个SCN为止。
dbwr 根据 buffer 在被首次修改的时候的时间的顺序批量地写出dirty buffer到datafile。
checkpoint 发生时:
一方面通知dbwr进行下一批写操作。
另一方面，oracle 采用了一个心跳的概念，以3秒的频率将dbwr 写的进度反应到控制文件中，也就是把dbwr当前刚写完的dirty buffer对应的scn和lrba写入数据文件头和控制文件，这就是检查点scn。
3秒只是在控制文件中，ckpt 进程去更新当前dbwr写到哪里了，这个对于ckpt 进程来说叫 heartbeat ，heartbeat是3秒一次: 3秒可以看作不停的检查并记录检查点执行情况（DBWR的写进度）。
检查点发生之后数据库的数据文件、控制文件处于一致状态的含义是不需要进行介质恢复，只表示数据文件头一致，但是并不表示数据文件内容一致，因为数据文件内容可能在没有发生检查点的其他情况下的dbwr写数据文件，这样数据文件内容就不一致，若掉电需要进行崩溃恢复(前滚+回滚)。
*************************************************************************************
第二部分 相关基础知识——Block Address
*************************************************************************************
一、block address(ondisk rba在9.2后作废)
1.uba=Undofile BA
2.dba=Datafile BA=dbfile文件号、块号、行号
rdba=tablespace Relative Database BA
3.rba=Redofile BA=logfile 序列号，logfile 块号，偏移长度
**************************************************************************************
二、low cache rba与low rba
1.low cache rba
=检查点位置
=就是CKPT记录的DBWR写的进度
=low cache rba 以前的更前的已经写入数据文件
2. 当前redo logfile的low scn(first_change#)
SQL> select sequence#,status,first_change# from v$log;
SEQUENCE# STATUS FIRST_CHANGE#
---------- ---------------- -------------
5 INACTIVE 566751
6 CURRENT 589819
4 INACTIVE 531541
first_change#表示当前redo log的low scn，
实例恢复只会用到当前redo log file（原因：日志切换时触发CKPT写了脏块）
3.补充知识：
next_change#表示当前redo log的high scn
select sequence#,first_change# from v$log;
select sequence#,first_change from v$log_history;
Redo log会顺序纪录数据库的各个变化。一组redo log文件写满后，会自动切换到下一组redo log文件。则上一组redo log的high scn就是下一组redo log的low scn。
**********************************************************************
第三部分 相关基础知识——scn
**********************************************************************
说明：文中的名词stop scn与名词end scn均指代"select name,last_change# from v$datafile;"
一、计数器
1.scn计数器(未保存)
=是不断向前累加的的，系统当前的逻辑时钟
=数据库越忙变化越快
=可与时间相互转换
=select CURRENT_SCN from v$database;
2.检查点scn时间点(已保存的)
=已提交到数据文件头或控制文件中的scn值
=有end scn,start scn,system scn等很多种
=保存在数据块头中、控制文件头中、数据文件头中等很多位置
3.为什么用scn而不用时间来界定呢？
在9：00的时执行一条DML语句，
然后修改机器上的时间为8：00，再执行一条DML语句。
机器上的时间区分的话，Oracle区分不出来这两条DML语句的执行顺序
——所以它采用自己产生的SCN计数来区分所有操作的先后顺序。
***********************************************************************************************
二、全局SCN/局部SCN(保存在控制文件中)
1.全局SCN(系统检查点SCN)
=控制文件中自身的SCN
=select checkpoint_change# from v$database;
2.局部SCN（有些表空间的是只读的，故与全局SCN不同）
=控制文件中各文件的SCN
=select name,checkpoint_change# from v$datafile;
*************************************************************************
四、控制文件头中数据文件stop scn和数据文件头中的start scn
1.end scn
=在控制文件中
=正常关闭数据库或正常将表空间置为read only或offline时将修改的
=select name,last_change# from v$datafile;
2.start scn
=在数据文件头中
=select checkpoint_change# from v$datafile_header
================================================================
重要说明：
a.正常关机时(Normal或Immediate)
发出完全检查点，这将为各数据文件设置控制文件中的结束SCN，使其等于数据文件头中对应的开始SCN。
b.异常关机
控制文件中的数据文件头信息(ckpt cnt)与数据文件头一致(ckpt cnt)，所以不需要介质恢复，数据文件和控制文件一致。
此时控制文件中的数据文件stop scn=null,与数据文件头中的start scn不相等，说明数据文件和日志文件不一致，所以需要进行实例恢复。
**********************************************************************************************
第四部分 启动过程中的一致性检查
1．对比start scn与checkpoint scn
2．对比start scn与end scn
***************************************************************************
一、第一次检查是决定是否做media recover(难点)
1.对比控制文件中记录的数据库全局检查点Checkpoint SCN
和
数据文件头部所记录的数据文件的Start SCN 是否相等，从而确定是否需要进行介质恢复。
两者不相等需介质恢复时，
介质恢复的起始点是各数据文件头部所记录的Start SCN对应的RBA
终点是控制文件中记录的数据库全局检查点Checkpoint SCN对应的RBA
2.两者若相等则进行第二次检查是决定是否做instance recover
====================================================================
补充知识：日志切换检查点
在控制文件中,只记录日志切换时的SCN,不记录RBA.
日志切换时,被写进数据文件头的并不只有SCN信息,还有RBA信息.这个RBA是新的连机重做日志文件第一条重做记录的RBA.
**********************************************************************************
二、第二次检查是决定是否做instance recover
对每个数据文件都作这样的检查，然后打开数据库：
1.检查对数据文件头中的中对应文件的Start SCN
和
控制文件中对应文件的end SCN
2.分两种情况
a.如果end SCN等于start SCN，则不需要对那个文件进行redo恢复。
b.如果上次数据库用ABORT等非正常关闭的，数据库没进行检查点处理，而结束SCN仍然为无穷大或null。
在下次启动期间，发现开始SCN和结束SCN不同，需要进行实例恢复：
前滚,online,后滚
3.作为打开过程的一部分，要将结束SCN重新设置为无穷大或null。
*******************************************************************************
三、只读表空间的问题
1.alter tablespace tbs1 read only;此信息会存到控制文件中
此表空间的数据文件包括数据文件头中及控制文件中的scn等信息被冻结
2. shutdown immediate;所有read write的数据文件对应scn,rba等更新一致
3.实例启动时仅对在控制文件中标记为read write的表空间做一致性检查
*******************************************************************
近期文章：
欢迎支持我的帖子：:p
IP卡
狗仔卡
发表于 2013-1-30 16:40
收藏
提升卡
置顶卡
变色卡
显身卡
