很多资料都把delayed block cleanout 作为产生ORA-1555的一个原因。我觉得ora-1555的原因有二：相应的transaction table slot被覆盖或相应的undo information被覆盖。想不明白为什么单独把delayed block cleanout作为一个原因：它可以归结为上述原因之一。
谁帮忙解释一下。
另外一个问题：如果transaction table slot被覆盖，block cleanout能成功吗？它的commit SCN从那里得到？
谢谢！

问题太简单还是坛中已有相关帖子？
我在黑暗中，清指出一条明路。

相应的transaction table slot被覆盖.oracle不能确定数据块在查询开始的SCN时是否是commit的。

cleanout 能成功，只要进行cleanout的这个事务不发生1555。rbs header里有个SCN的上限值，cleanout时会记录这个SCN，而不是事务实际的SCN了。

TRANSACTION SLOT OVERWRITTEN，所以不知该BLOCK的COMMIT SCN与QUERY SCN孰大孰小，所以无从得到CONSISTENT IMAGE。对吗?
谢谢楼上仁兄。

一致读的步骤：
    1. Read the Data Block.

2. Read the Row Header.

3. Check the Lock Byte to determine whether there's an ITL entry.

4. Read the ITL entry to determine the Transaction ID (Xid).

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.

6. Read the last undo block (Uba).

7. Compare the block transaction ID with the transaction table transaction ID. If the Transaction ID in the undo block doesn't equal the Transaction ID from the Transaction Table, then issue ORA-1555, Snapshot Too Old.

8. If the Transaction IDs are identical, make a copy of the data block in memory. Starting with the head undo entry, apply the changes to the copied data block.

9. If the tail undo entry (the actual first undo entry in the chain, or the last in the chain going backwards!) indicates another data block address, read the indicated undo block into memory and repeat steps 7 and 8 until the undo entries don't contain a value for the data block address.

10. When there's no "previous data block address," the transaction has been completely undone.

11. If the undo entry contains:

a. a pointer to a previous transaction undo block address, read the Transaction ID in the previous transaction undo block header and read the appropriate Transaction Table entry. Return to step 5.

b. an ITL record, restore the ITL record to the data block. Return to step 4.

to hqs4500:
  我认为你的理解是对的。

to biti:
你的文章里并没有提到transaction table slot找不到(被覆盖)的情况。

5,6,7,8

假如 transaction table slot 和 undo  block 都被覆盖，则返回 1555,假如transaction table slot被覆盖，但是 undo  block 没有被覆盖，这时一定满足这样其中情况，就是 事务已经提交并且 commit  SCN  > select SCN (假如commit SCN < select SCN的话在5已经停止往下走了)，于是产生consistent reads

8. If the Transaction IDs are identical, make a copy of the data block in memory. Starting with the head undo entry, apply the changes to the copied data block.

把 data block 产生一个拷贝，把 回滚段内容应用于 拷贝上


transaction table slot找不到  也是标志 事务被提交的情况的一种，实际上已经包含在上述的文字中了

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

QUOTE:

---

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

---

commit SCN 是真切地存在于回滚段中，如果都被覆盖了，还从哪里来？其他地方能存储么？可是好多的说

应该是没有办法

BTW: 偶还是比较信任给出这份文字的人的说

没想到biti_rainy也来了，有些激动。
但是感觉overtime说法更合理，先消化消化看是否还有其他问题。