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';
haha,内部资料哦
http://www.itpub.net/673122.html
提到你了。请阅读。haha
to 5哥
在拉萨无法访问itpub？不知道是itpub的问题还是拉萨的问题，帖子说啥了，我暂时看不到。
to wanghai
adjust scn的算法好像不是内部资料，你们在metalink上好像也可以搜索到的。还有，你的blog在订阅的时候显示文章都没有分行的，一句接一句，让fenng帮你整整哈。
哦。不急，等你回来再看。
帖子大意是，我把Fenng批了一通，原因嘛，主要是我想看他女朋友照片，他不给我看。哈哈。
你好，我有些关于ORACLE的视图的问题，搜索到你的blog，想借机会请教你一个问题，望帮助解答。
公司用的是oracle8i，有一个表数据量很大还时常更新，一个视图是基于这个表的一些列生成的。以前公司用的软件是基于表查询数据，速度挺快。现在软件升级后变成基于视图查询。视图建立不了索引，查询速度相当慢。我想找到解决办法。在网上搜索到固化视图可以提高查询效率，但好象视图基于的表数据常变化也会常更新视图，影响效率。
请问我该怎么办才能提高视图的查询效率，还是只能把查询从视图改为从表中查询？
谢谢
to Lion
我们认为视图只是一段SQL的同义词，相信你把构成视图的SQL直接嵌入调用视图的那个SQL中，效率仍然是一样差，所以实质问题并非是通过了视图查询还是直接在基表上查询。
你应该注意的是，在使用视图前的业务逻辑和使用视图后的业务逻辑是否有差异，整个SQL的执行计划在前后是否有差异。
我相信既然以前直接查询基表效率是好的，那么你就无需通过物化视图的方式来进行调优。
谢谢。我又对比了一下，现语句用ORDER BY 排序了一下，查询速度就由原来的10秒增加到100秒以上（基表中数据量有100多万条）
怎么能提高带ORDER BY查询语句的执行速度？
我没有系统的学过ORACLE，如果问的问题过于简单请见谅
大量的排序必然牵涉到大量的I/O，如果内存中的排序区不足以容纳需要排序的数据，那么还需要在临时表空间中进行磁盘I/O，这是一个昂贵的操作。
既然以前可以不用order by，现在为什么要在视图里使用order by？
软件升级时要求查询结果需要按一定顺序打印出来，所以加了order by语句
其实查询出来的数据只有几十条到几百条，我想应该是按照条件检索出一些记录后，再order by才对，这样执行速度也不会降低多少。现在看来难道是order by的执行优先于条件检索？
这个看执行计划就比较清楚了，想来应该是在有很大recordset的时候就进行order by了
我看了一下执行计划里两个语句执行的区别。当没有ORDER BY时，直接在表中FULL查询；当加上ORDER BY后，先是在该表的索引中FULL SCAN，然后在表中BY INDEX ROWID查询。我想ORDER BY效率差的原因是因为会先在索引中选择所有的值，然后再一条一条和表中的ROWID比较，最后得出结果。
如果不调用索引，查询速度就应该会快起来。那个表的索引还有其他用途，所以不能取消。还有什么方法可以让ORDER BY不使用索引查询么？或者有其他的解决办法？谢谢
还有我用的是pl/sql developer 7,数据库是8i。
执行计划里把所有的可选项目都加上了。但执行完语句只有几个列里有数据，象COST，IO COST，Bytes之类的列都是空的。是因为数据库版本低不支持的原因么？
1. 作表的analyze
2. 手动禁用索引，可以通过诸如index_column||”=some_value这样的方式，也就是给索引字段并上一些空值（数字的可以加0），在不改变数值的情况下避开索引使用
十分感谢你的热心帮助，请问有QQ或MSN的联系方式么？希望能和你成为朋友