|
|
当事务被提交时，该事务的变更的REDO 信息会确保已经存入到联机日志文件。但是事务涉及到的数据块的修改写入数据文件是一个异步的过程。检查点和检查点进程推动这种异步机制的同步过程，而且直接影响了数据库实例恢复有关的行为。本章讨论的中心内容是：数据库自身如何确定什么时候需要恢复、实例恢复的详细内部过程、其他一些相关讨论主题
数据库在“事务”当中发生变化，Oraccle 数据库系统使用系统变更号（System Change Number，简写为SCN）来记录数据库内部的变化。数据库内部的很多事件，以及用户通过SQL 语句对数据库内容进行变化，会让SCN 值增长。
我们知道，当应用程序提交（Commit）某个事务时，先是日志写入进程（LGWR）将Log Buffer 中的该事务的纪录写入到联机重做日志文件成功后，才由Service Process 通知相关的用户进程：你的提交已成功。
检查点出现，将推动检查点时刻前的日志文件中所参考的数据块的修改，已经被DBWR 写入到数据文件中。CKPT进程会纪录该检查点的Checkpoint SCN 的信息到数据文件和控制文件中。从而推动了数据库的一个“同步点”。如果在下一个同步点完成之前，数据库发生失败，在数据库的实例恢复从系统当前检查点开始，运用后面的日志进行实例恢复。
可以看出，检查点的出现，可以让数据库在运行时，“定期”的维护日志文件，数据文件进行状态一致性。有些类似于我们生活中：定期的不同的公司的账目结清，当一个检查点完成后，大家都承认，这个时间之前的一切账目已经结清。
一、Oracle 是如何确定需要恢复的
1、正常运行的数据库的有关检查点信息纪录
在数据库正常OPEN 运行时，当一个检查点完成后，Oracle存储新的System Checkpoint SCN 值
到控制文件中，我们可以通过下面的查询来得到该值。
SQL> select a.CHECKPOINT_CHANGE# from v$database a;
CHECKPOINT_CHANGE#
------------------
2798752785243
SQL> select a.NAME,a.CHECKPOINT_CHANGE# from v$datafile a;
NAME CHECKPOINT_CHANGE#
-------------------------------------------------------------------- ------------------
C:\ORACLE\ORADATA\JACKY\SYSTEM01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\UNDOTBS01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\CWMLITE01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\DRSYS01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\EXAMPLE01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\INDX01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\ODM01 2798752785243
C:\ORACLE\ORADATA\JACKY\TOOLS01.DBF 2798752785243
D:\DATAFILE\USERS01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\XDB01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\BLOCK.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\RMAN.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\TEST01.DBF 2798752785243
13 rows selected
Oracle 也会在每个数据文件的头部存储存储Checkpoint SCN的值，名称叫做Start SCN。主要作用是在数据库Open的时候，用于和控制文件有关信息进行比较，从而确定是否需要做恢复。
SQL> select a.NAME,a.CHECKPOINT_CHANGE# from v$datafile_header a;
NAME CHECKPOINT_CHANGE#
-------------------------------------------------------------------- ------------------
C:\ORACLE\ORADATA\JACKY\SYSTEM01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\UNDOTBS01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\CWMLITE01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\DRSYS01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\EXAMPLE01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\INDX01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\ODM01 2798752785243
C:\ORACLE\ORADATA\JACKY\TOOLS01.DBF 2798752785243
D:\DATAFILE\USERS01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\XDB01.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\BLOCK.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\RMAN.DBF 2798752785243
C:\ORACLE\ORADATA\JACKY\TEST01.DBF 2798752785243
13 rows selected
Oracle 在控制文件为每个数据文件存储Stop SCN 的值，在正常OPEN 的数据库中，该值为一个无穷大，查询时，显示NULL。
SQL> select a.NAME,a.LAST_CHANGE# from v$datafile a;
NAME LAST_CHANGE#
-------------------------------------------------------------------------------- ------------
C:\ORACLE\ORADATA\JACKY\SYSTEM01.DBF
C:\ORACLE\ORADATA\JACKY\UNDOTBS01.DBF
C:\ORACLE\ORADATA\JACKY\CWMLITE01.DBF
C:\ORACLE\ORADATA\JACKY\DRSYS01.DBF
C:\ORACLE\ORADATA\JACKY\EXAMPLE01.DBF
C:\ORACLE\ORADATA\JACKY\INDX01.DBF
C:\ORACLE\ORADATA\JACKY\ODM01.DBF
C:\ORACLE\ORADATA\JACKY\TOOLS01.DBF
D:\DATAFILE\USERS01.DBF
C:\ORACLE\ORADATA\JACKY\XDB01.DBF
C:\ORACLE\ORADATA\JACKY\BLOCK.DBF
C:\ORACLE\ORADATA\JACKY\RMAN.DBF
C:\ORACLE\ORADATA\JACKY\TEST01.DBF
13 rows selected
2、正常关闭的数据库的有关检查点记录信息
当我们正常关闭数据库（Shutdown immediate 或者Shutdown normal），此时会执行一个检查点的过程，该过程会把控制文件中记录的每个数据文件的Stop SCN 进行设置，等于每个数据文件头部的StartSCN。所以，我们以start mount 加载数据库，然后进行上面的查询。得到下图的结果：
正常关闭数据库，在Mount 模式下启动数据库，查询System Checkpoint SCN 和Data File
Checkpoint SCN 以及Start SCN、Stop SCN 变得一致。
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area 135338868 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
2.7988E+12
SQL> select name,checkpoint_change#,last_change# from v$datafile where name like
'%USER%';
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
-------------------------------
D:\DATAFILE\USERS01.DBF 2.7988E+12 2.7988E+12
SQL>
在OPEN 数据库时，Oracle 先检查数据文件头部所记录的Start SCN 和控制文件中所记录的数据文件的Checkpoint SCN 是否一致，如果一致，Oracle 进一步检查Start SCN 和控制文件中记录的数据文件的Stop SCN，如果一致。这表示所有的已经被修改的数据块已经反映到了数据文件中。在是正常关闭数据库的情况。数据库可以正常OPEN，无需作实例恢复，当数据库打开后，控制文件中的Stop SCN 会变为NULL。
SQL> alter database open;
数据库已更改。
SQL> select name,checkpoint_change#,last_change# from v$datafile where name like
'%USER%';
NAME CHECKPOINT_CHANGE# HANGE#
--------------------------------------------------------------------------------
D:\DATAFILE\USERS01.DBF 2.7988E+12
数据库在打开时，对每个数据文件要进行两个比对：
A、控制文件中记录的数据文件的Checkpoint SCN 和 数据文件头部所记录的Start SCN 是否相等；
B、然后检查：控制文件中记录数据文件的Stop SCN 和 数据文件头部所记录的Start SCN 是否相等；
3、实例Crash 后的有关检查点记录信息
SQL> create table test (a number) tablespace test ;
Table created
SQL> insert into test values(1);
1 row inserted
SQL> shutdown abort
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area 135338868 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
2.7988E+12
SQL> select name,checkpoint_change#,last_change# from v$datafile where name like
'%TEST%';
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
------------------ ------------
C:\ORACLE\ORADATA\JACKY\TEST01.DBF 2.7988E+12 NULL
SQL> select name,checkpoint_change# from v$datafile_header where name like'%TEST%';
NAME CHECKPOINT_CHANGE#
------------------
C:\ORACLE\ORADATA\JACKY\TEST01.DBF 2.7988E+12
从上面可以看出控制文件中记录的Stop SCN （查询中的Last_Change#）为无穷大。不等于数据文件头部的Start SCN。这表示：数据库在Crash 关闭时，没有进行Checkpoint和相关过程。实例在Open 之前，需要做实例恢复。
实例恢复由Oracle 实例自动完成。Oracle 依照控制文件记录的数据库的Checkpoint SCN 定位联机重做日志文件中的重做日志位置。从该位置开始应用重做日志一直到Crash 时日志结束点。这中间所有被提交的事务，将会确保写入到数据文件，这个过程叫做前滚过程（Roll Forward）。没有提交的活动事务将从回滚段中恢复过来；在上面的例子中Crash 前，我们插入了一行数据，但是没有被提交。所以，实例恢复后，将查询不到该行数据。
SQL> alter database open;（oracle 实例自动完成）
数据库已更改。
SQL> select * from test;
未选定行
控制文件中记录的数据文件的Checkpoint SCN 和 数据文件头部所记录的Start SCN 始终是相等的。这是因为数据库在经历检查点后，检查点后台进程会同时修改数据库的System
Checkpoint SCN、控制文件中记录的数据文件的Checkpoint SCN、以及数据文件头文件中的Start SCN，设置它们的值为检查点开始的系统变更号SCN。
只有在当数据文件丢失时，我们使用以前的备份的数据文件时，这个比对就不一致，数据文件头部纪录的Start SCN 将会小于控制文件中所记录的该数据文件的Checkpoint SCN。将使用到必要的归档／联机日志文件进行恢复。
4、使用备份的控制文件进行恢复
在正常情况下，数据文件头部所记录的Start SCN 都不会大于控制文件中记录的数据文件的CheckpointSCN 的。我们也许觉得奇怪，控制文件已经记录了Checkpoint SCN，为何还需要纪录System Checkpoint SCN 呢，这主要有下列原因：
A、有时候，数据库的某些表空间处于只读模式，当系统经历检查点，只读表空间的数据文件头部的StartSCN 将不会更新； System Checkpoint SCN 有助于识别这一点。
B、有时候，我们的控制文件丢失了，当我们使用以前备份的控制文件。此时，数据文件头部的Start SCN会大于控制文件的System Checkpoint SCN，这表明使用了备份的控制文件。如果我们使用正常的recoverdatabase 的恢复方法，将会出现错误消息。我们应该使用：recover database using backup controlfile;
二、实例恢复的详细过程
当我们系统掉电，或者通过Shutdown abort 关闭数据后，再重新打开数据库前，系统
会自动进行恢复，这个恢复过程可以分为下列三个阶段
A、前滚过程（Roll Forward）：对于已经提交变更的数据块，如果还没有写入到数据文件，则会利用联机日志文件的有关重做信息，写入到数据文件中。
B、数据库打开：进行完毕前滚过程后，数据库就可以打开，可以接受用户连接访问了。
C、回退(Roll Back) 过程：没有提交的事务将会被回退。
1、redo buffer 的操作
当用户User A 发出数据修改命令： UPDATE emp SET sal=10 WHERE id=1234
数据块被读入DB Buffer 中；相应的回滚段的数据块也被读入到DB Buffer 中，并将数修改前的值信息记录下来，作为前映像； 这样的变化过程会作为REDO 实体记录在Redo Buffer中。
然后，修改DB Buffer 中数据块的值为新值；并在Redo Buffer中生成重做信息。在Redo Buffer 中的重做记录实体主要包含三部分信息：
事务的识别号
修改目标Column 的地址
修改Column 的新值
然后，用户User A 发出提交命令：
Commit
在Redo Buffer 中生成相应的重做信息实体，该信息主要包含三部分：
A、一个标志指示该实体是一个Commit。如果是Rollback 或者是Checkpoint也有相应的标志。
B、时间。
C、当前的SCN 号。
SCN 是System Change Number，用来帮助识别数据库的事务，数据库在事务当中变化，我们可以
认为SCN 是数据库变化的“时钟”。SCN 一般用来标识数据库内事务的开始，事务的提交，回滚，或者是检查点的时间，以及其他数据库内部的事件。
LGWR 进程负责将Log Buffer 中内容写入到联机日志文件中去。触发LGWR 工作的机制有：
用户提交
Redo Buffer 的1/3 写满了
Redo Buffer 中写满1M 内容
超时3 秒
DBWR 写
总之，LGWR是一个极为频繁的工作进程，从而保证事务信息被非常快速，及时地写入到联机日志文件。
当联机日志文件Log 1 写满之后，则发生日志切换到Log 2。在正常的生产数据库上，联机日志文件的组数和大小需要灵活考虑，通常情况下，较好的经验值是让日志切换的发生时间间隙为２０－３０分钟之间。这只是一个建议，某些情况或者某些特别的需求，也有要求日志切换更加频繁或者间隙更长。
2、 数据库恢复的过程
因为系统掉电或者不正常关闭数据库（Shutdown abort），当数据库要重新打开前，系统自动会进行恢复过程。这个恢复过程是首先从读取控制文件的信息开始的。控制文件中记录的Checkpoint RBA (Redo Byte Address) 指向联机日志文件中一个恢复开始点。由于每次操作都在redo log都有记录，所以可以从这个开始点往后的重做信息直到重做信息的结束点每次操作都进行“重演”，也就是恢复。
对于已经提交的事务，事务被“重新提交（Re-Commit)”，这就是前滚的概念。然而，在数据库Crash 前没有提交的事务，当时所引起的数据文件的修改变化。在恢复过程后，数据库打开运行期间，如果有用户访问到这些数据块，才利用以前的“前映像”来重新修改回去。这是未提交的事务的回退过程。
从oracle9i开始，Oracle 改善了恢复过程中“前滚”的操作。这个小的改变提高了实例恢复过程中的效率－－在实例失败后可以更快速的恢复过来。当一次DBWR写过程完成后，LGWR会在Redo Buffer 中记录该次写完成的数据块。
这种新的快速前滚机制分为两个步骤：
A、 先快速选择哪些块的事务需要处理；扫描一次Redo Log, 根据DBWR的写快记录滤去已经写入了数据文件的那些重做实体的处理，这个过程不需要读取数据文件块。速度非常快。
B、 然后对选择的块进行处理；
这个小的改善，显剧减少了恢复过程中去读取和修改数据块的数量。再加上Checkpoint 的同步特性和有关参数控制。让实例Crash后的快速恢复过程的时间是快速的，可控的。 |
|
楼主: zhang41082
IP卡
狗仔卡
发表于 2006-4-24 10:22
显身卡
发表于 2006-4-25 11:26
