书名书名书名书名书名书名书名书名书名书名书名书名书名书名
·2·
程本身也要产生 Redo,所以回退这个操作是很昂贵的。
在 Oracle 的性能优化中,有一个性能指标称为平均事务回滚率(Rollback per transaction),
用来衡量数据库的提交与回滚效率。在 Statspack 的报告中,可以从开头部分找到这个指标:
Load Profile
~~~~~~~~~~~~
% Blocks changed per Read: 0.37 Recursive Call %: 1.14
Rollback per transaction %: 38.22 Rows per Sort: 11.83
该参数计算公式如下:
Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%
其中 user commits 和 user rollbacks 数据来自系统的统计信息,可以从 V$SYSSTAT 视图
中得到,在 Statspack 中也包含着部分数据的输出,本例选择的报告相关部分摘录如下:
user commits 31,910 12.9 0.6
user rollbacks 19,740 8.0 0.4
按照公式计算就可以得出平均事务回滚率:
Round(19740 / (31910 + 19740),4) = .3822
这个指标应该接近于 0,如果该指标过高,则说明数据库的回滚过多。回滚过多不仅说明
数据库经历了太多的无效操作,而且这些操作会极大影响数据库性能。
8.2 回滚段存储的内容
在上一章中讲过,REDO 中只会记录少量信息,这些信息足以重演事务;同样 UNDO 中
也只记录精简信息,这些信息足以撤消事务。
对于 insert 操作,回滚段只需要记录插入记录的 rowid,如 果 回 退 ,只 需 将 该 记 录 根 据 rowid
删除即可;对于 update 操作,回滚段只需要记录被更新字段的旧值即可(前镜像),回退时通
过旧值覆盖新值即可完成回退;对于 delete 操作,Oracle 则必须记录整行的数据,在回退时,
Oracle 通过一个反向操作恢复删除的数据。
通过以上介绍可以简单总结一下:对于相同数据量的数据操作, 通常 insert 产生最少的
UNDO, update 产生的 UNDO 居中,而 delete 操作产生的 UNDO 最多。这也就是我们经常看到
的,当一个大的 Delete 操作失败或者回滚,总是需要很长的时间,并且会有大量的 redo 生成。
所以通常在进行大规模数据删除操作时,推荐通过分批删除分次提交,以减少对于回滚段的占
用和冲击。
回滚段在 UNDO 表空间中分配,其数据在 Buffer Cache 内存中的管理方式与用户数据一
致,同样按照相同的规则写出到 Undo 表空间的数据文件上。UNDO 表空间中的存储空间同样
按照 Segment 来分配和使用。下图显示的就是回滚段的机制与原理示意,回滚段的作用除了回
退事务外,还要参与事务恢复,以及提供读一致性。
因为 UNDO 数据要参与事务恢复,所以在备份数据库时一定要包含 UNDO 表空间,而且
一旦 UNDO 表空间损坏会丢失,那么数据库将会出现故障,需要进行介质恢复来恢复相关数
据文件:
评论