标签归档:oradebug kcsgscn_

使用ORACDEBUG 修改 数据库SCN

之前有一些简单介绍SCN的文章: 浅谈SCN_1–从oracle7至今,如何获取scn 浅谈SCN_2–_kcmgas_函数 通过修改控制文件来修改SCN 1988年Oracle发布了Oracle V6,这一版本中Oracle引入了热备的操作,同时SCN使用48位存储的算法写死在代码中,一直沿用至12c以前(12c开始使用8个bytes存储SCN)。由于ORACLE的SCN是由48位来表示的,因此最大值不能超过2的48次方 Oracle为了确保48位的SCN能够用足够长的时间(500年),于是对SCN做出了一个限制,就是每秒钟SCN最大增长不能超过16K,Oracle从1988年1月1日0点0分0秒为基准时间,到当前的秒钟数乘以16K,就是当前SCN的最大允许值这就是SCN HEADROOM。 因此SCN天花板 的计算公式就类似于: (当前时间-19880101 000000)*16384–(current_scn),其中 16384是SCN的内部增长速度16k,这是代码中的硬限制。 这个限制在11.2.0.2版本之前,scn 的最大增长频率是16k,在11.2.0.2版本开始,为32k。 此行为是受到下面参数_max_reasonable_scn_rate控制的: 在11.2中,Oracle除了将SCN 每秒最大的增长量从16K加大为32K,还引入了一个阀值,用于阻断有SCN HEADROOM问题的系统将故障传播到其他系统。 这些修复包含在下列补丁中: 如果SCN发生突增的情况,alert中就会出现类似下面的告警: 因此,打了这上面这些补丁后,就不能使用以前的参数直接修改SCN了。 然后,有时候数据库遇到一些异常错误,还是需要将SCN推进的到一个合适的值,例如,常见一些错误造成数据库的部分block跟数据库SCN不一致,或者一些有undo$数据库启动时引导失败: ORA-600 [2256] ORA-600 [2662] ORA-600 [4000] ORA-600 [kcsadjn1] 在以前我们使用参数来修改SCN,例如: event=”10015 trace name adjust_scn level x” 或者使用 _minimum_giga_scn … 继续阅读

发表在 backup&recovery, Internal | 标签为 | 留下评论