首页 > 代码库 > SCN系统变更号以及它和恢复的关系
SCN系统变更号以及它和恢复的关系
一、SCN基础
1、什么是scn？
在oracle数据库中保证数据一致性的方法就是事务。事务是一个逻辑的、原子性的作业单元，通常由一个或多个sql组成，一个事务中的所有sql操作，要么失败全部回滚，要么成功全部提交。数据库的事务最主要的作用就是保证了数据的一致性，每次事务的提交都是将数据库从一种一致性状态带进另外一种一致性状态。
scn在数据库中是一个单一的不断的随着数据库一致性状态的改变而自增的序列。每个scn值代表着数据库运行中的一个一致性的点。
2、SCN概述
2.1、系统检查点scn（systmen checkpoint scn）
存在于控制文件，检查点进程启动、全局范围内，oracle就把系统检查点scn记录到控制文件中。
SQL> select dbid,name,log_mode,checkpoint_change# from v$database;
2.2、文件检查点scn（datafile checkpoint scn）
存在于控制文件，检查点进程启动、全局范围内以及文件级别的检查点（将表空间只读、begin backup或某个文件置为offline），oracle把该检查点记录到控制文件中。
SQL> alter tablespace testtbs04 begin backup;
SQL> select
2 ts.name "表空间名"
3 , df.file# "文件号"
4 , df.checkpoint_change# "检查点"
5 , df.last_change# "终止检查点"
6 , df.name "文件名"
7 from v$tablespace ts,v$datafile df
8 where ts.ts#=df.ts#
9 order by df.file#;
表空间名 文件号 检查点 终止检查点 文件名
------------------------------ ---------- ---------- ---------- ----------------------------------------
SYSTEM 1 745206 /oracle/oradata/boss/system01.dbf
UNDOTBS1 2 745206 /oracle/oradata/boss/undotbs01.dbf
SYSAUX 3 745206 /oracle/oradata/boss/sysaux01.dbf
USERS 4 745206 /oracle/oradata/boss/users01.dbf
EXAMPLE 5 745206 /oracle/oradata/boss/example01.dbf
TESTTBS01 6 745206 /oracle/oradata/boss/testtbs01_01.dbf
TESTTBS01 7 745206 /oracle/oradata/boss/testtbs01_02.dbf
TESTTBS02 8 745206 /oracle/oradata/boss/testtbs02_01.dbf
TESTTBS03 9 652799 652799 /oracle/oradata/boss/testtbs03_01.dbf
TESTTBS04 10 745405 /oracle/oradata/boss/testtbs04_01.dbf
SQL> select file#,name,status,CHECKPOINT_CHANGE#,recover from v$datafile_header;
FILE# NAME STATUS CHECKPOINT_CHANGE# REC
---------- ---------------------------------------- ------- ------------------ ---
1 /oracle/oradata/boss/system01.dbf ONLINE 745206 NO
2 /oracle/oradata/boss/undotbs01.dbf ONLINE 745206 NO
3 /oracle/oradata/boss/sysaux01.dbf ONLINE 745206 NO
4 /oracle/oradata/boss/users01.dbf ONLINE 745206 NO
5 /oracle/oradata/boss/example01.dbf ONLINE 745206 NO
6 /oracle/oradata/boss/testtbs01_01.dbf ONLINE 745206 NO
7 /oracle/oradata/boss/testtbs01_02.dbf ONLINE 745206 NO
8 /oracle/oradata/boss/testtbs02_01.dbf ONLINE 745206 NO
9 /oracle/oradata/boss/testtbs03_01.dbf ONLINE 652799
10 /oracle/oradata/boss/testtbs04_01.dbf ONLINE 745405 NO
2.3、终止scn（stop scn）
保存在控制文件，每个数据文件都有一个终止scn，数据库正常运行中，只要数据文件在线且是可读写的，结束scn为null，否则就存在具体的scn值。
2.4、数据文件头scn（start scn）
保存在数据文件中，系统以及文件级别的检查点
SQL> select file#,name,status,CHECKPOINT_CHANGE#,recover from v$datafile_header;
3、scn的相关概念
3.1、redo log中的high scn和low scn
一个重做日志写满后，会自动切换到下一个重做日志，上一个重做日志的high scn就是下一个重做日志的low scn，current log 的high scn无穷大。
SQL> select recid,sequence#,first_change#,next_change# from v$log_history;
RECID SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 1 707655 707656
2 1 710834 741781
3 2 741781 744120
4 3 744120 745576
SQL> select group#,members,sequence#,archived,status,first_change# from v$log;
GROUP# MEMBERS SEQUENCE# ARC STATUS FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
1 1 2 YES INACTIVE 741781
2 1 3 YES INACTIVE 744120
3 1 4 NO CURRENT 745576
##转储当前重做日志
SQL> alter system dump logfile ‘/oracle/oradata/boss/redo03.log‘;
SQL> alter system switch logfile;
SQL> select group#,members,sequence#,archived,status,first_change# from v$log;
GROUP# MEMBERS SEQUENCE# ARC STATUS FIRST_CHANGE#
---------- ---------- ---------- --- ---------------- -------------
1 1 5 NO CURRENT 747335
2 1 3 YES INACTIVE 744120
3 1 4 YES ACTIVE 745576
过段时间，发生自动系统检查点后
SQL> select
2 ts.name "表空间名"
3 , df.file# "文件号"
4 , df.checkpoint_change# "检查点"
5 , df.last_change# "终止检查点"
6 , df.name "文件名"
7 from v$tablespace ts,v$datafile df
8 where ts.ts#=df.ts#
9 order by df.file#;
表空间名 文件号 检查点 终止检查点 文件名
------------------------------ ---------- ---------- ---------- ----------------------------------------
SYSTEM 1 747335 /oracle/oradata/boss/system01.dbf
UNDOTBS1 2 747335 /oracle/oradata/boss/undotbs01.dbf
SYSAUX 3 747335 /oracle/oradata/boss/sysaux01.dbf
USERS 4 747335 /oracle/oradata/boss/users01.dbf
EXAMPLE 5 747335 /oracle/oradata/boss/example01.dbf
TESTTBS01 6 747335 /oracle/oradata/boss/testtbs01_01.dbf
TESTTBS01 7 747335 /oracle/oradata/boss/testtbs01_02.dbf
TESTTBS02 8 747335 /oracle/oradata/boss/testtbs02_01.dbf
TESTTBS03 9 652799 652799 /oracle/oradata/boss/testtbs03_01.dbf
TESTTBS04 10 747335 /oracle/oradata/boss/testtbs04_01.dbf
SQL> select file#,name,status,CHECKPOINT_CHANGE#,recover from v$datafile_header;
FILE# NAME STATUS CHECKPOINT_CHANGE# REC
---------- ---------------------------------------- ------- ------------------ ---
1 /oracle/oradata/boss/system01.dbf ONLINE 747335 NO
2 /oracle/oradata/boss/undotbs01.dbf ONLINE 747335 NO
3 /oracle/oradata/boss/sysaux01.dbf ONLINE 747335 NO
4 /oracle/oradata/boss/users01.dbf ONLINE 747335 NO
5 /oracle/oradata/boss/example01.dbf ONLINE 747335 NO
6 /oracle/oradata/boss/testtbs01_01.dbf ONLINE 747335 NO
7 /oracle/oradata/boss/testtbs01_02.dbf ONLINE 747335 NO
8 /oracle/oradata/boss/testtbs02_01.dbf ONLINE 747335 NO
9 /oracle/oradata/boss/testtbs03_01.dbf ONLINE 652799
10 /oracle/oradata/boss/testtbs04_01.dbf ONLINE 747335 NO
10 rows selected.
SQL> select dbid,name,log_mode,checkpoint_change# from v$database;
DBID NAME LOG_MODE CHECKPOINT_CHANGE#
---------- ---------------------------------------- ------------ ------------------
1375601832 BOSS ARCHIVELOG 747335
SQL> show parameter user_dump
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
user_dump_dest string /oracle/admin/boss/udump
##获得当前时间 系统scn，如果shutdown abort，恢复的记录为active重做日志到shutdown abort时间点
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
746578
3.3、日志切换或检查点：执行检查点后，在重做日志中标记该检查点队列的尾scn之前的scn无需再做恢复
日志切换不会引起4个检查点的改变，只是在下次执行检查点后，将数据文件头scn、数据文件scn、系统scn都更新为high scn。
执行检查点时，将检查点队列上的所有脏数据写入（已提交和未提交的）写入到数据文件，在重做日志中标记该检查点队列的尾scn之前的scn无需再做恢复，最后将数据文件头scn、数据文件scn、系统scn都更新为当前scn。
3.5、数据库正常启动关闭
数据库正常关闭时，系统会执行一个完全检查点动作，用当前scn更新4个scn，将所有数据文件scn置为数据文件头scn（除了offline和read only的数据文件）。
数据库启动时，oracle先比较启动scn和系统scn，如果启动scn>系统scn，控制文件是旧的，如果启动scn<系统scn，数据文件是旧的，如果启动scn=系统scn，再查看终止scn，如果为nul就进行实例恢复
例如：begin backup引起启动scn和数据文件scn的改变，然后shutdown abort，需要恢复也就证明以上过程
3.6、数据库非正常关闭
数据库非正常关闭（实例崩溃）时，终止scn不会被设置，是null。可以数据库启动到mount状态时，进行查询。数据库open过程中，smon进程执行实例恢复工作，即先进行前滚，再把数据库打开，最后回滚。
3.7、数据文件介质故障
启动scn<系统scn
3.8、控制文件介质故障
启动scn>系统scn。noresetlogs重建控制文件时，控制文件的系统scn来自current log头；resetlogs重建控制文件，控制文件的系统scn来自启动scn（感觉不对）。
3.9、备份时的实例崩溃
begin backup时，实例崩溃