客户,会发现由于存在这种优化,你只会等待 LGWR 一次,而不是 100 次。这是不是说可
以在 PL/SQL 中频繁地提交呢?这是一个很好或者不错的主意吗?不是,绝对不是,在
PL/SQ;中频繁地提交与在其他语言中这样做同样糟糕。指导原则是,应该在逻辑工作单元
完成时才提交,而不要在此之前草率地提交。
COMMIT 是一个“响应时间很平”的操作,虽然不同的操作将生成不同大小的 redo,
即使大小相差很大或者说无论生成多少 redo,但也并不会影响提交(COMMIT)的时间或
者说提交所用的时间都基本相同。
9.3.2 ROLLBACK 做什么?
一般地回滚时间是所修改数据量的一个函数。回滚操作的开销很大,这是可以想像的,
因为 ROLLBACK 必须物理地撤销我们所做的工作。类似于 COMMIT,必须完成一系列操
作。在到达 ROLLBACK 之前,数据库已经做了大量的工作。再复习一遍,可能已经发生
的操作如下:
l 已经在 SGA 中生成了 undo 块。
l 已经在 SGA 中生成了已修改数据块。
l 已经在 SGA 中生成了对于前两项的缓存 redo。
l 取决于前三项的大小,以及这些工作花费的时间,前面的每个数据(或某些数
据)可能已经刷新输出到磁盘。
l 已经得到了所需的全部锁。
ROLLBACK 时,要做以下工作:
l 撤销已做的所有修改。其完成方式如下:从 undo 段读回数据,然后实际上逆
向执行前面所做的操作,并将 undo 条目标记为已用。如果先前插入了一行,ROLLBACK
会将其删除。如果更新了一行,回滚就会取消更新。如果删除了一行,回滚将把它再次插
入。
l 会话持有的所有锁都将释放,如果有人在排队等待我们持有的锁,就会被唤醒。
1.4 分析 redo
作为一名开发人员,应该能够测量你的操作生成了多少 redo,这往往很重要。生成的
redo 越多,你的操作花费的时间就越长,整个系统也会越慢。你不光在影响你自己的会话,
还会影响每一个会话。redo 管理是数据库中的一个串行点。任何 Oracle 实例都只有一个
LGWR,最终所有事务都会归于 LGWR,要求这个进程管理它们的 redo,并 BOMMIT 其
事务,LGWR 要做的越多,系统就会越慢。
9.4.1 测量 redo