深入剖析 - Oracle SCN机制详细解读

SCN可以说是Oracle中一个很基础的部分,但同时它也是一个很重要的。它是系统中维持数据的一致性和顺序恢复的重要标志,是数据库非常重要的一种数据结构。

SCN介绍

SCN即系统改变号(System Change Number),是在某个时间点定义数据库已提交版本的时间戳标记。 Oracle为每个已提交的事务分配一个唯一的SCN。 SCN的值是对数据库进行更改的逻辑时间点。 Oracle使用此编号记录对数据库所做的更改。在数据库中,SCN也可以说是无处不在,数据文件头,控制文件,数据块头,日志文件等等都标记着SCN。也正是这样,数据库的一致性维护和SCN密切相关。不管是数据的备份,恢复都是离不开SCN的。

SCN是一个6字节(48bit)的数字,其值为281,474,976,710,656(2^48),分为2个部分:

SCN_BASE是一个4字节(32bit)的数字 SCN_WRAP是一个2字节(16bit)的数字

每当SCN_BASE达到其最大值(2^32 = 4294967296)时,SCN_WRAP增加1,SCN_BASE将被重置为0,一直持续到SCN_WRAP达到其最大值,即2^16 = 65536。

SCN =(SCN_WRAP * 4294967296)+ SCN_BASE

SCN随着每个事务的完成而增加。提交不会写入数据文件,也不更新控制文件。当发生checkpoint时,控制文件更新,SCN被写入到控制文件。

当前的SCN可以通过以下查询获得:

select dbms_flashback.get_system_change_number scn from dual;

select current_scn from v$database;

四种重要的SCN

在理解这几种SCN之前,我们先看下oracle事务中的数据变化是如何写入数据文件的:

第一步:事务开始; 第二步:在buffer cache中找到需要的数据块,如果没找到,从数据文件中载入buffer cache中; 第三步:事务修改buffer cache的数据块,该数据被标识为“脏数据”,并被写入log buffer中; 第四步:事务提交,LGWR进程将log buffer中的“脏数据”的日志条目写入redo log file中; 第五步:当发生checkpoint,CKPT进程更新所有数据文件的文件头中的信息,DBWn进程则负责将Buffer Cache中的脏数据写入到数据文件中。

经过上述5个步骤,事务中的数据变化最终被写入到数据文件中。但是,一旦在上述中间环节数据库意外宕机了,在重新启动时如何知道哪些数据已经写入数据文件、哪些没有写呢?(同样,在DG、streams中也存在类似疑问:redolog中哪些是上一次同步已经复制过的数据、哪些没有)

SCN机制就能比较完善的解决上述问题。 SCN是一个数字,确切的说是一个只会增加、不会减少的数字。正是它这种只会增加的特性确保了 Oracle知道哪些应该被恢复、哪些应该被复制。

总共有4种SCN

系统检查点(System Checkpoint)SCN 数据文件检查点(Datafile Checkpoint)SCN 结束SCN(Stop SCN) 开始SCN(Start SCN)

(1)System Checkpoint SCN

当checkpoint完成后,ORACLE将System Checkpoint SCN号存放在控制文件中。我们可以通过下面SQL语句查询:

select checkpoint_change# from v$database;

(2)Datafile Checkpoint SCN

当checkpoint完成后,Oracle将Datafile Checkpoint SCN存放在控制文件中。我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt SCN。

select name,checkpoint_change# from v$datafile;

(3)Start SCN

Oracle将StartSCN存放在数据文件头中。这个SCN用于检查数据库启动过程是否需要做media recovery。我们可以通过以下SQL语句查询:

select name,checkpoint_change# from v$datafile_header;

(4)Stop SCN

ORACLE将StopSCN存放在控制文件中。这个SCN号用于检查数据库启动过程是否需要做instance recovery。我们可以通过以下SQL语句查询:

select name,last_change# from v$datafile;

在数据库正常运行的情况下,对可读写的online数据文件,该SCN号为NULL。

SCN与数据库启动

在数据库启动过程中,当System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN都相同时,数据库可以正常启动,不需要做media recovery。三者当中有一个不同时,则需要做media recovery.如果在启动的过程中,End SCN为NULL,则需要做instance recovery。Oracle在启动过程中首先检查是否需要media recovery,然后再检查是否需要instance recovery。

SCN与数据库关闭

