oracle 实例恢复原理,实例恢复相关原理精简总结

************************************************************************************************

二、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