Oracle体系结构之SCN、实例恢复


SCN：System Change Number
SCN是Oracle数据库的一个逻辑的内部时间戳，用以标识数据库在某个确切时刻提交的版本。在事务提交或回滚时，它被赋予一个惟一的标识事务的SCN，用来保证数据库的一致性。
SQL> select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) from dual;
GET_SYSTEM_CHANGE_NUMBER SCN_TO_TIMESTAMP(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER)
------------------------ -------------------------------------------------------
                1819076 06-JUL-13 11.40.12.000000000 PM
SQL>select  current_scn from v$database;
CURRENT_SCN
-----------
    1819065

SCN在数据库中是无处不在的，常见的控制文件、数据文件头部、日志文件等都记录有SCN。
控制文件中
系统检查点SCN(System Checkpoint SCN)

SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
          1809219

文件检查点SCN(Datafile Checkpoint SCN)

文件结束SCN(Stop SCN)

SQL> select name,checkpoint_change#,last_change# from v$datafile;
NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#
--------------------------------------------- ------------------ ------------
+DATA/orcl/datafile/system.256.817343229                1809219
+DATA/orcl/datafile/sysaux.257.817343231                1809219
+DATA/orcl/datafile/undotbs1.258.817343231              1809219
+DATA/orcl/datafile/users.259.817343231                  1809219
+DATA/orcl/datafile/example.265.817343543                1809219

数据文件头部
开始SCN(Start SCN)

SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
          1809219
          1809219
          1809219
          1809219
          1809219

日志文件中
FIRST SCN：redo log file中第一条日志的SCN

NEXT SCN：redo log file中最后一条日志的SCN(即下一个redo log file的第一条日志的SCN)

通常,只有当前的重做日志文件组写满后才发生日志切换,但是可以通过设置参数ARCHIVE_LOG_TARGET控制日志切换的时间间隔,在必要时也可以采用手工强制进行日志切换.
一组redo log file写满后，会自动切换到下一组redo log file。上一组redo log的High SCN就是下一组redo log的Low SCN,且对于Current日志文件的High SCN为无穷大(FFFFFFFF)。
SQL> select group#,sequence#,status,first_change#,next_change# from v$log;
    GROUP#  SEQUENCE# STATUS          FIRST_CHANGE#      NEXT_CHANGE#
---------- ---------- ---------------- ------------- ------------------
        1        34 INACTIVE              1746572            1770739
        2        35 INACTIVE              1770739            1808596
        3        36 CURRENT                1808596    281474976710655

--------------------------------------------------------------------------------

实例崩溃恢复：

在open数据库时,Oracle通过控制文件进行了以下验证：

检查数据文件头部所记录的Start SCN 和控制文件中所记录的System Checkpoint SCN 是否一致,若不同则需要进行介质恢复

检查数据文件头部所记录的Start SCN 和控制文件中记录的Stop SCN是否也一致,若不同则需要进行实例恢复.

如果两个都一致了,说明所有已被修改的数据块已经写入到了数据文件中,才可以正常open,

当数据库open并正常运行期间,系统SCN、文件SCN和数据文件头部的开始SCN都是一致的,且(大于或)等于ACTIVE/CURRENT日志文件的最小FIRST SCN,但文件结束SCN为NULL(无穷大);

当数据库正常关闭时,Oracle通过完全检查点将buffer cache中的所有缓存写到磁盘上,同时根据关闭数据库的时间点更新控制文件中的系统SCN、文件SCN、结束SCN和数据文件头部中的开始SCN,且SCN都是一致的,且LRBA指针指向on disk RBA,否则需要前滚;

当数据库非正常关闭(崩溃/掉电)后启动实例时,Oracle将检测到控制文件中的系统SCN、文件SCN和数据文件头部的开始SCN都是一致的,但是结束SCN为NULL,则在需要参与实例崩溃恢复的redo log file中根据控制文件中记录的LRBA地址(前滚起点)和on disk RBA(前滚终点)地址找出相应的日志项进行实例崩溃恢复,最终才可将数据库open.

Oracle体系结构系列相关文章：

Oracle体系结构之SCN、实例恢复

Oracle体系结构之检查点   

Oracle体系结构之SQL语句的执行过程 

更多详情见请继续阅读下一页的精彩内容：

  • 1
  • 2
  • 下一页

相关内容