知乎免费阅读网站,宿州网站制作公司,建设培训网站,wordpress the7 建站SCN可以说是Oracle中一个很基础的部分#xff0c;但同时它也是一个很重要的。它是系统中维持数据的一致性和顺序恢复的重要标志#xff0c;是数据库非常重要的一种数据结构。
转载#xff1a;深入剖析 - Oracle SCN机制详细解读 - 知乎 (zhihu.com)https://zhuanlan.zhihu.…SCN可以说是Oracle中一个很基础的部分但同时它也是一个很重要的。它是系统中维持数据的一致性和顺序恢复的重要标志是数据库非常重要的一种数据结构。
转载深入剖析 - Oracle SCN机制详细解读 - 知乎 (zhihu.com)https://zhuanlan.zhihu.com/p/31446957
SCN介绍
SCN即系统改变号System Change Number是在某个时间点定义数据库已提交版本的时间戳标记。 Oracle为每个已提交的事务分配一个唯一的SCN。 SCN的值是对数据库进行更改的逻辑时间点。 Oracle使用此编号记录对数据库所做的更改。在数据库中SCN也可以说是无处不在数据文件头控制文件数据块头日志文件等等都标记着SCN。也正是这样数据库的一致性维护和SCN密切相关。不管是数据的备份恢复都是离不开SCN的。 SCN是一个6字节48bit的数字其值为281,474,976,710,6562^48分为2个部分 SCN_BASE是一个4字节32bit的数字 SCN_WRAP是一个2字节16bit的数字 每当SCN_BASE达到其最大值2^32 4294967296时SCN_WRAP增加1SCN_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中 第五步当发生checkpointCKPT进程更新所有数据文件的文件头中的信息DBWn进程则负责将Buffer Cache中的脏数据写入到数据文件中。 经过上述5个步骤事务中的数据变化最终被写入到数据文件中。但是一旦在上述中间环节数据库意外宕机了在重新启动时如何知道哪些数据已经写入数据文件、哪些没有写呢同样在DG、streams中也存在类似疑问redolog中哪些是上一次同步已经复制过的数据、哪些没有 SCN机制就能比较完善的解决上述问题。 SCN是一个数字确切的说是一个只会增加、不会减少的数字。正是它这种只会增加的特性确保了 Oracle知道哪些应该被恢复、哪些应该被复制。 总共有4种SCN
系统检查点System CheckpointSCN 数据文件检查点Datafile CheckpointSCN 结束SCNStop SCN 开始SCNStart SCN 1System Checkpoint SCN
当checkpoint完成后ORACLE将System Checkpoint SCN号存放在控制文件中。我们可以通过下面SQL语句查询
select checkpoint_change# from v$database; 2Datafile Checkpoint SCN
当checkpoint完成后Oracle将Datafile Checkpoint SCN存放在控制文件中。我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt SCN。
select name,checkpoint_change# from v$datafile; 3Start SCN
Oracle将StartSCN存放在数据文件头中。这个SCN用于检查数据库启动过程是否需要做media recovery。我们可以通过以下SQL语句查询
select name,checkpoint_change# from v$datafile_header; 4Stop 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。 QA
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 SCNLimitRSL 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 thescnhealthcheck.sql script (文档 ID 1393363.1)。 执行该脚本结果如下 这个结果我们仍然无法得到该数据库的具体SCN Headroom下面这个SQL是从scnhealthcheck.sql中找到的可以直接查到SCN Headroom的值indicator字段。 QA
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的函数在一个空库上做测试可以看出每分配一次scncalls 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从系统设计角度来讲也是不推荐这种系统间强耦合的设计。
