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

SCN：System Change Number

SCN是Oracle数据库的一个逻辑的内部时间戳，用以标识数据库在某个确切时刻提交的版本。在事务提交或回滚时，它被赋予一个惟一的标识事务的SCN，用来保证数据库的一致性。

<code>SQL> </code><code>select</code> <code>dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) </code><code>from</code> <code>dual;</code>

<code>GET_SYSTEM_CHANGE_NUMBER SCN_TO_TIMESTAMP(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER)</code>

<code>SQL></code><code>select</code> <code>current_scn </code><code>from</code> <code>v$</code><code>database</code><code>;</code>

<code>CURRENT_SCN</code>

SCN在数据库中是无处不在的，常见的控制文件、数据文件头部、日志文件等都记录有SCN。

控制文件中

系统检查点SCN(System Checkpoint SCN)

<code>SQL> </code><code>select</code> <code>checkpoint_change# </code><code>from</code> <code>v$</code><code>database</code><code>;</code>

<code>CHECKPOINT_CHANGE#</code>

文件检查点SCN(Datafile Checkpoint SCN)

文件结束SCN(Stop SCN)

<code>SQL> </code><code>select</code> <code>name</code><code>,checkpoint_change#,last_change# </code><code>from</code> <code>v$datafile;</code>

<code>NAME</code> <code>CHECKPOINT_CHANGE# LAST_CHANGE#</code>

<code>+DATA/orcl/datafile/system.256.817343229 1809219</code>

<code>+DATA/orcl/datafile/sysaux.257.817343231 1809219</code>

<code>+DATA/orcl/datafile/undotbs1.258.817343231 1809219</code>

<code>+DATA/orcl/datafile/users.259.817343231 1809219</code>

<code>+DATA/orcl/datafile/example.265.817343543 1809219</code>

数据文件头部

开始SCN(Start SCN)

<code>SQL> </code><code>select</code> <code>checkpoint_change# </code><code>from</code> <code>v$datafile_header;</code>

日志文件中

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)。

<code>SQL> </code><code>select</code> <code>group</code><code>#,</code><code>sequence</code><code>#,status,first_change#,next_change# </code><code>from</code> <code>v$log;</code>

<code> </code><code>GROUP</code><code># </code><code>SEQUENCE</code><code># STATUS FIRST_CHANGE# NEXT_CHANGE#</code>

<code> </code><code>1 34 INACTIVE 1746572 1770739</code>

<code> </code><code>2 35 INACTIVE 1770739 1808596</code>

<code> </code><code>3 36 </code><code>CURRENT</code> <code>1808596 281474976710655</code>

实例崩溃恢复：

在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

<code>SQL> shutdown immediate</code>

<code>Database</code> <code>closed.</code>

<code>Database</code> <code>dismounted.</code>

<code>ORACLE instance shut down.</code>

<code>SQL> startup mount</code>

<code>ORACLE instance started.</code>

<code>Total System </code><code>Global</code> <code>Area 459304960 bytes</code>

<code>Fixed </code><code>Size</code> <code>2214336 bytes</code>

<code>Variable </code><code>Size</code> <code>289408576 bytes</code>

<code>Database</code> <code>Buffers 159383552 bytes</code>

<code>Redo Buffers 8298496 bytes</code>

<code>Database</code> <code>mounted.</code>

<code>SQL> </code><code>select</code> <code>checkpoint_change# </code><code>from</code> <code>v$</code><code>database</code><code>;</code>

<code>SQL> </code><code>select</code> <code>name</code><code>,checkpoint_change#,last_change# </code><code>from</code> <code>v$datafile;</code>

<code>+DATA/orcl/datafile/system.256.817343229 1822573 1822573</code>

<code>+DATA/orcl/datafile/sysaux.257.817343231 1822573 1822573</code>

<code>+DATA/orcl/datafile/undotbs1.258.817343231 1822573 1822573</code>

<code>+DATA/orcl/datafile/users.259.817343231 1822573 1822573</code>

<code>+DATA/orcl/datafile/example.265.817343543 1822573 1822573</code>

<code>SQL> </code><code>select</code> <code>name</code><code>,checkpoint_change# </code><code>from</code> <code>v$datafile_header;</code>

<code>NAME</code> <code>CHECKPOINT_CHANGE#</code>

<code>+DATA/orcl/datafile/system.256.817343229 1822573</code>

<code>+DATA/orcl/datafile/sysaux.257.817343231 1822573</code>

<code>+DATA/orcl/datafile/undotbs1.258.817343231 1822573</code>

<code>+DATA/orcl/datafile/users.259.817343231 1822573</code>

