Redo 和Undo的区别和联系 详细解释

 

Redo和Undo

• Redo及其作用
• Undo及其作用
• Redo与Undo的关系
• 提交和回滚处理
• 基于LogMiner的日志分析

 

1

1.1  Redo及其作用

 

1.1.1Redo的作用是恢复已提交的事务，从而保证无论在介质失败还是实例失败时，都可以恢复用户已提交的事务，使数据库达到一致状态。

1.1.2Redo功能的实现依赖于以下三个组件：

• –Log Buffer
• –LGWR
• –联机重做日志文件和归档日志文件

1.2 Redo数据量的测量

  1.2.1用SQL*Plus内置的AUTORACE功能统计（只能针对简单的DML操作，无法统计存储过程调用等复杂操作的日志信息）：

set autotrace on statistics 
update big_table 
  set object_name=lower(object_name) 
  where rownum<10; 

 

    1.2.2.通过动态性能视图v$mystat检索。例如：

 

select a.name, b.value 
  from v$statname a, v$mystat b 
  where a.statistic# = b.statistic# 
  and lower(a.name) like 'redo size'; 

 

2  Undo及其作用

 

 

 

2.2.1 Undo的作用是：

– 回滚操作；

– 支持读一致性；

– 恢复失败的事务。

2.2.2 Undo的实现是通过Undo表空间内的undo段来实现的。每个事务只被分配一个undo段，undo段可以服务于多个事务。

2.2.3Undo机制只是逻辑地把数据恢复到修改前的状态，而不是物理地恢复。

 

语句中使用以下动态性能视图查询当前事务使用的undo块数：

V$MYSTAT：取得会话ID；

V$SESSION：获取事务地址；

V$TRANSACTION：找出事务使用的undo块数。

事务提交或回滚时会释放undo块占用的空间。

 

select used_ublk 
from v$transaction
where addr = (
   select taddr
   from v$session
   where sid = (
       select sid
       from v$mystat
       where rownum = 1
      )
   );

9.3   Redo与Undo的比较

	Undo	Redo
记录	怎样还原修改	怎样创建修改
用于	回滚、读一致性	前滚、数据库修改
存储于	Undo段	Redo日志文件
保护	多用户系统中的读一致性	损失的数据

 

3.4   undo管理

管理目标是避免出现两种错误：

vORA-01650: unable to extend rollback segment

vORA-01555: snapshot too old

管理方式落实为正确配置三个参数和一个还原表空间属性：

UNDO_MANAGEMENT

UNDO_TABLESPACE

UNDO_RETENTION

RETENTION GUARANTEE

 

9.5  提交和回滚处理

 

commit操作需要的时间很“平”，与事务的大小没有直接关系。

rollback操作所需的时间与事务所修改的数据量直接相关。

因此在设计事务时，不要考虑事务的大小和多少，而应以所执行的操作是否构成一个逻辑工作单元作依据。

 

提交前后完成的操作

 

提交前可能完成的操作

– 在SGA中生成UNDO块

– 在SGA中生成已修改的数据块

– 在SGA中生成前两项对应的redo日志

– 如果需要，前面的某些数据可能已经刷新输出到磁盘

– 得到所需的所有锁

提交时要完成的操作

– 为事务生成SCN

– LGWR把剩余所有缓存重做日志和SCN写入日志文件

– 释放锁

– 对缓冲区中的数据块进行块清理

 

 

回滚前后完成的操作

 

v 回滚前可能完成的操作

– 在SGA中生成UNDO块

– 在SGA中生成已修改的数据块

– 在SGA中生成前两项对应的redo日志

– 如果需要，前面的某些数据可能已经刷新输出到磁盘

– 得到所需的所有锁

v 回滚时要完成的操作

– 撤销已做的所有修改

– 释放锁