REDO是保证我们数据库交易安全最重要的保证
REDO LOG BUFFER记录了数据库块的所有变更,它的主要内容有:
主要目的是用来数据库恢复
在块中改动的记录我们称REDO 记录
REDO实体包括了重构数据的信息
大小由LOG_BUFFER参数决定
SQL> show parameter log_buffer
主要目的是用来数据库恢复
在块中改动的记录我们称REDO 记录
REDO实体包括了重构数据的信息
大小由LOG_BUFFER参数决定
SQL> show parameter log_buffer
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_buffer integer 2879488
SQL>
------------------------------------ ----------- ------------------------------
log_buffer integer 2879488
SQL>
Redo log buffer是为了避免Redo文件IO导致性能瓶颈而在sga中分配出的一块内存。
一个redo条目首先在用户内存(PGA)中产生,然后由oracle服务进程拷贝到log buffer中,
当满足一定条件时,再由LGWR进程写入redo文件
一个redo条目首先在用户内存(PGA)中产生,然后由oracle服务进程拷贝到log buffer中,
当满足一定条件时,再由LGWR进程写入redo文件
___________________
|block 33 slot 0 |
|------------------
|ename scott |
|------------------
|empno 7788 |
|------------------
|block 33 slot 0 |
|------------------
|ename scott |
|------------------
|empno 7788 |
|------------------
___________________
|block 33 slot 1 |
|------------------
|ename king |
|------------------
|empno 7839 |
|------------------
|block 33 slot 1 |
|------------------
|ename king |
|------------------
|empno 7839 |
|------------------
执行 update emp set empno=7777 where ename='KING';
则得到这样的redo:
____________________________________
| 5.2 | slot 18: 10 回滚段事务信息|
|-----------------------------------
| | block 33 solt 1 |
| 5.1 |-----------------------------
| | empno : 7839 undo的redo |
|-----------------------------------
| | block 33 slot 1 |
|11.5 |-----------------------------
| | empno | 7777 redo的redo |
|-----------------------------------
5.2、5.1、11.5分别表示我这次REDO的操作类型
5.2是设置事务表状态为活动,并记录REDO值是10,10表示是该事务是ACTIVE的。
5.1操作是写UNDO记录,它把原来字段empno的值7839改成7777,
7839值要作为UNDO RECORD保存在REDO里,它涉及的块号是33块
11.5 是数据块修改的操作,将块号33的块的特定行的empno列改成7777
5.2是设置事务表状态为活动,并记录REDO值是10,10表示是该事务是ACTIVE的。
5.1操作是写UNDO记录,它把原来字段empno的值7839改成7777,
7839值要作为UNDO RECORD保存在REDO里,它涉及的块号是33块
11.5 是数据块修改的操作,将块号33的块的特定行的empno列改成7777
这就是REDO信息,图中相对简单很多,实际信息量要比这个图多
存储的信息叫向量,我们发现写UNDO的REDO比REDO的REDO早,就是为了保证能回退。
存储的信息叫向量,我们发现写UNDO的REDO比REDO的REDO早,就是为了保证能回退。
假设有一张t1表 x列一行数据是 1,假设存储在4号文件的11号块中
依次修改这个数据
update t1 set x=2;
update t1 set x=3;
update t1 set x=4;
update t1 set x=5;
commit;
update t1 set x=6;
update t1 set x=7;
update t1 set x=8;
update t1 set x=9;
断电
假设当前这个表的数据脏块还在buffer_cache里就断电,磁盘上的块内容依旧是1
每次update操作前会将改前影像存到undo中,所以这时的redo信息如下:
每次update操作前会将改前影像存到undo中,所以这时的redo信息如下:
redo的redo---->2345提交6789---\
---> into redo
undo的redo---->1234提交5678---/
---> into redo
undo的redo---->1234提交5678---/
那么下次实例启动发现数据不一致就需要恢复
读出4号文件的11号块 发现内容比较老 是1
接着找到对应的redo开始前滚,前滚的过程就是2代替1,3代替2,4代替3....一直滚到9,
数据库打开,发现事务未提交,数据库再根据undo的redo回滚,8代替9,7代替8,6代替7,5代替6,发现commit,回滚停止.
释放这个数据块资源
读出4号文件的11号块 发现内容比较老 是1
接着找到对应的redo开始前滚,前滚的过程就是2代替1,3代替2,4代替3....一直滚到9,
数据库打开,发现事务未提交,数据库再根据undo的redo回滚,8代替9,7代替8,6代替7,5代替6,发现commit,回滚停止.
释放这个数据块资源
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24756465/viewspace-717613/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/24756465/viewspace-717613/