标签归档：oradebug kcsgscn_

之前有一些简单介绍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 … 继续阅读 →