如果数据库的正常关闭的话,将会触发一个checkpoint,同时将数据文件的END SCN设置为相应数据文件的Start SCN。当数据库启动时,发现它们是一致的,则不需要做instance recovery。在数据库正常启动后,ORACLE会将END SCN设置为NULL.如果数据库异常关闭的话,则END SCN将为NULL。

Q&A

Q

为什么ORACLE在控制文件中记录System checkpoint SCN 号的同时,还需要为每个数据文件记录DatafileCheckpoint SCN?

A

如果有表空间read only,那么该表空间的所有datafile的start SCN和stop SCN将被冻结,这个时候就跟System Checkpoint SCN不一致,但在库open的时候是不需要做media recovery的,如果没有DatafileCheckpoint SCN就无法判断这些datafile是否是最新的。

可能遇到的SCN问题

首选我们看几个跟SCN有关的概念:

Reasonable SCNLimit(RSL)

RSL = (当前时间 - 1988年1月1日)*24*3600*SCN每秒最大可能增长速率

也就是从1988年1月1日开始,假如SCN按最大速率增长,当天理论上的最大值。

最大增长速率:在11.2.0.2之前是16384,在11.2.0.2及之后版本是32768

在11.2.0.2版本之后由_max_reasonable_scn_rate参数控制

该参数不建议修改。

SCN Headroom

Headroom(天) = (Reasonable SCN Limit -CurrentSCN)/ SCN每秒最大可能增长速率/3600/24

也就是如果SCN按最大速率增长,达到当前理论最大值需要的天数。这个值可以用来判断SCN增长速率是否过快。

那么,SCN Headroom如果获取呢?

参考MOS: Bug 13498243 -"scnhealthcheck.sql" script (文档 ID 13498243.8),打上该BUG的patch之后,将在$ORACLE_HOME/rdbms/admin中增加scnhealthcheck.sql文件,该文件就是用来检查SCN是否正常。

另外还有一篇MOS文档,专门对该脚本的输出做了解释。即Installing, Executing and Interpreting output from the"scnhealthcheck.sql" script (文档 ID 1393363.1)。

执行该脚本,结果如下:

这个结果我们仍然无法得到该数据库的具体SCN Headroom,下面这个SQL是从scnhealthcheck.sql中找到的,可以直接查到SCN Headroom的值(indicator字段)。

Q&A

Q

针对上面的查询结果,是不是意味着过1647天之后,SCN就将达到最大值?

A

不会,因为1647天之后,Current SCN会变大,Reasonable SCN Limit同样也会变大,正常情况下,SCNHeadroon只会变大不会变小。

SCN headroom过小的问题

如果SCN正常增长,达到最大值大约可以用500年,SCN headroom的值也会随着时间的推移慢慢变大,但是可能由于BUG、用特殊手段人为调整、dblink传播导致SCN增长出现异常。但如果出现SCN headroom过小,alert log会出现警告:Warning: The SCN headroom for this database is only NN days!

原因定位:

1. 通过下面这篇文档里提供的脚本,该脚本类似于创建AWR,可以按snap_id对dba_hist_sysstat里的某个stat_name做统计,我们这里的Stat_name选择calls to kcmgas。 How to Extract the Historical Values of aStatistic from the AWR Repository (文档 ID 948272.1) 2. 通过查询V$ARCHIVED_LOG单位时间内scn变化 3. 通过上面两个方式得出的结果分析,如果是非持续突发增长,认为很可能是通过dblink引起; 4. 同时比较awr报告中“callsto kcmgas” 和“user commits”,如果user commits也是高速增长,很可能是自身引起;

kcmgas是Oracle分配scn的函数,在一个空库上做测试,可以看出每分配一次scn,calls to kcmgas的统计增加1,所以calls to kcmgas的量可以作为scn的增长量来分析。

ORA-19706: Invalid SCN错误

[1376995.1]里的介绍,在2012年1月CPU或PSU里增加_external_scn_rejection_threshold_hours参数,11.2.0.2及以后的版本,默认为1天即24小时,其他版本默认为31天即744小时,相当于把拒绝外部SCN连接的阈值调大了,因而更加容易引发ORA-19706错误。该参数对数据库自身产生的SCN递增没有影响。Bug 13554409 - Fix for bug13554409 [ID 13554409.8]的里对该问题也有介绍。

