Oracle体系结构之SCN、实例恢复-白红宇

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

阅读量：6848 次

发布时间：2019-06-26

本文共 8423 字，大约阅读时间需要 28 分钟。

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 PMSQL>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.

实例恢复的详细过程：

前滚阶段(前滚靠redo,又叫缓冲区恢复cache recovery,即负责恢复已经在内存中但还没有写入数据文件中的内容)

Oracle是按照redo log file的记录来前滚的(不管有没有commit),所以前滚完成后,data file中可能会有没有提交的数据(所以需要后面的回退过程).

另外,由于undo的生成也是要记录redo log的,所以还会按照redo重新生成后面回退时需要的undo信息.

数据库open阶段

前滚完毕后,数据库中所有已被修改的数据块已经写入到了数据文件中才可以正常open

回滚阶段(回滚靠undo,又叫事务恢复transaction recoery,即负责回退实例崩溃前没有提交的事务)

正常关闭数据库时：

系统SCN、文件SCN、结束SCN和数据文件头部中的开始SCN都是相等的，且(大于或)等于ACTIVE/CURRENT日志文件中的最小FIRST SCN

SQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL> startup mountORACLE instance started.Total System Global Area  459304960 bytesFixed Size                  2214336 bytesVariable Size             289408576 bytesDatabase Buffers          159383552 bytesRedo Buffers                8298496 bytesDatabase mounted.SQL>  select checkpoint_change# from v$database;CHECKPOINT_CHANGE#------------------           1822573SQL>  select name,checkpoint_change#,last_change# from v$datafile;NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#--------------------------------------------- ------------------ ------------+DATA/orcl/datafile/system.256.817343229                 1822573      1822573+DATA/orcl/datafile/sysaux.257.817343231                 1822573      1822573+DATA/orcl/datafile/undotbs1.258.817343231               1822573      1822573+DATA/orcl/datafile/users.259.817343231                  1822573      1822573+DATA/orcl/datafile/example.265.817343543                1822573      1822573SQL> select name,checkpoint_change# from v$datafile_header;NAME                                          CHECKPOINT_CHANGE#--------------------------------------------- ------------------+DATA/orcl/datafile/system.256.817343229                 1822573+DATA/orcl/datafile/sysaux.257.817343231                 1822573+DATA/orcl/datafile/undotbs1.258.817343231               1822573+DATA/orcl/datafile/users.259.817343231                  1822573+DATA/orcl/datafile/example.265.817343543                1822573SQL> select group#,sequence#,status,first_change#,next_change# from v$log;    GROUP#  SEQUENCE# STATUS           FIRST_CHANGE#       NEXT_CHANGE#---------- ---------- ---------------- ------------- ------------------         1         37 CURRENT                1822207    281474976710655         3         36 INACTIVE               1808596            1822207         2         35 INACTIVE               1770739            1808596

正常open数据库时：

文件结束SCN为NULL(无穷大)

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

异常关机（实例崩溃）时：

文件结束SCN仍为NULL(无穷大)

SQL> shutdown abortORACLE instance shut down.SQL> startup mountORACLE instance started.Total System Global Area  459304960 bytesFixed Size                  2214336 bytesVariable Size             289408576 bytesDatabase Buffers          159383552 bytesRedo Buffers                8298496 bytesDatabase mounted.SQL> select name,checkpoint_change#,last_change# from v$datafile;NAME                                          CHECKPOINT_CHANGE# LAST_CHANGE#--------------------------------------------- ------------------ ------------+DATA/orcl/datafile/system.256.817343229                 1822576+DATA/orcl/datafile/sysaux.257.817343231                 1822576+DATA/orcl/datafile/undotbs1.258.817343231               1822576+DATA/orcl/datafile/users.259.817343231                  1822576+DATA/orcl/datafile/example.265.817343543                1822576

启动实例将进行实例恢复：

SQL> alter database open;Database altered.$ tailf /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.logSun Jul 07 00:10:07 2013alter database openBeginning crash recovery of 1 threads parallel recovery started with 3 processesStarted redo scanCompleted redo scan read 192 KB redo, 87 data blocks need recoveryStarted redo application at Thread 1: logseq 37, block 533Recovery of Online Redo Log: Thread 1 Group 1 Seq 37 Reading mem 0  Mem# 0: +DATA/orcl/onlinelog/group_1.261.817343457  Mem# 1: +FRA/orcl/onlinelog/group_1.257.817343463Completed redo application of 0.15MBCompleted crash recovery at Thread 1: logseq 37, block 918, scn 1843004 87 data blocks read, 87 data blocks written, 192 redo k-bytes readSun Jul 07 00:10:13 2013Thread 1 advanced to log sequence 38 (thread open)Thread 1 opened at log sequence 38  Current log# 2 seq# 38 mem# 0: +DATA/orcl/onlinelog/group_2.262.817343467  Current log# 2 seq# 38 mem# 1: +FRA/orcl/onlinelog/group_2.258.817343473Successful open of redo thread 1Sun Jul 07 00:10:14 2013SMON: enabling cache recoverySuccessfully onlined Undo Tablespace 2.Verifying file header compatibility for 11g tablespace encryption..Verifying 11g file header compatibility for tablespace encryption completedSMON: enabling tx recoveryDatabase Characterset is AL32UTF8No Resource Manager plan activeSun Jul 07 00:10:17 2013replication_dependency_tracking turned off (no async multimaster replication found)Starting background process QMNCSun Jul 07 00:10:21 2013QMNC started with pid=28, OS id=7140Sun Jul 07 00:10:31 2013Completed: alter database open

转载于:https://blog.51cto.com/vnimos/1248546

你可能感兴趣的文章

深度有趣 | 12 一起来动动手

查看>>