SCN是当Oracle数据库更新后，由DBMS自动维护去累积递增的一个数字。当一笔交易commit 时，LGWR会将log buffer写入redo log file，

上次做了下基于scn恢复delete掉的数据后，觉得应该好好理解下scn的知识，今天在网上找了下相关的介绍，参考了某些文章，，在此我通过实验总结一下。

SCN是当Oracle数据库更新后，由DBMS自动维护去累积递增的一个数字。当一笔交易commit 时，LGWR会将log buffer写入redo log file，同时也会将该笔交易的SCN同步写入到redo log file内(wait-until-completed)。因此当你commit transaction时，在交易成功的讯息返回之前，LGWR必须先完整的完成上述行为之后，否则你是看不到提交成功的回应讯息。

那系统是如何产生一个最新的

select dbms_flashback.get_system_change_number, SCN_TO_TIMESTAMP(dbms_flashback

2 .get_system_change_number) from dual;

GET_SYSTEM_CHANGE_NUMBER

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

SCN_TO_TIMESTAMP(DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER)

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

117947354

24-MAR-11 11.32.22.000000000 AM

也可以用函数

SQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;

control中有三种SCN分别为，system SCN、datafile SCN、last SCN，数据文件头中有一种SCN start SCN

system scn从视图v$database中获得，对应checkpoint_change#字段，datafile scn、last scn分别对应视图v$datafile中的checkpoint_change#，last_change#，而 start scn则从v$datafile_header中checkpoint_change#得到。

数据库在正常启动后下，system scn,datafile scn,start scn会相等，而last scn会被置于无穷大，这里为null。

正常关闭后(immediate,noraml,translate)，上面四个scn会应执行full checkpoint 而相等。

当系统在非正常关闭后，如shutdown abort，这个时候last scn依然为无穷大，那么当重新启动实例时，系统首先会比较start scn与system scn，如果一致，那么再比较start scn 与last scan是否一样大，因为是非正常关闭，这里会不一样大，那么就需要例程恢复。

如果打开数据库时发现system scn>datafile scn，那么以为着使用旧的备份数据文件，也就是需要介质恢复

如果是system scn1、正常启动时

SQL> SELECT checkpoint_change# FROM v$database;

CHECKPOINT_CHANGE#

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

117866282

SQL> SELECT file#, checkpoint_change# FROM v$datafile_header;

FILE# CHECKPOINT_CHANGE#

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

1 117866282

2 117866282

3 117866282

4 117866282

5 117866282

6 117866282

7 117866282

8 117866282

9 117866282

10 117866282

11 117866282

FILE# CHECKPOINT_CHANGE#

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

12 117866282

13 117866282

14 117866282

14 rows selected.

SQL> SELECT file#, checkpoint_change#, last_change# FROM v$datafile;

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

1 117866282

2 117866282

3 117866282

4 117866282

5 117866282

6 117866282

7 117866282

8 117866282

9 117866282

10 117866282

11 117866282

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

12 117866282

13 117866282

14 117866282

14 rows selected.

2、正常关闭后，然后在startup mount;

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 835104768 bytes

Fixed Size 2217952 bytes

Variable Size 624953376 bytes

Database Buffers 201326592 bytes

Redo Buffers 6606848 bytes

Database mounted.

SQL> SELECT file#, checkpoint_change# FROM v$datafile_header;

FILE# CHECKPOINT_CHANGE#

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

1 117925094

2 117925094

3 117925094

4 117925094

5 117925094

6 117925094

7 117925094

8 117925094

9 117925094

10 117925094

11 117925094

FILE# CHECKPOINT_CHANGE#

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

12 117925094

13 117925094

14 117925094

14 rows selected.

SQL> SELECT checkpoint_change# FROM v$database;

CHECKPOINT_CHANGE#

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

117925094

SQL> SELECT file#, checkpoint_change#, last_change# FROM v$datafile;

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

1 117925094 117925094

2 117925094 117925094

3 117925094 117925094

4 117925094 117925094

5 117925094 117925094

6 117925094 117925094

7 117925094 117925094

8 117925094 117925094

9 117925094 117925094

10 117925094 117925094

11 117925094 117925094

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

12 117925094 117925094

13 117925094 117925094

14 117925094 117925094

14 rows selected.

--发现start scn=last scn,证明系统是正常关闭

SQL> alter database open;

Database altered.