ORA-19706错误:最常见的就是拒绝dblink连接的时候,如A库跟B库通过dblink连接,A的SCN有通过人为调整增大许多,连接B库的时候,Oracle会判断该SCN传播过来之后,如果会导致SCN headroom小于_external_scn_rejection_threshold_hours设置的阈值,则拒绝连接

相关参考:SCN、ORA-19706错误和_external_scn_rejection_threshold_hours参数

如果打完2012年1月CPU或PSU后遇到ORA-19706错误,对于以下这些版本的数据库:

Oracle 10.2.0.5 Oracle 11.1.0.7 Oracle 11.2.0.2 Oracle 11.2.0.3

oracle建议给数据库安装2012年4月发布的PSU,并在安装该PSU的基础上,安装补丁13916709。如果是集群架构,同时给集群软件最新安装PSU。参数_external_scn_rejection_threshold_hours在2012年4月(包含2012年4月)以后发布的PSU/CPU中,11.2.0.2及以后的版本,是1天即24小时,其他版本是31天即744小时。其他版本:先升级到高版本,再按照上面的方法处理。

总结

如果发现SCN有异常,需要及时通过上述方法来打上最新的PSU,同时尽量少用DBLINK,从系统设计角度来讲也是不推荐这种系统间强耦合的设计。

作者介绍

周玉其 云和恩墨技术顾问

8年以上数据库开发、运维经验。思维敏捷,曾在电信、物流行业从事数据库开发、运维工作,擅长PL/SQL开发、性能优化、故障诊断。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-11-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏史上最简单的Spring Cloud教程

Openresty最佳案例 | 第8篇:RBAC介绍、sql和redis模块工具类

RBAC介绍 RBAC(Role-Based Access Control,基于角色的访问控制),用户基于角色的访问权限控制。简单地说,一个用户拥有若干角色,每...

2658
来自专栏乐沙弥的世界

使用 DBMS_REPAIR 修复坏块

       对于Oracle数据块物理损坏的情形,在我们有备份的情况下可以直接使用备份来恢复。对于通过备份恢复,Oracel为我们提供了很多种方式,冷备,基于...

582
来自专栏杨建荣的学习笔记

通过shell脚本模拟MySQL自增列的不一致问题

MySQL的自增列问题其实很有意思,在重启数据库之后,会按照max(id)+1的方式来计算,这样一个看起来有些别扭的实现方式在早期版本就饱受诟病,在MyS...

2844
来自专栏数据和云

Oracle 12c多租户特性详解:从Schema到PDB的变化与隔离

在Oracle Database 12c版本中,一个重要的新特性:插接式数据库(Pluggable Database)被引入进来。在12c之前的版本中,Orac...

30810
来自专栏杨建荣的学习笔记

一个普通数据库用户所能查到的"意料之外"的信息(r2笔记98天)

有时候限于工作环境的情况,大多数开发人员只得到了一个权限收到限制的数据库用户。 可能你都不知道你所拥有的数据库用户都能查到哪些你想象不到的数据库信息,其实你知道...

3288
来自专栏乐沙弥的世界

Oralce OMF 功能详解

OMF,全称是Oracle_Managed Files,即Oracle文件管理,使用OMF可以简化管理员的管理工作,不用指定文件的名字、大小、路径,其名字,大...

582
来自专栏杨建荣的学习笔记

MySQL中如何得到权限信息

最近在做一次MySQL数据迁移的时候,突然发现自己遗漏了一个地方,那就是权限信息没有导出,如果我们使用mysqldump --all-databases...

2935
来自专栏乐沙弥的世界

Oracle 用户、对象权限、系统权限

用户:对数据库的访问,需要以适当用户身份通过验证,并具有相关权限来完成一系列动作

822
来自专栏数据和云

数据恢复:隐含参数_minimum_giga_scn被废弃后如何调SCN

崔华,网名 dbsnake Oracle ACE Director,ACOUG 核心专家 在很多数据恢复的场景中,我们可能需要调节SCN,但是一个重要的隐含参数...

27310
来自专栏蓝天

MySQL中MyISAM引擎与InnoDB引擎性能简单测试

[硬件配置] CPU : AMD2500+ (1.8G) 内存: 1G/现代 硬盘: 80G/IDE [软件配置] OS : Windows XP SP2 S...

532

扫描关注云+社区