<code>+DATA/orcl/datafile/example.265.817343543 1822573</code>

<code> </code><code>1 37 </code><code>CURRENT</code> <code>1822207 281474976710655</code>

<code> </code><code>3 36 INACTIVE 1808596 1822207</code>

正常open数据库时：

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

<code>SQL> </code><code>alter</code> <code>database</code> <code>open</code><code>;</code>

<code>Database</code> <code>altered.</code>

<code>+DATA/orcl/datafile/system.256.817343229 1822576</code>

<code>+DATA/orcl/datafile/sysaux.257.817343231 1822576</code>

<code>+DATA/orcl/datafile/undotbs1.258.817343231 1822576</code>

<code>+DATA/orcl/datafile/users.259.817343231 1822576</code>

<code>+DATA/orcl/datafile/example.265.817343543 1822576</code>

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

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

<code>SQL> shutdown abort</code>

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

<code>$ tailf /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log</code>

<code>alter</code> <code>database</code> <code>open</code>

<code>Beginning crash recovery </code><code>of</code> <code>1 threads</code>

<code> </code><code>parallel recovery started </code><code>with</code> <code>3 processes</code>

<code>Started redo scan</code>

<code>Completed redo scan</code>

<code> </code><code>read</code> <code>192 KB redo, 87 data blocks need recovery</code>

<code>Started redo application </code><code>at</code>

<code> </code><code>Thread 1: logseq 37, block 533</code>

<code>Recovery </code><code>of</code> <code>Online Redo Log: Thread 1 </code><code>Group</code> <code>1 Seq 37 Reading mem 0</code>

<code> </code><code>Mem# 0: +DATA/orcl/onlinelog/group_1.261.817343457</code>

<code> </code><code>Mem# 1: +FRA/orcl/onlinelog/group_1.257.817343463</code>

<code>Completed redo application </code><code>of</code> <code>0.15MB</code>

<code>Completed crash recovery </code><code>at</code>

<code> </code><code>Thread 1: logseq 37, block 918, scn 1843004</code>

<code> </code><code>87 data blocks </code><code>read</code><code>, 87 data blocks written, 192 redo k-bytes </code><code>read</code>

<code>Thread 1 advanced </code><code>to</code> <code>log </code><code>sequence</code> <code>38 (thread </code><code>open</code><code>)</code>

<code>Thread 1 opened </code><code>at</code> <code>log </code><code>sequence</code> <code>38</code>

<code> </code><code>Current</code> <code>log# 2 seq# 38 mem# 0: +DATA/orcl/onlinelog/group_2.262.817343467</code>

<code> </code><code>Current</code> <code>log# 2 seq# 38 mem# 1: +FRA/orcl/onlinelog/group_2.258.817343473</code>

<code>Successful </code><code>open</code> <code>of</code> <code>redo thread 1</code>

<code>SMON: enabling cache recovery</code>

<code>Successfully onlined Undo Tablespace 2.</code>

<code>Verifying file header compatibility </code><code>for</code> <code>11g tablespace encryption..</code>

<code>Verifying 11g file header compatibility </code><code>for</code> <code>tablespace encryption completed</code>

<code>SMON: enabling tx recovery</code>

<code>Database</code> <code>Characterset </code><code>is</code> <code>AL32UTF8</code>

<code>No</code> <code>Resource Manager plan active</code>

<code>replication_dependency_tracking turned </code><code>off</code> <code>(</code><code>no</code> <code>async multimaster replication found)</code>

<code>Starting background process QMNC</code>

<code>QMNC started </code><code>with</code> <code>pid=28, OS id=7140</code>

<code>Completed: </code><code>alter</code> <code>database</code> <code>open</code>

本文转自Vnimos51CTO博客，原文链接：http://blog.51cto.com/vnimos/1248546，如需转载请自行联系原作者

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

继续阅读

报错：'mysql' 不是内部或外部命令，也不是可运行的程序或批处理文件。

Linxu常用命令技巧汇总

ERROR 1 (HY000): Can't create/write to file '/tmp/#sql_4188_1.MYI' (Errcode: 28)

艰难安装LDAP,SSL认证

《Linux命令行与Shell脚本编程大全第2版.布卢姆》pdf

MySQL的4种隔离级别？出现问题

XX系统实施过程问题总结

无组件上传图片到数据库中，最完整解决方案

【MySQL数据库】数据库索引事务1.索引2.事务

neo4j之cypher使用文档

NOSQL安全攻击

mybatis_入门程序Mybatis入门

登录plsql 报错 the account is locked --用户被锁

sqlServer根据经纬查距离

SequoiaDB巨杉数据库C++驱动概述

Oracle 批量查询传入List 返回List