DB Link导致SCN Headroom以及2012年1月的CPU或PSU补丁问题研究

Posted on 2024-05-27 20:23 dclogs 阅读(13) 评论(0) 编辑收藏举报

转自：

https://www.cnblogs.com/dc-chen/p/7245290.html

https://www.laoxiong.net/scn-ora-19706-_external_scn_rejection_threshold_hours-parameter.html

https://www.modb.pro/db/4664

https://www.iteye.com/blog/tianmaotalk-2437997

一、基础概念

1、SCN（System Change Number）值是Oracle数据库运行每次变化的一个逻辑点，相当于数据库内部的一个时钟，是个只增不减的数字，广泛应用于数据库的恢复、事务ACID、一致性读以及分布式事务中。

2、SCN的内部存储方式：在Oracle内部，SCN分为两部分存储，分别称之为scn wrap和scn base。实际上SCN长度为48位，即它其实就是一个48位的整数。由于在早些年通常只能处理32位甚至是16位的数据，所以分成了低32位（scn base）和高16位（scn wrap）。那么SCN这个48位长的整数，最大就是2^48（281万亿，281474976710656）

3、Maximum Reasonable SCN：在当前时间点，SCN最大允许达到的SCN值。也称为Reasonable SCN Limit，简称RSL。SCN Headroom即当前时间点SCN以每秒最大的增长速度达到RSL值所需时间，其计算公式为：

（当前时间-1988年1月1日00：00：00）×24×3600×SCN每秒最大的可能增长速度

那么SCN最秒最大可能增长速率是多少呢，这个跟Oracle版本有一定的关系，在11.2.0.2之前是16384（即16K），在11.2.0.2及之后版本是32768（即32K）。在11.2.0.2的版本中有一个隐含参数，_max_reasonable_scn_rate，其默认值就是32768（不建议调整这个值）。如果按16K的最大值，SCN要增长到最大，要超过500年。

4、SCN Headroom：这个是指Maximum Reasonable SCN与当前数据库SCN的差值。在alert中通常是以“天”为单位，这个只是为了容易让人读而已。天数=(Maximum Reasonable SCN-Current SCN)/16384/3600/24。这个值就的意思就是，如果按SCN的每大增长速率，多少天会到达Maximum Reasonable SCN。但实际上即使如此，也不会到达Maximum Reasonable SCN，因为到那时Maximum Reasonable SCN也增大了（越时间增大），要到达Maximum Reasonable SCN，得必须以SCN最大可能速率的2倍才行

5、SCN的异常增长：通常来说，每秒最大允许的16K/32K增长速率已经足够了，但是不排除由于BUG，或者人为调整导致SCN异常增长过大。特别是后者，比如数据库通过特殊手段强制打开，手工把SCN递增得很大。同时Oracle的SCN会通过db link进行传播。如果A库通过db link连接到B库，如果A库的SCN高于B库的SCN，那么B库就会递增SCN到跟A库一样，反之如果A库的SCN低于B库的SCN，那么A库的SCN会递增到跟B库的SCN一样。也就是说，涉及到db link进行操作的多个库，它们会将SCN同步到这些库中的最大的SCN

6、那么，如果是数据库本身操作而不是通过db link同步使得SCN的增长，其增长速率如何判断呢，这个可以通过系统的统计量“calls to kcmgas”和"DEBUG calls to kcmgas"来得到。kcmgas的意思是get and advance SCN，即获取并递增SCN。

