SCN系统变更号以及它和恢复的关系

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了SCN系统变更号以及它和恢复的关系，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含9774字，纯文字阅读大概需要14分钟。

内容图文

一、SCN基础 1、什么是scn？ 在oracle数据库中保证数据一致性的方法就是事务。事务是一个逻辑的、原子性的作业单元，通常由一个或多个sql组成，一个事务中的所有sql操作，要么失败全部回滚，要么成功全部提交。数据库的事务最主要的作用就是保证了数据的一致

一、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时，实例崩溃

内容总结

以上是互联网集市为您收集整理的SCN系统变更号以及它和恢复的关系全部内容，希望文章能够帮你解决SCN系统变更号以及它和恢复的关系所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端