最近几家客户的Oracle数据库开始集中爆发SCN HeadRoom问题,虽然SCN不会真正用完,但是数据库触碰到headroom天花板,还是可能有意想不到的情况发生,例如事务拒绝。
小编这里尽量用通熟易懂的语言,来解释下SCN HeadRoom,以及出现SCN HeadRoom后的处理措施。
SCN是Oracle的内部时钟,他会随着Oracle的各种操作,不断增长,最大能涨到2的48次方,也算是个天文数字。
Oracle对于SCN的增长有个小小的限制,即当前HeadRoom,注意,用了 当前 两个字,表示这个HeadRoom是实时计算出来的,计算方式为:1988年距当前时间的秒数 * 16k,所以HeadRoom是按照秒,每秒16K的涨幅在增加,每个时刻,Oracle会将SCN与HeadRoom进行比较,如果事务SCN超过HeadRoom,当前事务可能失败,但随着时间的流逝,HeadRoom也在不断增长,只要你的后续SCN增长不触碰到HeadRoom,就没问题。另外触碰到HeadRoom与用尽SCN是两码事,按照16K/秒的速度,SCN需要500年才能用尽。
那么哪些原因会导致数据库触碰到HeadRoom呢?
对于1,好理解,Bug出来,猪飞上天都不足为奇;对于2,就是受限于Oracle DBLink的工作机制,每一次跨库查询,都算一个分布式事务,他们需要一个统一的SCN,两个库的SCN不一样,就同步成一样。如果一个SCN异常增长的库放在你的生产环境里,又有DBlink查询的话,这片数据库的SCN增长基本都会异常。所以当DBLink触发的SCN增长超过限定值时,对端数据库可能会拒绝这次事务。
如何有效处理SCN HeadRoom
Oracle给出的方法,是对于SCN异常增长的数据库打补丁,如果没有相应补丁,就dblink层面隔离掉,另外有些提高阀值的调整方法,小编觉得并不治本。
客户有100多套数据库,我怎么快速知道,谁是异动数据库?DBlink走的跟蜘蛛网一样,我怎么快速找源头?如果你直接告诉我,谁是异动库,谁是跳变源头,那无非就补丁,隔离两条路了。所以解决SCN HeadRoom的难点并不在问题本身,而在于一套有效的追踪机制,茫茫库海,谁TM是我要寻的。
根据上述分析,我们重点要找的是自身SCN增长异常的库,至于被感染的库,只要去掉感染源,他本身还是健康的,小编思路如下:
经过上述自动化的工具采集,展现,分析,你可以很清晰的看到,这么多库在一起,谁的scn增长是快的,谁的天花板是要塌的,谁总是抢在别人前面发生SCN突变,大浪淘沙,总有几个库会露出马脚,这也许就是我们要提前整治的库。
★友情提示:本文实际是提供的一种自动化工具运维的思路,数据库多了,DBA的价值不在于解决具体某个库的问题,他更大的价值应该是解决规模效应。小编已经将上述思路工具化,在客户现场进行HeadRoom数据的采集,汇总与分析,略见成效,忙并快乐着,有更多进展会继续文章反馈!!!