7、在两个库通过db link进行分布式事务时，假设B库的SCN值要高于A库的SCN，因此要将B库的SCN增同步到A库，但是如果B库的SCN过高，这样同步到A库之后，使得A库面临Headroom过小的风险，那么A库会拒绝同步SCN，这个时候就会报ORA-19706: Invalid SCN错误。分布式事务，或者说是通过db link的操作就会失败，即使是通过db link的查询操作。这里显然有一个阈值，如果递增SCN使得Headroom过小到什么值时，就会拒绝递增（同步）SCN？目前来看是这样：如果打了2012年1月CPU或PSU补丁，11.2.0.2及以后的版本，是1天即24小时，其他版本是31天即744小时，打了补丁之后可以由隐含参数_external_scn_rejection_threshold_hours来调整。而没有打补丁的情况下，视同此参数设为0，实际最小为1小时。由于Oracle 9.2.0.8没有了最新的补丁集，显示也不会有这个参数，保持默认为1小时。注意这是一个静态参数。所以打了2012年1月CPU或PSU补丁的一个重要变化是增加了_external_scn_rejection_threshold_hours参数，同时使11.2.0.2以下版本的数据库其Headroom的阈值增得较大。这带来的影响就是ORA-19706的错误出现的概率更高。解决的办法将_external_scn_rejection_threshold_hours这个隐含参数设置为较小的值，推荐的值是24，即1天。从_external_scn_rejection_threshold_hours这个参数名的字面意思结合它的作用，可以说这个参数就是”拒绝外部SCN“的阈值。对于数据库自身产生的SCN递增是没有影响的。

8、虽然11.2.0.2及之后的版本，其默认的每秒最大可能SCN增长速率为32K，这使得Maximum Reasonable SCN更大，也就是说其SCN可以增长到更大的值。那也就是可能会使11.2.0.2的库向低版本的数据库进行连接时，不能进行db link连接。或者是11.2.0.2的库不能与16K速率的（比如调整了_max_reasonable_scn_rate参数值）的11.2.0.2的库进行db link连接。

注：

（当前时间-1988年1月1日）得到天数，为方便计算，每月按照31天计算。
SCN每秒最大的可能增长速率跟Oracle版本有一定的关系，在11.2.0.2之前是16384（即16K），在11.2.0.2及之后版本是32768（即32K）。在11.2.0.2及以上的版本中有一个隐含参数_max_reasonable_scn_rate，其默认值就是32768（不建议调整这个值）。根据对各个数据库版本的补丁13498243中自带的scnhealthcheck.sql研究，SCN Headroom计算公式中的最大速率均为定义为16k。
Alert日志中的SCN Headroom剩余天数为此刻达到RSL所需天数，并非真正耗尽数据库SCN的时间，SCN Headroom每一秒都在增长。

二、 研究过程

1、 SCN Headroom过低问题发现

（1） alert日志可能出现以下告警：

1、Warning - High Database SCN: Current SCN value is 0x0b7b.0008e40b, threshold SCN value is 0x0b75.055dc000
If you have not previously reported this warning on this database, please notify Oracle Support so that additional diagnosis can be performed.
2、Warning: The SCN headroom for this database is only NN days!
3、Warning: The SCN headroom for this database is only N hours!
4、WARNING: This patch can not take full effect until this RAC database has been completely shutdown and restarted again.
Oracle recommends that it is done at the earliest convenience.
5、Rejected the attempt to advance SCN over limit by 9374 hours worth to 0x0c00.00000f66, by distributed transaction remote logon, remote DB: REMDB.XX.ORACLE.COM.
Client info : DB logon user ME, machine yy, program sqlplus@yy (TNS V1-V3), and OS user uuu
6、Rejected the attempt to advance SCN over limit by 9375 hours worth to 0x0c00.000003c6, by distributed transaction logon, remote DB: REMDB.XX.ORACLE.COM.
Client info : DB logon user TC, machine xx, program oracle@xx (TNS V1-V3), and OS user xxx 
7、Rejected the attempt to advance SCN over limit by 9374 hours worth to 0x0c00.00000f66, by XXXXX
Client info : DB logon user TC, machine mmm, program sqlplus@mmm (TNS V1-V3), and OS user uuu
Where XXXXX is a string such as:
 ? PL/SQL RPC (remote)
 ? sql exec with curSCN
 ? sql exec with outSCN

（2）通过如下脚本检查当前 SCN 距离 Headroom上限的剩余天数