3、在正常打开状态下进行事务操作

SQL> CREATE TABLE w(a number);

Table created.

SQL> INSERT INTO w VALUES(1);

1 row created.

SQL> commit;

Commit complete.

SQL> INSERT INTO w VALUES(2);

1 row created.

4、非正常关闭

SQL> shutdown abort;

ORACLE instance shut down.

5、打开到mount状态下，观看scn

SQL> startup mount;

ORACLE instance started.

Total System Global Area 835104768 bytes

Fixed Size 2217952 bytes

Variable Size 624953376 bytes

Database Buffers 201326592 bytes

Redo Buffers 6606848 bytes

Database mounted.

SQL> SELECT file#,checkpoint_change#, last_change# FROM v$datafile;

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

1 117925097

2 117925097

3 117925097

4 117925097

5 117925097

6 117925097

7 117925097

8 117925097

9 117925097

10 117925097

11 117925097

FILE# CHECKPOINT_CHANGE# LAST_CHANGE#

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

12 117925097

13 117925097

14 117925097

14 rows selected.

SQL> SELECT checkpoint_change# FROM v$database;

CHECKPOINT_CHANGE#

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

117925097

SQL> SELECT file#,checkpoint_chnge# FROM v$datafile_header;

SELECT file#,checkpoint_chnge# FROM v$datafile_header

*

ERROR at line 1:

ORA-00904: "CHECKPOINT_CHNGE#": invalid identifier

SQL> SELECT file#, checkpoint_change# FROM v$datafile_header;

FILE# CHECKPOINT_CHANGE#

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

1 117925097

2 117925097

3 117925097

4 117925097

5 117925097

6 117925097

7 117925097

8 117925097

9 117925097

10 117925097

11 117925097

FILE# CHECKPOINT_CHANGE#

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

12 117925097

13 117925097

14 117925097

14 rows selected.

--这时发现start scn 与last scn不等，last scn为无穷大，需要例程恢复

6、改变数据库状态为open，并查看该阶段运行日志

SQL> ALTER DATABASE open;

Database altered.

SQL> SELECT * FROM w;

A

----------

1

--发现没有提交的事务丢失。

查看日志如下：

Thu Mar 24 10:47:24 2011

ALTER DATABASE MOUNT

Successful mount of redo thread 1, with mount id 1274403260

Database mounted in Exclusive Mode

Lost write protection disabled

Completed: ALTER DATABASE MOUNT

Thu Mar 24 10:50:12 2011

ALTER DATABASE open

Beginning crash recovery of 1 threads --会自动判断是否需要恢复，这里开始例程恢复

parallel recovery started with 2 processes

Started redo scan

Completed redo scan

read 162 KB redo, 112 data blocks need recovery

Started redo application at

Thread 1: logseq 2635, block 491121

Recovery of Online Redo Log: Thread 1 Group 1 Seq 2635 Reading mem 0 --恢复用的在线重做日志

Mem# 0: /u01/oradata/orcl/redo01a.log

Mem# 1: /u01/oradata/orcl/redo01b.log

Completed redo application of 0.13MB

Completed crash recovery at --恢复完成

Thread 1: logseq 2635, block 491446, scn 117945330

112 data blocks read, 112 data blocks written, 162 redo k-bytes read

Thu Mar 24 10:50:13 2011

LGWR: STARTING ARCH PROCESSES

Thu Mar 24 10:50:13 2011

ARC0 started with pid=22, OS id=31059

ARC0: Archival started

LGWR: STARTING ARCH PROCESSES COMPLETE

ARC0: STARTING ARCH PROCESSES

Thu Mar 24 10:50:14 2011

ARC1 started with pid=23, OS id=31061

Thread 1 advanced to log sequence 2636 (thread open)

Thu Mar 24 10:50:15 2011

ARC2 started with pid=24, OS id=31063

Thread 1 opened at log sequence 2636

Current log# 2 seq# 2636 mem# 0: /u01/oradata/orcl/redo02a.log

本文原创发布php中文网，转载请注明出处，感谢您的尊重！

