8i中回滚段使用和ORA-1555

    回滚段中保存的回滚数据有2个作用：一致读和回滚。回滚段是由连续block组成的区间extent组成.回滚段有顺序的循环的使用这些区间。当当前区间写满的时候，Oracle移向下一个区间. 如一个回滚段有4个区间A,B,C,D;当区间C被写满的时候，oracle将写区间D,而当D写满的时候，oracle将尝试重新写区间A.这样循环的有顺序的使用区间。     事务必须将回滚信息写到回滚段中；事务的当前新产生的回滚信息写在该回滚段的位置叫做回滚段的head. 而在该回滚段上最早发生的尚未提交的事务最早产生的回滚信息所在位置叫做回滚段的tail. 当前区间写满的时候，oracle移动head到下一个区间.     8i时每个事务只能使用一个回滚段。Oracle会根据回滚段workload，平均将事务分配给各个回滚段。在回滚段使用上的一些规则     1.一个事务只能使用一个回滚段。     2. 多个事务可以共用一个区间。但Active的事务不能共用一个block.     3. 回滚段的current extent写满的时候，回滚段的Head不能够移动到回滚段tail所在的区间。     4. 区间总是被有顺序的循环的时候；当head移动的时候，不会跳跃区间；只能移动到下一个区间。     5. 假如head不能够使用下一个区间（如tail在下一个区间），将会分配一个新的区间extent，并将新区间extent插入到这个循环使用的extent圈中。这叫做回滚段的扩展。     ORA-1555 snapshot too old主要是在一致读和延迟块清除delay block cleanout的时候产生；     [参考]一致读的步骤     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.     第5步细分     ---IF 在Transaction Table 中根据Transaction ID 找到transaction
    ------------IF transaction 已经commit
    ------------------------IF query scn>commit scn
    -------------------------------------则接受该块，进行clean out，返回1
    ------------------------ELSEIF query scn    -------------------------------------则进行一致性读，从第6步向后执行
    ------------ELSEIF transaction 没有commit
    ------------------------也进行一致性读，从第6步向后执行     ---ELSEIF 在Transaction Table 中没有找到transaction(undo header中的transaction slot被覆盖了，也说明事务已经提交，因为只有提交后所在的transaction slot才能被覆盖。这样query scn则去比较control scn。在该回滚段上control scn以前的transaction都已经被提交，也就是事务表中所能找到的最小的commit scn了)
    ------------IF query 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
    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. 表示回滚段中回滚信息被覆盖，无法为一致读提供必需的before image。
    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.     出现1555的时候，首先判定是哪个原因导致，可以设置event；假如因为transaction slot被覆盖导致，则增加回滚段数目；假如因为回滚信息被覆盖，则增加回滚大大小。1555错误比较复杂，通常需要考虑很多问题。     event = "1555 trace name processstate forever, level 10"     That will give you a process state dump for any process that gets an ORA-1555 error. The dump will show you which block the process was trying to rollback to its snapshot SCN. If it's a rollback segment header block, then you have your proof. see more from http://www.ixora.com.au/q+a/undo.htm