select
  version,
  to_char(SYSDATE,'YYYY/MM/DD HH24:MI:SS') DATE_TIME,
  ((((
   ((to_number(to_char(sysdate,'YYYY'))-1988)*12*31*24*60*60) +
   ((to_number(to_char(sysdate,'MM'))-1)*31*24*60*60) +
   (((to_number(to_char(sysdate,'DD'))-1))*24*60*60) +
   (to_number(to_char(sysdate,'HH24'))*60*60) +
   (to_number(to_char(sysdate,'MI'))*60) +
   (to_number(to_char(sysdate,'SS')))
   ) * (16*1024)) - dbms_flashback.get_system_change_number)
  / (16*1024*60*60*24) 
  ) indicator    --day
from v$instance;

注：根据scnhealthcheck.sql定义：

当SCN Headroom > 62天则健康状态为A,系统无SCN问题；
当10 < SCN Headroom <= 62天则健康状态为B，系统存在SCN问题，尚不致命；
当SCN Headroom <=10天则健康状态为C，系统存在致命的SCN问题，需立即处理。

（3）问题发生可能原因：

本地数据库自身业务问题导致SCN激增
DB Link传染

数据库之间可以通过dblink来进行数据访问，当通过dblink进行业务提交的时候，由于数据库之间存在不同的SCN，因此，为了让事务一致，Oracle将会以两者之间较大的SCN来进行同步，更新dblink两端的数据库SCN。但是，如果源数据库出现SCN生成率过高的问题，随着业务的不断运行，SCN的异常就会通过dblink传染到其他相关的数据库，而dblink使用的频率越大，这种传染的速度也就越快。如果企业内部存在网状的dblink结构，那么这将很容易将SCN的问题扩大到全网，极端情况下会引起大范围的宕机。

通过以下脚得到数据库的scn headroom变化趋势图,如果 SCN Headroom 的剩余天数的历史变化很突然，那么就说明数据库主要被外部通过DBLINK 传染，导致SCN异常增长。

#查看scn headroom变化趋势（前提是数据库开启归档模式）
set numwidth 17
set pages 1000
alter session set nls_date_format='DD/Mon/YYYY HH24:MI:SS';
SELECT tim, gscn,
  round(rate_per_sec),
  round((chk16kscn - gscn)/24/3600/16/1024,1) "Headroom"
