How to calculate adjust SCN level

本文对eygle的如何处理ORA-600 [2662]作一点补充。

通常我们对于ORA-600 [2662]错误的解决是通过10015 ADJUST_SCN事件来增进current SCN以达到比数据文件中最大的SCN还要大的目的,这样才可能启动数据库。

eygle的例子中报错信息如下:

ORA-00600: internal error code, arguments: [2662], [0], [547743994], [0], [898092653], [8388617], [], []

这个报错参数的含义在metalink中如此描述的:
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [C] dependent SCN WRAP
为了存储更大的SCN值,当SCN BASE到足够大并开始重置的时候,SCN WRAP将加1。
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
也就是Arg [d] 的值是从哪个block中找到的,通常是一个data block address。

通过这几个参数根据一定的规则可以计算出我们需要的level。计算规则如下:
1. Arg [C] *4得出一个数值,假设为V_Wrap
2. 如果Arg [d]=0,则V_Wrap值为需要的level
Arg [d] < 1073741824,V_Wrap+1为需要的level Arg [d] < 2147483648,V_Wrap+2为需要的level Arg [d] < 3221225472,V_Wrap+3为需要的level 仍旧看eygle的案例。 Arg [C] *4 = 0 * 4 = 0 Arg [d] = 898092653 < 1073741824 所以level = 0+1 = 1 因此其实eygle不需要增进level 10,level 1就应该足够了。 alter session set events ‘10015 trace name adjust_scn level 1’;

看另外一个例子的报错信息,我们再来计算一次。

ORA-00600: internal error code, arguments: [2662], [0], [2179133], [8656], [70114056], [33855201], [], []

Arg [C] *4 = 8656 * 4 = 34624
Arg [d] = 70114056 < 1073741824 所以level = 34624 + 1 = 34625 因此在这个例子中我们应该执行 alter session set events ‘IMMEDIATE trace name ADJUST_SCN level 34625’;

14 Comments Add yours

  1. wanghai says:

    haha,内部资料哦

  2. 5415 says:

    http://www.itpub.net/673122.html

    提到你了。请阅读。haha

  3. kamus says:

    to 5哥
    在拉萨无法访问itpub?不知道是itpub的问题还是拉萨的问题,帖子说啥了,我暂时看不到。

    to wanghai
    adjust scn的算法好像不是内部资料,你们在metalink上好像也可以搜索到的。还有,你的blog在订阅的时候显示文章都没有分行的,一句接一句,让fenng帮你整整哈。

  4. 5415 says:

    哦。不急,等你回来再看。

    帖子大意是,我把Fenng批了一通,原因嘛,主要是我想看他女朋友照片,他不给我看。哈哈。

  5. lion says:

    你好,我有些关于ORACLE的视图的问题,搜索到你的blog,想借机会请教你一个问题,望帮助解答。
    公司用的是oracle8i,有一个表数据量很大还时常更新,一个视图是基于这个表的一些列生成的。以前公司用的软件是基于表查询数据,速度挺快。现在软件升级后变成基于视图查询。视图建立不了索引,查询速度相当慢。我想找到解决办法。在网上搜索到固化视图可以提高查询效率,但好象视图基于的表数据常变化也会常更新视图,影响效率。
    请问我该怎么办才能提高视图的查询效率,还是只能把查询从视图改为从表中查询?
    谢谢

  6. kamus says:

    to Lion
    我们认为视图只是一段SQL的同义词,相信你把构成视图的SQL直接嵌入调用视图的那个SQL中,效率仍然是一样差,所以实质问题并非是通过了视图查询还是直接在基表上查询。
    你应该注意的是,在使用视图前的业务逻辑和使用视图后的业务逻辑是否有差异,整个SQL的执行计划在前后是否有差异。
    我相信既然以前直接查询基表效率是好的,那么你就无需通过物化视图的方式来进行调优。

  7. lion says:

    谢谢。我又对比了一下,现语句用ORDER BY 排序了一下,查询速度就由原来的10秒增加到100秒以上(基表中数据量有100多万条)
    怎么能提高带ORDER BY查询语句的执行速度?
    我没有系统的学过ORACLE,如果问的问题过于简单请见谅

  8. kamus says:

    大量的排序必然牵涉到大量的I/O,如果内存中的排序区不足以容纳需要排序的数据,那么还需要在临时表空间中进行磁盘I/O,这是一个昂贵的操作。
    既然以前可以不用order by,现在为什么要在视图里使用order by?

  9. lion says:

    软件升级时要求查询结果需要按一定顺序打印出来,所以加了order by语句
    其实查询出来的数据只有几十条到几百条,我想应该是按照条件检索出一些记录后,再order by才对,这样执行速度也不会降低多少。现在看来难道是order by的执行优先于条件检索?

  10. kamus says:

    这个看执行计划就比较清楚了,想来应该是在有很大recordset的时候就进行order by了

  11. lion says:

    我看了一下执行计划里两个语句执行的区别。当没有ORDER BY时,直接在表中FULL查询;当加上ORDER BY后,先是在该表的索引中FULL SCAN,然后在表中BY INDEX ROWID查询。我想ORDER BY效率差的原因是因为会先在索引中选择所有的值,然后再一条一条和表中的ROWID比较,最后得出结果。
    如果不调用索引,查询速度就应该会快起来。那个表的索引还有其他用途,所以不能取消。还有什么方法可以让ORDER BY不使用索引查询么?或者有其他的解决办法?谢谢

  12. lion says:

    还有我用的是pl/sql developer 7,数据库是8i。
    执行计划里把所有的可选项目都加上了。但执行完语句只有几个列里有数据,象COST,IO COST,Bytes之类的列都是空的。是因为数据库版本低不支持的原因么?

  13. kamus says:

    1. 作表的analyze
    2. 手动禁用索引,可以通过诸如index_column||”=some_value这样的方式,也就是给索引字段并上一些空值(数字的可以加0),在不改变数值的情况下避开索引使用

  14. lion says:

    十分感谢你的热心帮助,请问有QQ或MSN的联系方式么?希望能和你成为朋友

Leave a Reply

Your email address will not be published. Required fields are marked *