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
回滚时要完成的操作
–
撤销已做的所有修改
–
释放锁