FROM
(
 select tim, gscn, rate_per_sec,
  ((
  ((to_number(to_char(tim,'YYYY'))-1988)*12*31*24*60*60) +
  ((to_number(to_char(tim,'MM'))-1)*31*24*60*60) +
  (((to_number(to_char(tim,'DD'))-1))*24*60*60) +
  (to_number(to_char(tim,'HH24'))*60*60) +
  (to_number(to_char(tim,'MI'))*60) +
  (to_number(to_char(tim,'SS')))
  ) * (16*1024)) chk16kscn
 from
 (
   select FIRST_TIME tim , FIRST_CHANGE# gscn,
          ((NEXT_CHANGE#-FIRST_CHANGE#)/
           ((NEXT_TIME-FIRST_TIME)*24*60*60)) rate_per_sec
     from v$archived_log
    where (next_time > first_time)
 )
)
order by 1,2

对于非归档模式的数据库可以通过以下脚本查询SCN增长速度,通过了解SCN的走势诊断SCN Headroom问题，发现系统中存在的跳变情况则可确认为DB Link传染导致SCN异常。

with t1 as(
select time_dp , 24*60*60*(time_dp - lag(time_dp) over (order by time_dp)) timediff,
  scn - lag(scn) over(order by time_dp) scndiff
from smon_scn_time
)
select time_dp , timediff, scndiff,
       trunc(scndiff/timediff) rate_per_sec
from t1
order by 1
/

2、 建议解决方式

（1）应用ORACLE官方推荐的补丁13498243，调整隐含参数：_external_scn_rejection_threshold_hour（11.2.0.2及以上版本的这个参数默认值是24，其他版本默认值是744，官方建议调整为24小时，以避出现过多的ORA-19706）、

_external_scn_logging_threshold_second（建议为86400，相关的信息会记录到Alert log中。通过这些记录的信息，日后可以查找导致SCN跳变的源头。）、_external_scn_rejection_delta_threshold_minute

这三个参数最大限度保障业务系统正常运行需安装到所有db link操作相关的数据库上，同是将SCN Headroom加入监控指标进行规律监控。

（2）查找SCN传染源数据库并进行隔离通过其他手段使用数据，如使用OGG同步相关数据，减少DB Link使用，避免数据库之间通过DB Link传染高SCN值，传染源数据库打完13498243补丁，可直接在alert日志中找到传染源数据库的相关信息：

Advanced SCN by 2280 minutes worth to 0x0e26.e74b94ff, by distributed transaction end, remote DB: ORCL.
 Client info: DB logon user DB_CX, machine HDDS-FXGLDB, program ORACLE.EXE, and OS user SYSTEM

另外，12cr2可利用新特性监视数据库链接，可确认SCN暴增原因，主要通过这3个视图：DBA_DB_LINKS，DBA_EXTERNAL_SCN_ACTIVITY、DBA_DB_LINK_SOURCES。

通过dbms_tns包的函数resolve_tnsname可以分析判断数据库链接目标主机是否可用，dba_db_link_sources可以获取到存在的数据库链接信息，DBA_EXTERNAL_SCN_ACTIVITY可以记录分布式事务和分布式读在分布式数据库环境中的一致性即来判断SCN是否高速率增长。

执行以下脚本，如无结果，则数据库无SCN高生成率活动，否则，会返回造成SCN高生成率相关信息。

(SELECT RESULT, OPERATION_TIMESTAMP, EXTERNAL_SCN, SCN_ADJUSTMENT, HOST_NAME, DB_NAME, 
SESSION_ID, SESSION_SERIAL#   
    FROM DBA_EXTERNAL_SCN_ACTIVITY a, DBA_DB_LINK_SOURCES s   
    WHERE a.INBOUND_DB_LINK_SOURCE_ID = s.SOURCE_ID) --返回通过DB Link导致SCN增长的远程数据库信息
UNION 
(SELECT RESULT, OPERATION_TIMESTAMP, EXTERNAL_SCN, SCN_ADJUSTMENT, 
dbms_tns.resolve_tnsname(HOST) HOST_NAME, NULL DB_NAME, SESSION_ID, 
SESSION_SERIAL#   
    FROM DBA_EXTERNAL_SCN_ACTIVITY a, DBA_DB_LINKS o, DBA_DB_LINK_SOURCES s 
    WHERE a.OUTBOUND_DB_LINK_NAME = s.SOURCE_ID AND  
OUTBOUND_DB_LINK_OWNER = o.OWNER) --返回通过DB Link导致SCN增长的远程数据库信息
UNION 
(SELECT RESULT, OPERATION_TIMESTAMP, EXTERNAL_SCN,   SCN_ADJUSTMENT,  
s.MACHINE HOST_NAME, NULL DB_NAME, SESSION_ID, SESSION_SERIAL#   
    FROM DBA_EXTERNAL_SCN_ACTIVITY a, V$SESSION s
    WHERE a.SESSION_ID = s.SID AND           
        a.SESSION_SERIAL#=s.SERIAL# AND
        INBOUND_DB_LINK_SOURCE_ID IS NULL AND
        OUTBOUND_DB_LINK_NAME IS NULL AND
        OUTBOUND_DB_LINK_OWNER IS NULL); --返回通过用户连接导致SCN增长的相关信息
--脚本源自《Oracle® Database Administrator’s Guide 12c Release 2 (12.2)》32.5.5 Determining the Source of High SCN Activity for Incoming Database Links
--《Oracle® Database Administrator’s Guide 12c Release 2 (12.2)》4.242 DBA_EXTERNAL_SCN_ACTIVITY
--尚未进行相关验证

三、总结

1. 在全系统内做SCN生成率的普查，看看各系统的SCN生成情况是否牵涉生成率过高的现象；

2. 发现SCN生成率过高的相关数据库，及时进行修正处理；

3. 形成日常检查机制，每半月或者每月运行scnhealthcheck.sql，例行检查SCN的生成率情况；

4. 根据相关数据库的dblink使用情况，形成dblink跟踪列表，便于日后检查SCN状态。列表内容包括源数据库名称、目标数据库名称、dblink名称、dblink用途，甚至包括关联对象等信息，

5. 目前的Oracle官方并没有给出完全解决SCN headroom过低问题，只能通过设置相关隐含参数最大限度保障业务系统的正常运行，隔离高SCN值数据库通过DB link传染，极端情况下还需关闭数据库等待SCN headroom增长。

四、 相关SQL脚本附录

#隐含参数查询

select name
    ,value
    ,decode(isdefault, 'TRUE','Y','N') as "Default"
    ,decode(ISEM,'TRUE','Y','N') as SesMod
    ,decode(ISYM,'IMMEDIATE', 'I','DEFERRED', 'D','FALSE', 'N') as SysMod
    ,decode(IMOD,'MODIFIED','U','SYS_MODIFIED','S','N') as Modified
    ,decode(IADJ,'TRUE','Y','N') as Adjusted
    ,description
    from ( --GV$SYSTEM_PARAMETER
        select x.inst_id as instance           
            ,x.indx+1
            ,ksppinm as name
            ,ksppity
            ,ksppstvl as value
            ,ksppstdf as isdefault
            ,decode(bitand(ksppiflg/256,1),1,'TRUE','FALSE') as ISEM
            ,decode(bitand(ksppiflg/65536,3),1,'IMMEDIATE',2,'DEFERRED','FALSE') as ISYM
            ,decode(bitand(ksppstvf,7),1,'MODIFIED','FALSE') as IMOD
            ,decode(bitand(ksppstvf,2),2,'TRUE','FALSE') as IADJ
            ,ksppdesc as description
        from x$ksppi x,x$ksppsv y
    where x.indx = y.indx
    and substr(ksppinm,1,1) = '_'
    and x.inst_id = USERENV('Instance')
)
where name like '%&par%'
order by name
/

&par:_external_scn_rejection_threshold_hour

五、参考资料

System Change Number (SCN), Headroom, Security and Patch Information (文档 ID 1376995.1)

Installing, Executing and Interpreting output from the "scnhealthcheck.sql" script (文档 ID 1393363.1)

ORA-19706 and Related Alert Log Messages (文档 ID 1393360.1)

How to Extract the Historical Values of a Statistic from the AWR Repository (文档 ID 948272.1)

六、相关回答

1. 不升级/不打补丁现有DB Link或数据库就必然会有问题吗？

不是！系统SCN的变化是基于系统的繁忙情况，事务的多少和DBLINK的同步，在打上该补丁后，系统SCN的变化速度并不改变，只是允许系统上支持更繁忙事务和当前SCN允许更大的值，这样在通过DBLINK同步到其他低SCN又未打补丁的系统上时，才会有可能造成DB link访问拒绝或其它未知问题。

2. 升级/打补丁之后DB Link因SCN拒绝或SCN headroom问题就不存在了么？

不是。该补丁本质只是增大了SCN增长速度和上限限制，如果某系统上依然存在bug或其他原因导致SCN的异常增长，即使是所有系统都打上了该补丁，DB Link间的SCN同步依然会发生，同样会将SCN的异常传播到整个DB Link网络，SCN Headroom问题依然存在。

3. 对于10.2 版本以及更早版本影响

如果不存在SCN headroom问题和也不存在DB Link 指向已安装补丁的数据库，可以不做任何改变；

2019年6月之后，如果老版本数据库和已安装了补丁并使用了新的SCN兼容性的数据库存在DB Link，如果已安装补丁数据库SCN 使用速度没有变化（虽然已允许更快的速率），老版本的DB Link仍可以正常访问；如果DB Link 另一端已安装补丁的数据库SCN 增长超过了16K, 可能就会因为DB Link 同步老版本的数据库SCN导致SCN headroom问题甚至拒绝链接，并且那时需要断开这些DB Link连接或升级。Oracle研发目前正在评估为10.2.0.5提供补丁的需求和可行性。

4. 对于11.2.0.4,12.1.0.2和12.2.0.1版本数据库需要做什么？

什么都不用做，所有需要的修补程序已包含在这些版本中，但是并不是SCN就不会有SCN headroom问题，只是概率非常低，很少有数据库事务率会使用SCN每秒增长超过90多K。

5. 未安装补丁的数据库DBLINK间是否会有问题？

不会，两个未修复的数据库或两个旧版本的数据库之间，如10204,9i的版本数据DB Link连接不受此更改的影响。

6. 应该优先处理什么样的系统？

综上，我们应该优先处理环境中目前是否存在SCN增长过快的系统和SCN headroom天数较小的系统。建议检查目前环境中的所有数据库的SCN值和headroom是否都大于30天。

如何查看具体的DBLINK信息？

所有的数据库版本可以使用DBA_DB_LINKS视图查看现在数据库中存在的DB Link。
对于12.1以后的数据库可以查询dba_db_link_sources视图查看。
从12.2 版本起数据库提供了DBA_EXTERNAL_SCN_ACTIVITY 视图可以排查SCN 的跳跃信息，更新信息查看MOS note ID 2171090.1。

七、2012年1月后发布的CPU或PSU补丁到底使数据库在SCN处理方面产生了什么样的变化

答案是：增加了_external_scn_rejection_threshold_hours参数，11.2.0.2及以上版本的这个参数默认值是24，其他版本默认值是744。这样使11.2.0.2以下版本的数据库其Headroom的阈值增得较大。
这种变化对数据库有什么危害吗？答案是：在一个具有很多系统的大型企业环境里面，db link使用很多，甚至有一些不容易管控到的数据库也在跟关键系统通过 db link进行连接，在这样的环境中，过高的SCN扩散到关键系统，而系统如果打了这个补丁，其Headroom阈值变大，那么就更容易出现ORA-19706错误，对db link依赖很严重的系统可能会导致业务系统问题，严重情况下甚至会宕库。不过通过设置隐含参数_external_scn_rejection_threshold_hours可解决这样的问题。所以，如果你安装了2012年1月的CPU或PSU补丁，请尽快设置此参数为建议的值24，极端情况下你可以设置为1。。
alert中的那些提示或警告信息是BUG引起的吗？答案是：这些提示或警告不是BUG引起的。它只是提醒你注意SCN过高增长，或者是你的Headroom较小（在Headroom小于62天时可能会提醒），引起你的重视。实际上根据MOS文档《System Change Number (SCN), Headroom, Security and Patch Information [ID 1376995.1]》的说法，这个补丁修复了SCN相关的一些BUG。如果非要说BUG，可以勉强认为补丁安装后新增的参数_external_scn_rejection_threshold_hours其默认值过大。Bug 13554409 - Fix for bug 13554409 [ID 13554409.8]就是说的这个问题。不过这个问题已经在2012年4月的CPU或PSU补丁中得到修复

在最后我们来解读一下alert日志中的一些信息：

信息：
Wed May 30 15:09:53 2012
Completed crash recovery at
Thread 1: logseq 3059, block 19516, scn 12754630269552
2120 data blocks read, 2120 data blocks written, 19513 redo blocks read
.....
Wed May 30 15:09:57 2012
Advanced SCN by 68093 minutes worth to 0x0ba9.4111a520, by distributed transaction remote logon, remote DB:xxxx.
Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J001), and OS user oracle
这里是说，SCN向前（跳跃）递增了68098分钟，其递增后的SCN是0x0ba9.4111a520。注意这里的分钟的计算就是根据SCN每秒最大可能增长速率为16K来的。我们计算一下：
0x0ba94111a520转换成10进制12821569053984。
在alert日志中，这个信息是刚打开数据库的时候，所以 crash recovery完成时的scn可以做为近似的当前SCN，其值为12754630269552：
(12821569053984-12754630269552)/16384/60=68093.65278320313
这里16384值的是SCN每秒最大可能增长速率，可以看到计算结果极为接近。
我们再来计算一下这个SCN的headroom是多少:
```
SQL>    select
      ((((
       ((to_number(to_char(cur_date,'YYYY'))-1988)*12*31*24*60*60) +
       ((to_number(to_char(cur_date,'MM'))-1)*31*24*60*60) +
       (((to_number(to_char(cur_date,'DD'))-1))*24*60*60) +
       (to_number(to_char(cur_date,'HH24'))*60*60) +
       (to_number(to_char(cur_date,'MI'))*60) +
       (to_number(to_char(cur_date,'SS')))
       ) * (16*1024)) - 12821569053984)
      / (16*1024*60*60*24)
      ) headroom
      from (select to_date('2012-05-30 15:09:57','yyyy-mm-dd hh24:mi:ss') cur_date from dual);

  HEADROOM
----------
24.1496113
```
可以看到结果为24天，由于这个时候_external_scn_rejection_threshold_hours参数值为24，即1天，所以虽然有这么大的跳跃，但SCN仍然增长成功。
信息：
Wed May 30 12:02:00 2012
Rejected the attempt to advance SCN over limit by 166 hours worth to 0x0ba9.3caec689, by distributed transaction remote logon, remote DB: xxxx.
Client info : DB logon user xxxx, machine xxxx, program oracle@xxxx (J000), and OS user oracle
在这个信息中，拒绝了db link引起的SCN增加。计算一下这个SCN的headroom：
0x0ba93caec689转换成10进制是12821495465609
当前时间是2012-05-30 12:02:00，
```
SQL>    select
      ((((
       ((to_number(to_char(cur_date,'YYYY'))-1988)*12*31*24*60*60) +
       ((to_number(to_char(cur_date,'MM'))-1)*31*24*60*60) +
       (((to_number(to_char(cur_date,'DD'))-1))*24*60*60) +
       (to_number(to_char(cur_date,'HH24'))*60*60) +
       (to_number(to_char(cur_date,'MI'))*60) +
       (to_number(to_char(cur_date,'SS')))
       ) * (16*1024)) - 12821495465609)
      / (16*1024*60*60*24)
      ) headroom
      from (select to_date('2012-05-30 12:02:00','yyyy-mm-dd hh24:mi:ss') cur_date from dual);

  HEADROOM
----------
24.0710752
```
由于这个时候_external_scn_rejection_threshold_hours参数值为744，即31天，计算出的headroom在这个阈值之内，因此拒绝增加SCN。
(31-24.0710752)*24=166.2941952，正好是166小时。

实际上2012年1月的CPU或PSU补丁之后还会有下面的变化：

_minimum_giga_scn这个隐含没有了，可惜了这个手工增加SCN的利器。
11.2.0.2及之后的版本，从原来的32K SCN最大速率调整回了16K速率。可以用下面的SQL来得到结果：
```
SQL&gt select decode(bitand(DI2FLAG,65536),65536,'Y','N') using16 
  2   from x$kccdi2;

U
-
Y
```
上面的SQL的结果只有在11.2.0.2及以上版本才有意义，结果为Y，表示使用的是16K的速率，否则是使用32K速率。

本文涉及的一些参数，和SCN的一些算法，可能会随着版本或补丁的变化而产生较大的变化。

important update: 实际上在Jan 2012的PSU/CPU补丁中存在较大的SCN BUG，目前已经不建议打这个补丁集，而是打到更高的PSU补丁集上。

会员力量，点亮园子希望

刷新页面返回顶部

DBA学习之路

导航

公告