delayed block cleanout 与 ORA-1555的关系

biti_rainy

最初由 hqs4500 发布
[B]没想到biti_rainy也来了，有些激动。
但是感觉overtime说法更合理，先消化消化看是否还有其他问题。 [/B]

我说的和他说的并没有大的矛盾，呵呵

只不过有一点点小问题上 有分歧

就是关于确立 comit  number 上
但是他只是猜测，并且这个猜测…… 暂时没有依据

而偶引自 专家的话而已

overtime

我记得你有篇贴子还分析了block dump的内容，其中每个transaction slot有个字段是flag,含义：
C=committed
U=upper bound commit
这个upper bound commit是从何而来？
另外，我比较相信以下两个人:
http://www.jlcomp.demon.co.uk/cleanout.html (第三段)
http://www.ixora.com.au/tips/admin/ora-1555.htm  (cleanout failure)

biti_rainy

最初由 overtime 发布
[B]"假如 transaction table slot 和 undo block 都被覆盖，则返回 1555"
这种 情况下并不一定要会返回1555，只有当Oracle无法判断出commitSCN<querySCN时才会返回1555.(这种时候Oracle还有可能有办法得到一个COMMIT SCN的上限值，可以通过上限值来比较来判断是否commitSCN<querySCN) [/B]

认同这个说法



只要有办法做到，我也总相信oracle能做到的

BTW :
偶更信任 steve and JL 的说

grassbell

好贴！

grassbell

这个upper bound commit是从何而来？oracle怎么做到的？

biti_rainy

最初由 grassbell 发布
[B]这个upper bound commit是从何而来？oracle怎么做到的？ [/B]

oracle 会把query  scn 去和 回滚段中 事务的提交scn比较，如果没有找到事务结束scn，说明回滚信息已经被覆盖了。这时就把query  scn 去和 control scn比较，因为 control  scn 是当前该回滚段中所能获得的最小的一个 commit  scn.如果 query  scn 依然小于这个control  scn ，由于被覆盖的事务的commit  scn 肯定比回滚段中 contrl  scn 小，则暗示着 oracle 无法知道 query  scn 和 commit  scn 之间的大小关系，就报了 1555 错误。

这个时候，oracle就把这个 control  scn 当作 upper  bound  commit  scn 。这是因为，真实的cmmit  scn 必然小于这个 control  scn .而current  scn必然远大于这个 control  scn。所以将 commit  scn 设置为这个control  scn 必然是安全的。

commit scn <  control  scn (upper  bound  scn)  <  current  scn

grassbell

OK!

control SCN is the commit SCN of the most recently reused transaction slot's previous transaction.

http://www.ixora.com.au/q+a/cr.htm

加精！

grassbell

将一致读的步骤细化一点，请指正：

从第5步开始：
---IF 在Transaction Table 中根据Transaction ID 找到transaction
------------IF  transaction 已经commit
------------------------IF query scn>commit scn                  
-------------------------------------则接受该块，进行clean out，返回1
------------------------ELSEIF query scn<commit scn                  
-------------------------------------则进行一致性读，从第8步向后执行
------------ELSEIF transaction 没有commit     
------------------------也进行一致性读，从第8步向后执行

---ELSEIF 在Transaction Table 中没有找到transaction(回滚信息被覆盖了，也说明事务已经提交，因为只有提交后所在的undo extent才能被覆盖。这样query scn则去比较control scn。control scn是指事务表中最近一次被重用的transaction slot的前一个事务的commit scn，也就是事务表中所能找到的最小的commit scn了)
------------IF query scn<control scn
------------------------则无法知道query scn和commit scn得大小关系，出现ORA-01555错误
------------IF query scn>control scn       
------------------------则query scn肯定>commit scn
-------------------------------------则接受该块，进行clean out，并将block 中ITL标记上“U”，表示“upper bound commit” ，并返回1

idler

这是我以前翻译的一篇ORA-1555的文章（来自METALINK），加了点自己的理解

ORA-1555错误综述
ORA-1555是一个非常著名但让人讨厌的错误，下面就该错误是如何产生的及该如何来预防做个综述。
        ORA-1555错误简单的说就是针对一个数据块产生一致读时发生了错误。一致读就是指ORACLE利用回滚段来临时重构一个和事务或查询开始时的块状态相同的快照块的过程。如果一个块改变了多次，可能就会有多个快照块的。
        一个事务或查询开始执行时，ORACLE会产生一个SCN来记录这个开始时刻点，这个SCN也就叫做SNAPSHOT SCN。ORACLE仅仅看基于SNAPSHOT SCN的快照记录。如果块中有活动的事务或BLOCK SCN> SNAPSHOT SCN时，就产生了一致读。如果是没有活动的事务但没有产生COMMIT SCN的块，先产生DELAY BLOCK CLEANOUT，再比较COMMIT SCN与SNAPSHOT SCN的大小，如果COMMIT SCN小于SNAPSHOT SCN则直接使用该块，否则要产生一致读。
        产生ORA-1555的可能情况：
