`

转:scn问题详解

 
阅读更多

ORACLE SCN问题详解(1)--基础概念详解

  

一:SCN问题产生的背景

    11月15日ORACLE数据库出现故障后,对数据库进行了重新启动,发现alter.log日志告警,详细信息如下:

    
    说明:首先出现此问题就是我们所说的天花板问题,此处的27并不是说数据库只能用27天了,该值是不断变化的,而且该告警也只有重启数据库后才会出现,因此发现此问题不要扩大声势的向领导反馈说数据库急需打SCN补丁,不然会搞的自己很被动,因为在实际生产库中往往各库之间存在dblink,而此问题可以通过dblink同步传播。

二:Headroom的值如何理解?

    查看数据库Headroom历史变化值发现,Headroom由最小的8天变为33天,有时甚至值是45天,既然scn增长是不可逆向的Headroom应该越来越小才对,为什么变大了?

    注意:SCN距离当前的最大SCN限制还有大约27天*24小时*60分*60秒*16384。注意这个当前最大SCN限制是变化的。它每一秒钟增大16384。因此,这个告警并不是说27日之后就不可用了。比如,如果您的数据库SCN每秒前进少于16384,那您可能观察到这个27天变成28天,29天...,换句话说,因此scn问题导致数据库宕机等待一段时间重启,数据库有可能恢复,只不过等待时间长短不好确定,但不是网上流传的必须重建数据库,数据库scn和Headroom的值都随着时间在增长,如果查询Headroom的历史值在不断增大,说明数据库在逐渐走向健康状态,

三:如何查询Headroom历史值的变化

    1、通过如下脚本检查当前 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

    FROM V$INSTANCE;

四:该问题的影响:

     Oracle SCN的合理生成频率大约为16K/秒,如果该SCN超过合理值范围的话,数据库将会cancel该事务并伴随报错信息。当下一秒,应用再连接的时候,由于SCN的值已经处于合理范围内,业务可以继续执行,对前端应用来看,就好像有个短暂停顿。但是在极端情况下,数据库可能需要需要不得已关闭来保证数据的完整性,所以会引起数据库宕机的情况。

五:该问题产生的原因:

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

六:该问题涉及到的补丁

    在10.2.0.5版本的数据库中,scn问题涉及到补丁如下四个

    PSE1 (12780098)
    PSE2 (12748240)
    PSE3 RAC only (Originally 13437573, superceded by 13632140) <<<

    --注意,PSE3只在某些平台存在补丁
    PSE4 (13916709)

    SCN问题ORACLE公司前后发布两次补丁,第一次是2012年1月,PSU为:13343471,但是此次补丁并没有修复SCN全部部题,ORACLE公司于2012年7月发布PSU或CPU中修复,因此可以这么说,如果您的数据库打了2012年7月份或之后的PSU或者CPU就解决了绝大部分SCN问题。

     关于数据库PSU或CPU对应的发布时间可参考metalink文档:1454618.1

七:如何查看本库PSU版本信息

    cd $ORACLE_HOME/OPatch

     ./opatch lsinventory -bugs_fixed|grep -i 'DATABASE PSU'

     9952230  13632743 Sat Aug 18 10:36:35 GMT+08:00 2012DATABASE PSU 10.2.0.5.1 (INCLUDES CPUOCT2010)
     10248542 13632743 Sat Aug 18 10:36:35 GMT+08:00 2012DATABASE PSU 10.2.0.5.2 (INCLUDES CPUJAN2011)
     11724962 13632743 Sat Aug 18 10:36:35 GMT+08:00 2012DATABASE PSU 10.2.0.5.3 (INCLUDES CPUAPR2011)
     12419392 13632743 Sat Aug 18 10:36:35 GMT+08:00 2012DATABASE PSU 10.2.0.5.4 (INCLUDES CPUJUL2011)
     12827745 13632743 Sat Aug 18 10:36:35 GMT+08:00 2012DATABASE PSU 10.2.0.5.5 (INCLUDES CPUOCT2011)
     13343471 13632743 Sat Aug 18 10:36:35 GMT+08:00 2012DATABASE PSU 10.2.0.5.6 (INCLUDES CPUJAN2012)

    第一列加粗部分就是我们所说的PSU,跟据PSU号码查询metalink文档:1454618.1时间即可,跟据输出,我生产库最新PSU为13343471该PSU是2012年4月份的,因此PSE4尚未修复

八:如何查询本库是否安装某个patchORACLE 

    cd $ORACLE_HOME/OPatch

    ./opatch lsinventory

    该命令最终会输出很多patch或bug号,查询你所安装的patch号是否存在,如果存在,说明已经打过此patch

九:SCN问题解决方法

    方法一:打ORACLE官方推存的补丁

    说明:该方法有两个难点,如果该库和其它库有dblink连接,那么其它库也要同时做补丁升级,牵涉多少套系统未知,再说其它库是否采取升级你也是无法控制的,如果你只升级本库,那么如果异常同步scn至本库本库会拒绝dblink连接,导致业务失败,也是一种风险,退一万步讲,就算所有数据库补丁升级,升级后会不会出现新的bug也无法预料,因此风险和不可控因素太多

    方法二:找查SCN传染源,进行隔离处理

    说明:该方法简单而且处理起来难度最低,找到scn异常问题传染源以后进行补丁升级或将dblink用其它方式代替,可避免此类隐患导致故障(个人认为最优方法)

    方法三:通过调整隐含参数值最大限度保障业务运行

    说明:该方法前提是数据库打了2012年1月份的补丁后,会引入一个新的参数,该参数是控制headroom剩余天数,_EXTERNAL_SCN_REJECTION_THRESHOLD_HOURS该参数默认值是24,建议故障发生后重启再次宕机将该参数设置成1,最大限度紧急恢复业务,然后进行补丁升级,注意,该方法有前提并且仅供应急时使用,ORACLE官方不建议修改此参数值

十:如何查询headroom隐含参数值

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 
/

Enter value for par: _external_scn_rejection_threshold_hours

 

 

ORACLE SCN问题详解(2)--传染源定位

  

    ORACLE SCN增长异常定位传染源将其隔离处理是处理SCN问题最有效的方法,具体定位过程如下:

一:查看alter日志找查传染源


    从数据库alter日志中可以看出,系统scn增长过快是因为通过dblink被远端数据库ORCL传染所致,信息详细显示了远端数据库名、用户名、触发机器名等信息,但是该提示是安装2012年1月ORACLE发布的补丁才会有的提示,因此该方法有很大的局限性

二:通过定位传染源方法

1、查询SCN距离Headroom 上限的剩余天数的历史变化

SELECT TIM,

       GSCN,

       ROUND(RATE),

       ROUND((CHK16KSCN - GSCN) / 24 / 3600 / 16 / 1024, 1) "HEADROOM"

  FROM (SELECT TIM,

               GSCN,

               RATE,

               ((((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

                  FROM V$ARCHIVED_LOG

                 WHERE (NEXT_TIME > FIRST_TIME)))

 ORDER BY 1, 2;

将结果导出EXECEL生成图形:

1、如果是传染源headroom趋势图如下:

    
     说明:如果 SCN Headroom 的剩余天数的历史变化是相对平滑的趋向于变小,那么就说明内部数据库有应用触发了 Bug,导致 SCN 异常增长,如图上图所示

2、被传染headroom趋势图如下:

 

       
     说明:如果 SCN Headroom 的剩余天数的历史变化很突然,那么就说明数据库主要被外部通过DBLINK 传染,导致 SCN 异常增长;

     看一下我管理系统生产库SCN历史变化图:

     
     变化很突然,说明是被传染所致,因此问题的重点是查找传染源(这种方法不太准确)
2、也可以跟据如下脚本判断数据库是否为传染源

SELECT SS.SNAP_ID AS SNAP_ID,      
       TO_CHAR(SN.BEGIN_INTERVAL_TIME, 'YYYY-MM-DD HH24:MI:SS') AS "SNAP_DATE",      
       SUM(DECODE(STAT_NAME, 'calls to kcmgas', VALUE, 0)) -      
       LAG(SUM(DECODE(STAT_NAME, 'calls to kcmgas', VALUE, 0)), 1) OVER(ORDER BY SS.SNAP_ID) "KCMGAS",      
       TRUNC((SUM(DECODE(STAT_NAME, 'calls to kcmgas', VALUE, 0)) -            
             LAG(SUM(DECODE(STAT_NAME, 'calls to kcmgas', VALUE, 0)), 1)           
              OVER(ORDER BY SS.SNAP_ID)) /           
             TRUNC((CAST(SN.END_INTERVAL_TIME AS DATE) -                  
                   CAST(SN.BEGIN_INTERVAL_TIME AS DATE)) * 86400)) "KCMGAS PER SEC"
  FROM SYS.DBA_HIST_SYSSTAT SS, SYS.DBA_HIST_SNAPSHOT SN
 WHERE SS.SNAP_ID = SN.SNAP_ID   
   AND SS.STAT_NAME IN ('calls to kcmgas')     
   AND SS.DBID = SN.DBID     
   AND SS.INSTANCE_NUMBER = SN.INSTANCE_NUMBER    
   AND SN.INSTANCE_NUMBER = 1 --替换检查库INSTANCE_NUMBER    
   AND SN.DBID = 1840233104 --替换检查库DBID

分享到:
评论

相关推荐

    个人经验总结:Oracle数据库SCN号详解

    ### 个人经验总结:Oracle数据库SCN号详解 #### 一、引言 在Oracle数据库管理与维护过程中,了解SCN(System Change Number)的概念及其作用至关重要。SCN是Oracle数据库内部用于跟踪数据库状态变化的一个重要机制,...

    oracle SCN机制详解

    Oracle SCN(System Change Number)机制是Oracle数据库中用于跟踪和保证数据一致性的重要组成部分。SCN是一个不断递增的数字,代表了数据库中的时间线,它记录了每一次对数据库的修改。Oracle利用SCN来确定数据的...

    oracle scn概念解析

    ### Oracle SCN 概念解析 #### 一、SCN 的定义与作用 **SCN (System Change Number)** 是 Oracle 数据库中的一个重要概念,用于记录数据库的状态变化。它本质上是一个递增的逻辑计数器,每当数据库发生变化时就会...

    oracle scn 详解

    ### Oracle SCN 详解 #### 一、SCN概念解析 **SCN (System Change Number)** 是Oracle数据库中用于标识数据库状态变化的一种内部编号机制。它是一个递增的数字,每当数据库发生更新操作时,SCN就会增加。这个机制...

    Oracle系统改变号SCN详解

    SCN的重要性在于,它不受操作系统时间的影响,避免了由于时间篡改导致的数据混乱问题。在Oracle数据库中,SCN被用来跟踪并确保事务的正确提交和回滚,以及在数据库恢复过程中的精确性。 SCN的设计非常巧妙,它的值...

    Oracle SCN详解

    Oracle SCN 详解 Oracle 中的 SCN(system change number)是一种时间号,类似于我们的北京时间,但是它的意义不同于北京时间。SCN 是 Oracle 用来记录所有操作的先后顺序的重要机制。 为什么 Oracle 不使用时间...

    ORACLE SCN增长过快问题研究和解决方案探索.pdf

    【Oracle SCN增长过快问题详解】 Oracle数据库中的System Change Number(SCN)是数据库内部用于追踪事务时间顺序的关键机制。SCN是一个递增的计数器,它在每次事务提交时都会增加,确保数据的一致性和可恢复性。...

    oracle scn

    ### Oracle SCN详解 #### 一、SCN概念与作用 **SCN(System Change Number)**,即系统变更号,是Oracle数据库中的一个重要机制。它主要用于跟踪数据库内部的变化,包括但不限于数据恢复、Data Guard、Streams复制...

    Oracle SCN与检查点详解

    Oracle SCN(System Change Number)是Oracle数据库中一个关键的概念,它是数据库内部的逻辑时钟,用来标记数据库在特定时刻的状态。SCN是一个递增的序列号,每次事务提交时,都会分配一个唯一的SCN,以此确保数据库...

    MATLAB实现SCN随机配置网络多输入单输出回归预测(含完整的程序和代码详解)

    内容概要:本文介绍了使用MATLAB实现SCN(基于脉冲神经网络的模型)的多输入单输出回归预测。首先描述了SCN模型的主要组成部分和算法流程,接着...在遇到问题时,可以通过参考提供的参考资料进一步理解概念和技术细节。

    oracle 备份文档

    ### Oracle备份核心知识点详解 #### 一、SCN(系统更改编号)的作用与意义 - **定义**: SCN(System Change Number)是Oracle数据库用来跟踪所有数据更改的一个内部序列号,它是一个递增的数字,每当数据库发生...

    MF_RC522_scn资料

    ### MF_RC522_scn资料详解 #### 1. 概述 MF RC522 是一款由 NXP 公司推出的适用于13.56MHz非接触式通信技术的高集成度读写卡芯片。该芯片因其低电压、低成本及小巧的体积而受到广泛关注,特别适合用于“三表”...

    Python 实现SCN随机配置网络多输入单输出回归预测(含完整的程序和代码详解)

    内容概要:本文详细介绍了一个基于 Python 的多输入单输出回归预测项目,采用随机配置网络(SCN),支持图形用户界面操作,主要功能包括数据预处理、模型构建与训练、评估以及预测结果可视化等。 适合人群:具备一定...

    scnedit:stencyl .scn编辑器

    【scnedit: Stencyl .scn编辑器详解】 Stencyl是一款强大的游戏创作工具,它允许非程序员通过图形化界面创建2D游戏。在Stencyl中,`.scn`文件是场景(Scene)的文件格式,包含了游戏中的布局、对象位置、交互逻辑等...

    scnscrap:用于抓取scn博客的简单项目

    **描述详解:** 该项目的描述表明它是一个专注于数据抓取(Web Scraping)的应用,旨在从SCN论坛中获取用户博客内容。它的目标是提供一个工具,能够帮助用户收集并分析SCN博客上的各种互动数据。通过抓取这些数据,...

    Oracle 数据泵详解

    - FLASHBACK_TIME/SCN:用于时间点恢复或基于SCN的恢复。 通过这些参数,用户可以根据实际需求定制导出操作,实现更精细的控制。 总结起来,Oracle数据泵是Oracle数据库管理中不可或缺的工具,它提供了高效、灵活...

    oracle中imp命令详解.pdf

    ### Oracle中IMP命令详解 #### 一、概述 Oracle 的导入实用程序(Import utility)是一种强大的工具,允许用户从一个数据库提取数据,并将其写入操作系统文件。这在进行数据库迁移、备份恢复等操作时非常有用。IMP...

Global site tag (gtag.js) - Google Analytics