`

转: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基础 ##### 1. 什么是SCN **SCN(System Change Number,系统变更号)**是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