Oracle安全:SCN可能最大值与耗尽问题

***安全:SCN可能最大值与耗尽问题

在2012年第一季度的CPU补丁中，包含了一个关于SCN修正的重要变更，这个补丁提示，在异常情况下，***的SCN可能出现异常增长，使得数据库的一切事务停止，由于SCN不能后退，所以数据库必须重建，才能够重用。

我曾经在以下链接中描述过这个问题：

***使用6 Bytes记录SCN，也就是48位，其最大值是：

SQL> col scn for 999,999,999,999,999,999  　　SQL> select power(2,48) scn from dual;  　　SCN  　　------------------------  　　281,474,976,710,656

***在内部控制每秒增减的SCN不超过 16K，按照这样计算，这个数值可以使用大约544年：

SQL> select power(2,48) / 16 / 1024 / 3600 / 24 / 365 from dual;  　　POWER(2,48)/16/1024/3600/24/365  　　-------------------------------  　　544.770078

然而在出现异常时，尤其是当使用DB Link跨数据库查询时，SCN会被同步，在以下链接中，我曾经描述过此问题：

一个数据库当前最大的可能SCN被称为"最大合理SCN"，该值可以通过如下方式计算：

col scn for 999,999,999,999,999,999  　　select 　　(  　　(  　(  　　(  　　(  　　(  　　to_char(sysdate,'YYYY')-1988  　　)*12+  　　to_char(sysdate,'mm')-1  　　)*31+to_char(sysdate,'dd')-1  　　)*24+to_char(sysdate,'hh24')  　　)*60+to_char(sysdate,'mi')  　　)*60+to_char(sysdate,'ss')  　　) * to_number('ffff','XXXXXXXX')/4 scn  　　from dual  　　/

这个算法即SCN算法，以1988年1月1日 00点00时00分开始，每秒计算1个点数，最大SCN为16K。

这个内容可以参考如下链接：

在CPU补丁中，***提供了一个脚本 scnhealthcheck.sql 用于检查数据库当前SCN的剩余情况。

该脚本的算法和以上描述相同，最终将最大合理SCN 减去当前数据库SCN，计算得出一个指标：HeadRoom。也就是SCN尚余的顶部空间，这个顶部空间最后折合成天数：

以下是这个脚本的内容：

在应用补丁之后，一个新的隐含参数 _external_scn_rejection_threshold_hours 引入，通常设置该参数为 24 小时：

_external_scn_rejection_threshold_hours=24

这个设置降低了SCN Headroom的顶部空间，以前缺省的设置容量至少为31天，降低为 24 小时，可以增大SCN允许增长的合理空间。

但是如果不加控制，SCN仍然可能会超过最大的合理范围，导致数据库问题。

这个问题的影响会极其严重，我们建议用户检验当前数据库的SCN使用情况，以下是检查脚本的输出范例：

这个问题已经出现在客户环境中，需要引起大家的足够重视。

【编辑推荐】

如何在***中使用Java存储过程(详解)任重道远迁移路之***到***11个重要的数据库设计规则让数据库变快的10个建议20个数据库设计最佳实践

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。