（1）        一个长时间运行的查询，并同时针对查询需要的块有DML处理
当一个长时间的查询开始执行时，查询所需要的一个数据块被修改并递交了，这个块是需要一致读的，但因为该DML事务已递交了，所以保留前映像的回滚段SLOT可以被另外的事务使用，这个查询事务耗时非常长，在这个时间段中，很可能该SLOT被另外的事务使用而把原值给覆盖了，所以当查询执行到该块时，该块的SNAPSHOT SCN时的值已经找不到了，报ORA-1555错误。
解决方法：
        业务控制，禁止对同一个表的长时间查询和更新处理同时进行，要分开执行
        增加回滚段的个数
        增大回滚段的大小，记住产生ORA-1555的错误可能是最小的回滚段造成的，所以每个回滚段的大小应该一致。
        不使用OPTIMAL选项
        推迟对DML语句的COMMIT
        缩短查询的时间，修改查询语句，比如并行查询
        为要查询的表建立只读SNAPSHOT，这样对表记录的修改就不会影响到查询，但该表不能是太大的表
（2）        交叉递交
通过一个游标建立一个循环来循环读取表的数据，但又在循环中对表的进行修改并递交。如果正好多次修改并递交，将一个数据块在回滚段的前映像给覆盖了，当循环又要取该数据块的值时，报ORA-1555错误。这是个经常出ORA-1555错误的操作。
解决方法：
        修改程序，避免这种情形出现
        尽量在循环读取中，不要做递交处理
        在查询语句中，增加“ order by 1 ”的语句，这样会在临时段中保留ORDER BY的结果，而不在需要一致读了。
（3）        延迟块清除
延迟块清除是指当一个DML事务发生并递交了，ORACLE在回滚段做了一个快速COMMIT标记该事务已递交了，但在DATA BUFFER中修改过的数据块并没有标记，（ORACLE一次只清除DATA BUFFER10%的修改的数据块）这些未清除但已递交的数据块要在下一次事务访问才清除掉，这就是延迟块清除。在这个过程中有可能出现ORA-1555的错误，但一般是非常难得的，因为出现这个错误需要满足以下几个条件：
     ①已做了修改并递交，但又未做清除的数据块
     ②这些块在被下一个要出错的事务使用前，没有被其他事务使用
     ③查询期间，系统中又发生了大量的其他DML处理，这些DML处理不涉及到这些块。
     ④因为这些大量的DML事务，产生了频繁的递交，造成事务表被多次WRAP，最初保留未清除事务的事务条目也被循环的使用，原来的UPDATE COMMIT SCN已经不存在了。
     ⑤回滚段的最小SCN已经超过查询SCN了
     ⑥当查询执行到该块的时候，发现该块的UPDATE COMMIT SCN已经不存在了，而且现在回滚段的最小SCN也比查询SCN要大，UPPER BOUND SCN都无法估算了，所以无法确定查询是否能使用这个块，造成ORA-1555错误。
     解决方法：
        一般这种情况很难出现，可以不考虑，如果确实要解决，可以在DML操作后，做一次FULL TABLE SCAN来清除上次未清除的块。
        可以设置DELAYED_LOGGING_BLOCK_CLEANOUTS = true （缺省）
（4）        回滚段有坏块

总结，从上面说明中可以看出，防止ORA-1555问题出现，最根本的一点就是保证回滚段中已COMMIT的事务信息不被覆盖了。9I中，ORACLE提供一个更加有效的方法来保证这点，用参数UNDO_RETENTION来保证COMMIT的事务多长时间不被覆盖。具体说明，参见ORACLE9I的自动回滚段管理说明（SMU）

ZALBB

有几个疑问：

1、TRANSACTION TABLE SLOT 什么时候/条件下会被覆盖？

2、对 hqs4500 说的这段：

这样理解正确否？
TRANSACTION SLOT OVERWRITTEN，所以不知该BLOCK的COMMIT SCN与QUERY SCN孰大孰小，所以无从得到
CONSISTENT IMAGE。对吗?

我觉得，TRANSACTION TABLE SLOT 因为被覆盖而造成BLOCK上的XID在TRANSACTION TABLE SLOT找不到
对应值的情况很少，更多的是, 被查询的BLOCK上ITL.UDA 对应的 UNDO BLOCK 被覆盖,而无法读到查询
开始时未修改的数据，所以出现ORA-01555错误。

我不认为 DELAYED BLOCK CLEANOUT 作为产生ORA-1555的一个原因，我觉得是因为：QUERY SCN < BLOCK
上的 COMMIT SCN，则必须到回滚段读修改前的数据，而此时若回滚段上的这些信息被覆盖了，则出现
ORA-01555错误。

若说：“TRANSACTION SLOT OVERWRITTEN，所以不知该BLOCK的COMMIT”，那BLOCK块上的SCN从哪里得来。

3、我还有一种想法：由于修改后的数据并不立刻被写进数据文件，会不会：ORACLE一开始就比较
QUERY SCN 和 BLOCK 块上的 SCN，若BLOCK SCN <= QUERY SCN，并且ITL上无活动/有效的事务信息，
则认为该块上的数据是所需要的？

若上面那个假设成立，那这里必须有个前提：在一开始做DML时候，ORACLE对被修改的块的ITL信息
做了标识，但此时并不把修改后的结果写回去。否则，ORACLE怎么知道会去读取回滚段？


4、有朋友说：ORACLE不会对修改提交后的块做CLEANOUT动作，直到第一次查询该块。
问：此说法是否正确？我有点疑问：ORACLE是凭什么对该块做CLEANOUT动作的？若是

5. Read the Transaction Table using the Transaction ID. If the transaction has been committed
   and has a System Commit Number less than the query's System Change Number, update the
   status of the block (block cleanout) and start over at step 1.
   
问：万一此Transaction Table上的记录被覆盖，那就做不了CLEANOUT了？