2.解读DSI——DSI301 回滚段恢复相关
回滚段是RDBMS的核心，用于回滚恢复和读一致性。
如果回滚段发生崩溃，数据库的可用性就会受到影响。如果没有提前准备纠正措施，那么就不可能恢复数据一致性了。
1 关于事务交易
当一个SLOT在交易表的回滚段头中分配，标志交易开始。
这个是交易的物理表现。交易ID（txid）指向这个位置。
Txid=usn.slot.wrap（undo_segment_number.transaction_slot_id.SCN_wrap）
交易开始插入，更新，删除一个行之前，一个ITL分配在包含该行的块中。
ITL用于标记行被锁住，直到交易提交或者回滚。ITL包含了交易的ID。
当已更改到块中，undo信息也产生了被存储在回滚段中。交易表slot包含指向UNDO的指针。当查询v$lock，usn.slot显示id1,wrap显示为id2.
2 读一致性
如果一个不同的会话要读同一个块，而第一个交易没有提交。
该会话读该块（很大可能还在CACHE中），找到打开的ITL，检查交易状态（通过读回滚段头）发现还是激活的。意味着会话必须回滚一个活动交易改变的快照。这个叫做一致性读（CR consistent read）副本，这个通过克隆一个块，然后通过回滚段中的undo records来回滚最新的改变。
CR请求需要访问数据块，回滚段头，回滚记录。如果其中崩溃，CR就会受到影响。
3 交易锁
如果其他一个会话要去改变或删除被第一个交易更新的行。第一个交易没有提交。
新的会话会读块发现打开的ITL，检查状态（读回滚段头）发现还是活动的。会话不能在这个阶段进行改变，需要等待这个交易提交或者回滚。
注意：必须读回滚段头来建立ITL的状态，如果回滚段头奔溃，那么锁就会影响。
4 交易提交
假设第一个交易提交。该事件通过标记交易表的SLOT为非活动的。但是块本身可能后续才会更新。说明块中的ITL在提交后还是打开一段事件。
当RDBMS下一次读这个交易表的时候，提交被确认，ITL关闭。这个叫做延时块清除。如果回滚段已经被删除了，undo$中的SCN记录用来确认这个提交。
RDBMS必须读回滚段头来执行块延时清除，如果回滚段崩溃，块延时清除就会影响。
从7.3版本开始，新的特性叫做loggin block cleanout(DLBC)改变了RDBMS行为（8.1.3版本C上没有该参数，特性直接合入了RDBMS）。
5 交易恢复
当一个回滚命令执行，RDBMS反向扫描当前交易的UNDO记录，并执行。当语句返回，所有块改变撤消，同时ITL被清除。回滚时候不会延迟。
回滚需要访问回滚段头，数据块，如果其中任何发生崩溃，回滚就会发生影响。
执行回滚会产生新的 REDO，写入到REO LOG。
6 交易恢复：进程崩溃
如果进程在有活动交易的时候崩溃，PMON会检查到并立刻进行回滚。
可以通过设置如下事件来启动监控相关事件。10012事件,10246事件。
7 交易恢复：实例崩溃
如果事务在提交前，实例崩溃，PMON来不及进行回滚事务。当下一次数据库打开，先进行前滚到崩溃状态然后再回滚所有没有不完整的交易。
8 交易恢复：数据库打开
RDBMS在不干净关闭后快速启动。如果新的交易想通过一个dead transaction来更新行，交易会自己进行回滚而不需要等SMON来处理。
在7.2版本之前，数据库打开之前所有活动的交易都要回滚，如果回滚段崩溃数据块就不能够启动了。
7.3版本后修正一些，数据块打开的，如果回滚段异常，会将错误记录到alert和trace文件。这样便于诊断错误。当ORACLE 8，如果回滚段头是崩溃的，也是不能打开数据库的。
数据库在打开的时候，所有的回滚段都会进行检查。
9 诊断事件
10013：在数据库启动阶段监控交易恢复
10015：在交易恢复前后dump回滚段头
