块清除 block cleanout 删除被修改数据块上的锁相关信息。
锁是数据的属性，存储在block的块首部。
修改了某一个数据块，在某些情况（什么情况？）下没有在事务结束时区清理上面的锁信息，在下一次访问该block时就会触发清理锁信息，也就是select也会产生block的修改即产生redo。
事务伴随着一个提交列表，Oracle根据这个列表统计记录被修改的block，每个列表跟踪20个block，根据需要分配若干个列表，直到某个临界点，如果修改的block超过了预期块缓存区的10%大小，也就是一定的阈值，就会停止分配新列表。
例如：缓冲区缓存大小（db_cache_size）设置为3000个block，如果修改的块数没有超过300（3000*10%=300）个block，并且这些block依旧在缓冲中可用，那么就会在事务commit时，清理这些块，否则不清理。
日志竞争 log centention
cannot allocate new log 一般导致log file sync或者log file parallel write等待事件增多。
产生的原因是重做日志写的不够快。
- redo log所在设备io性能不佳，比如设备本身性能不佳或者使用了raid-5技术。
- redo log和其他频繁访问的文件在同一设备，存在系统io竞争。
ORA-01555 snapshot too old
- undo段太小，不足以支撑
- 块清除
常见解决方案：
- 延长undo_retention
- 手动加大undo段
- 尽可能减少select语句的时间
- 收集相关对象的统计信息，这步时主动地完成块清除。
块清除过程：Oracle从块首部读出前一个事务所用的undo段，然后去undo首部查看该事务是否已提交，如果已提交，则去确认什么时间点提交的，如果undo段事务表的事务槽被覆盖了，那么可以确定很久之前提交了，另一种情况是commit scn存在undo段的事务表中，表明该事务刚刚提交，事务槽尚未被覆盖。
某个时刻发起修改数据并提交，其中某些块在commit时没有完成自动的提交清除锁相关信息
此时一个select开始并且记录此时的select scn记为T1，并且期间没有其他会话触及这些未修改锁相关信息的block
长时间的select正在继续，会读取到上面涉及到的一些block，并且必须将数据回滚到T1时刻的select scn进行查询，读一致性，开始查询的时候，第一条对应的事务信息包含事务槽尚在undo段里。
在这个select完成期间，发起了其他多次的commit，这些commit仍未触及这些未修改的block的锁信息，此时undo段的事务表会开始重用，即覆盖第一条对应的事务槽，一开始生产的那些undo数据也逐渐被覆盖，因为事务已经commit，这时undo 数据可以被覆盖。此外，由于commit的次数增加，undo段中记录的最小的scn此时已经大于select发起的T1的select scn。
正常情况下，是回到block所指的undo段，获取其中的commit scn，比较commit scn和select scn的大小知道先后顺序，如果是先修改提交，后select，那么没有问题，直接使用该commit scn的block，如果是先select，后修改提交，那么判断依据就是commit scn>select scn,所以需要应用undo回滚该block到select scn时刻进行数据的反馈，但是，这个时候的情况是，这个block所指的undo段已经被覆盖，无法获知其中的commit scn，进而无法比较commit scn和select scn的大小，最终无法确定能否使用最低scn已经超过T1时刻的undo数据，所以干脆爆出一个快照过旧，避免错误的select，另外一种意义上这是一个为了安全的报错
从上可以看出通过块清除发生的快照过旧的条件有点苛刻，但是肯定有这种情况发生，当发生这种情况时，我们就应当做一些措施来避免，毕竟谁也不想跑了很久的select结果报错，没有反馈预期的结果。
- 保证事务没有频繁提交，避免undo段的频繁回绕覆盖
- 适当进行相关对象的统计信息收集
- undo段适当扩大或者适当加大undo_retention
- 减少select的时间，并且最好的办法就是如此
PS:以上均为个人学习之后的理解，如有错误，恳请指正。
学习来源：《Oracle编程艺术第三版》