mysql scn_Oracle scn介绍相关推荐

  1. mysql scn_Oracle scn详解

    如果这两个值相互匹配,oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn.如果这两个值也一致,就意味 前面写过一个scn的基础性的文章,但是不能反映scn的变化和存在情 ...

  2. mysql scn_Oracle scn之基本概念

    Scn的作用主要是保证数据库的一致性.它是oracle的内部时钟机制.Scn是实施对oracle恢复非常重要的机制.Scn在数据库中无处不在, 一.scn的作用 Scn的作用主要是保证数据库的一致性. ...

  3. mysql scn_ORACLE SCN的概念

    SCN的概念 SCN是顺序递增的一个数字,在Oracle中用来标识数据库的每一次改动,及其先后顺序.SCN的最大值是0xffff.ffffffff. 1.系统检查点scn 当一个检查点动作完成之后,O ...

  4. mysql数据库引擎介绍

    mysql数据库引擎介绍 你能用的数据库引擎取决于mysql在安装的时候是如何被编译的.要添加一个新的引擎,就必须重新编译MYSQL.在缺省情况下,MYSQL支持三个引擎:ISAM.MYISAM和HE ...

  5. LAMP架构介绍、MySQL和MariaDB介绍、MySQL安装

    2019独角兽企业重金招聘Python工程师标准>>> LAMP架构介绍 Linux+Apache+MySQL+PHP 就是在linux系统上安装httpd. mysql .PHP, ...

  6. mysql 查询日志介绍

    MySQL查询日志介绍 MySQL的查询日志记录了所有MySQL数据库请求的信息.无论这些请求是否得到了正确的执行.默认文件名为hostname.log.默认情况下MySQL查询日志是关闭的.生产环境 ...

  7. MySQL复制类型介绍

    MySQL复制类型介绍: (1)同步复制:MASTER提交事务,直到事务在所有的Slave都已提交,此时,才会返回给客户端,事务执行完毕. 缺点:完成一个事务可能会有很大的延迟. slave1 MAs ...

  8. MySQL查询日志介绍

    MySQL查询日志介绍 MySQL的查询日志记录了所有MySQL数据库请求的信息.无论这些请求是否得到了正确的执行.默认文件名为hostname.log.默认情况下MySQL查询日志是关闭的.生产环境 ...

  9. MySQL第7天：MySQL的架构介绍之存储引擎

    MySQL的架构介绍之存储引擎 #编写时间:2017.3.9 #编写地点:广州 1.存储引擎相关的命令 //查看已安装的mysql已提供的存储引擎 mysql>show engines;//查看 ...

最新文章

  1. Java Web知识梳理
  2. 门户网站负载均衡技术的六大新挑战
  3. 计算机排版基础知识,计算机排版基础知识.pdf
  4. 找到真爱了-sublime
  5. “error LNK2019: 无法解析的外部符号”的几种可能原因
  6. Activity生命周期方法的调用顺序project与測试日志
  7. 机器学习实战（十四）Pegasos（原始估计子梯度求解器）
  8. linux面试题：删除一个目录下的所有文件，但保留一个指定文件
  9. python代替shell脚本_自动化shell脚本except与python的pexpect模块
  10. Django项目实践2 - Django模板（网页多语种支持/国际化）
  11. Hadoop CentOS 7 安装配置
  12. Powershell进阶学习(1) 浅谈Powershell学习方法
  13. tron区块链php对接,兄弟连区块链入门到精通教程基础开发通过接口查询tron提币情况...
  14. Unity Opencv摄像头实时美颜(二)
  15. c语言编写cad建筑画图程序,CAD建筑平面图绘图步骤试题.doc
  16. 电脑网络看不到其它计算机,解决网络和共享中看不到其他计算机的问题
  17. 一键设置 DeviceAdmin/ProfileOwner/DeviceOwner 应用
  18. 【ATE-SENT协议】使用LabVIEW采集并解析SENT协议
  19. 使用word写论文必备技巧（设置目录，目录导航）
  20. rsync下行同步和inotify实时同步部署

热门文章

  1. 配置计算机共享为免验证,网启局域网全网批量和单一机装系统工具winpe版
  2. Python开发的编译神器PyCharm----测试从业来编写Python脚本最钟意的工具
  3. div阻止点击穿透+实现点击穿透
  4. keil的jlink重新选择芯片识别
  5. msvcp110.dll丢失怎么修复
  6. 放弃高考连续3次创业80后，今天IPO敲钟市值2400亿
  7. python画指数函数图像_python中指数函数的回归线拟合
  8. 11.5 Daily Scrum
  9. [极品收藏]较全的FLASH素材大聚会
  10. 排队论 （queuing theory）推论与举例