redo记录信息问题

放过老衲吧

问一下redo记录undo的信息是记录整个块的改变 还是镜像呢？

Maclean Liu(刘相兵

Every redo record captures a logically atomic change to the database. Since one logical change can involve updates to multiple blocks including data blocks, undo blocks and undo segment headers, a redo record typically consists of one or more change vectors.


除非 是热备(hot backup)等特殊状态 否则redo 不会去记录 整个块的景象（Where as in case of begin backup mode, if a transaction happens and changes any block FOR THE FIST TIME, oracle copies the complete block to redo log file），  通常都是记录 change vectors。

SQL> alter system dump logfile '+DATA/vprod/onlinelog/group_2.264.766620031';

SQL> select file#,name from v$datafile;

     FILE#
----------
NAME
--------------------------------------------------------------------------------
         1
+DATA/vprod/datafile/system.490.769483911

         2
+DATA/vprod/datafile/sysaux.489.769483855

         3
+DATA/vprod/datafile/undo22.485.769484051


     FILE#
----------
NAME
--------------------------------------------------------------------------------
         4
+DATA/vprod/datafile/users.488.769483967

         5
+DATA/vprod/datafile/example.486.769484027

         6
+DATA/vprod/datafile/undotbs2.487.769483991


     FILE#
----------
NAME
--------------------------------------------------------------------------------
         7
+DATA/vprod/datafile/undo11.483.769484067                       ==>  一个UNDO 文件的FILE# 是7

         8
+DATA/vprod/datafile/undo22.384.772496035










REDO RECORD - Thread:1 RBA: 0x0000c7.00000107.01e8 LEN: 0x010c VLD: 0x01                      =>RBA
SCN: 0x0001.804c7cb5 SUBSCN: 16 02/22/2012 21:28:00                           
CHANGE #1 TYP:0 CLS:64 AFN:7 DBA:0x01c02dec OBJ:4294967295 SCN:0x0001.804c7cb5 SEQ:14 OP:5.1 ENC:0 RBL:0           operation code 5.1
ktudb redo: siz: 68 spc: 4274 flg: 0x0022 seq: 0x0074 rec: 0x31
            xid:  0x0018.016.00015746
ktubu redo: slt: 22 rci: 48 opc: 11.1 objn: 423 objd: 421 tsn: 0         => object number
Undo type:  Regular undo       Undo type:  Last buffer split:  No
Tablespace Undo:  No
             0x00000000
KDO undo record:
KTB Redo
op: 0x02  ver: 0x01                        
compat bit: 4 (post-11) padding: 1
op: C  uba: 0x01c02dec.0074.2f             [size=-1] Undo Byte Address (UBA)
KDO Op code: DRP row dependencies Disabled
  xtype: XA flags: 0x00000000  bdba: 0x00418579  hdba: 0x00400a80
itli: 2  ispac: 0  maxfr: 4863
tabn: 1 slot: 7(0x7)
CHANGE #2 TYP:0 CLS:1 AFN:1 DBA:0x00418579 OBJ:421 SCN:0x0001.804c7cb5 SEQ:8 OP:11.2 ENC:0 RBL:0
KTB Redo
op: 0x02  ver: 0x01
compat bit: 4 (post-11) padding: 1
op: C  uba: 0x01c02dec.0074.31
KDO Op code: IRP row dependencies Disabled
  xtype: XA flags: 0x00000000  bdba: 0x00418579  hdba: 0x00400a80
itli: 2  ispac: 0  maxfr: 4863
tabn: 1 slot: 7(0x7) size/delt: 22                                                                                                                  
fb: -CH-FL-- lb: 0x2  cc: 4 cki: 0                                                                                                                  
null: ----                                                                                                                                          
col  0: [ 2]  c1 07                                                                                                                                 
col  1: [ 1]  80                                                                                                                                    
col  2: [ 3]  c2 07 5b                                                                                                                              
col  3: [ 8]  d2 2c 4f 16 1b 2c 36 5b


  operation code 5.1 update transaction table in undo segment header

放过老衲吧

那redo里面有undo吗？   如果有的话  那是不是 redo里面只指向undo 的指针 而不是具体的改变呢？

Maclean Liu(刘相兵

redo 记录的 是 change vector ， 不会有 指向undo的指针。

放过老衲吧

redo 里的change vector 是什么意思，是对物理块的逻辑操作么？

Maclean Liu(刘相兵

那redo里的UBA是什么作用 ？


若redo 中没有UBA ，则 在前滚时(roll forward) 时 无法恢复 数据块头中ITL的 UBA信息， 如果没有完整的ITL 那么显然 前滚完成后 也无法继续完成回滚 roll back 。 所以redo中 要记录 scn和 uba。


redo 里的change vector 是什么意思？

Change Vector

Describes a change to a single data block

Can apply to
undo headers
undo blocks
data segment headers
data blocks

Is created in PGA before the data block buffer is modified

Consists of
header
array of change record lengths
array of change records

放过老衲吧

那这样的话，那undo产生的过多 undo段被覆盖了 怎么办

Maclean Liu(刘相兵

若redo 中没有UBA ，则 在前滚时(roll forward) 时 无法恢复 数据块头中ITL的 UBA信息， 如果没有完整的ITL 那么显然 前滚完成后 也无法继续完成回滚 roll back 。 所以redo中 要记录 scn和 uba。


=> 需要被rollback的事务 或者是active 的 或者是 dead transaction ， 这2种事务的undo 均不能在commit 或者 rollback之前被 覆盖。

放过老衲吧

那比如说这样一种场景： 一个事务特别大，直接把undo段占满还不够，这时候数据库会怎么办？ 难道redo里的UBA最终不是落实到undo表空间的undo段么

Maclean Liu(刘相兵

一个事务特别大，直接把undo段占满还不够，这时候数据库会怎么办？


redo 是 对oracle数据块物理变化的记录。

一个事务特别大 把undo表空间占满了， 此时另一个事务发起 无法 因为无法申请到 rollback segment ， 该事务直接失败； 不明白你想假设什么

放过老衲吧

数据库不会挂起吗  我有一次貌似是挂起了

Maclean Liu(刘相兵

数据库不会挂起吗  我有一次貌似是挂起了？

undo 空间不足可能导致 事务发起失败，  至于是否 会导致 实例挂起 instance hang 需要视乎实际情况 ，一般是不会的。

放过老衲吧

C:\Users\guoning\Desktop\undo.jpgundo.jpg
看到图片了么，这个UBA实际上是对物理块的操作，操作的同时会记录UBA，最终前滚的时候会查找UBA，最终完成回滚。是这样的吧，最终UBA先到undo段中去找，最终完成恢复。

Maclean Liu(刘相兵

前滚完成之后 才会 回滚
前滚和 UBA没有太大的关系
在 redo 看来 UBA也只是 change record的一部分

teapot

update一条记录时，
change_vector有两种，一是往undo写数据前景象的change_vector，另一个就是更新的数据文件的change_vector。
这个从dump redo时就会看到。

而回滚时，undo的change_vector应该只是修改事务表状态的，数据应该是从undo中前景象的change_vector
这个没有测试，猜想

[ 本帖最后由 teapot 于 2012-2-23 11:34 编辑 ]

Maclean Liu(刘相兵

rollback 回滚（或者说 transaction recovery) 是不依赖于 redo 重做日志的

用一个简单的实验证明， 非归档模式下 shutdown abort一个事务， 利用10513  event 禁止SMON 做trans recovery 事务回滚， 之后多次切换日志，将相关的redo logfile 覆盖掉， 取消10513 event ，  SMON会顺利做完 trans recovery 事务回滚



SQL> alter database open;

Database altered.

SQL> archive log list
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     0
Current log sequence           1


SQL> create table need_rollback(maclean int);

Table created.

SQL> insert into need_rollback values(1);

1 row created.


SQL> select xidusn,xidslot,xidsqn from v$transaction;

    XIDUSN    XIDSLOT     XIDSQN
---------- ---------- ----------
         1         19       2671


XIDSUN 1  XIDSLOT 19  XIDSQN 2671



SQL> alter system checkpoint;

System altered.

SQL> shutdown abort;
ORACLE instance shut down.


SQL> startup nomount;
ORACLE instance started.

Total System Global Area  620756992 bytes
Fixed Size                  2022760 bytes
Variable Size             234881688 bytes
Database Buffers          377487360 bytes
Redo Buffers                6365184 bytes


SQL> alter system set event='10500 trace name context forever,level 8:10513 trace name context forever, level 2' scope=spfile;

System altered.



SQL> startup force;
ORACLE instance started.

Total System Global Area  620756992 bytes
Fixed Size                  2022760 bytes
Variable Size             234881688 bytes
Database Buffers          377487360 bytes
Redo Buffers                6365184 bytes
Database mounted.
Database opened.



*** 2012-03-11 04:46:44.309
SMON: Event 10513 is level 2, trans recovery disabled.
*** 2012-03-11 04:46:44.372
SMON: system monitor process posted
*** 2012-03-11 04:46:44.372
SMON: Event 10513 is level 2, trans recovery disabled.
*** 2012-03-11 04:46:44.388
SMON: system monitor process posted
*** 2012-03-11 04:46:44.388
SMON: Event 10513 is level 2, trans recovery disabled.
~                                                               


SMON 发现需要rollback的事务，但是10513   禁止它做 trans recovery 的rollback


SQL> set linesize 200 pagesize 2000
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1          2   52428800          2 NO  CURRENT               15235919 11-MAR-12
         2          1          1   52428800          2 NO  INACTIVE              15169884 09-MAR-12
         3          1          0   52428800          2 YES UNUSED                       0


SQL> alter system switch logfile;

System altered.

SQL> /

System altered.

SQL> /

System altered.

SQL> /

System altered.

SQL> /

System altered.

SQL> alter system checkpoint;

System altered.

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1          5   52428800          2 NO  INACTIVE              15236104 11-MAR-12
         2          1          7   52428800          2 NO  CURRENT               15236108 11-MAR-12
         3          1          6   52428800          2 NO  INACTIVE              15236106 11-MAR-12
                 

之前的日志都被覆盖了， 取消10513 event

SQL> alter system set event='10500 trace name context forever,level 8' scope=spfile;

System altered.




SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.



SQL> startup;
ORACLE instance started.

Total System Global Area  620756992 bytes
Fixed Size                  2022760 bytes
Variable Size             234881688 bytes
Database Buffers          377487360 bytes
Redo Buffers                6365184 bytes
Database mounted.
Database opened.


SMON: system monitor process posted
Dead transaction 0x0001.013.00000a6f recovered by SMON
                 

事务被SMON 正常 回滚

0x0001.013.00000a6f =>  USN 1 XIDSLOT 19 XIDSQN 2671

Maclean Liu(刘相兵

10513  禁止 SMON 做trans recovery

使用 _offline_rollback_segments和 _CORRUPTED_ROLLBACK_SEGMENTS 禁止 consistent read reference UNDO/Rollback Segment

Maclean Liu(刘相兵

更新数据块 生成相关redo 产生了脏块  脏块未写入数据文件 ， 未commit或 未成功  redo在buffer里 未写出 =》　断电，redo丢失 但是没有commit 所以丢失脏块 无所谓， 没有数据丢失

更新数据块 生成相关redo 产生了脏块 脏块未写入数据文件， commit成功了 redo 必然写出到 日志文件 =》断电，　redo不丢失 =》前滚， 没有数据丢失  


更新数据块 生成相关redo 产生了脏块 脏块已写入到数据文件 ，DML redo先于脏块写出， 未commit或 commit不成功 =》断电，　＝》前滚　后回滚　

更新数据块生成相关redo 产生了脏块 脏块已写入到数据文件  ，DML redo先于脏块写出， commit成功   。


commit 要么成功 要么失败， 不存在第三种状态

Maclean Liu(刘相兵

redo 中change record里的uba，　其主要目的同样是为了　前滚　rolling forward:

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
www.oracledatabase12g.com


SQL> Alter database add supplemental log data;

Database altered.



SQL> alter system switch logfile;

System altered.



SQL>  select * from v$Log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
         1          1         41   52428800          2 NO  CURRENT               15356105 12-MAR-12
         2          1         40   52428800          2 YES INACTIVE              15356103 12-MAR-12
         3          1         39   52428800          2 YES INACTIVE              15355949 12-MAR-12
         
         
SQL> create table simu_change (mac1 varchar2(200));

Table created.


SQL> select dump('I AM RECORD HAS BEEN CHANGED',16) from dual;

DUMP('IAMRECORDHASBEENCHANGED',16)
--------------------------------------------------------------------------------
Typ=96 Len=28: 49,20,41,4d,20,52,45,43,4f,52,44,20,48,41,53,20,42,45,45,4e,20,43
,48,41,4e,47,45,44

SQL> insert into simu_change values('I AM RECORD HAS BEEN CHANGED');

1 row created.




SQL> alter system checkpoint;

System altered.


SQL> select header_file,header_block from dba_segments where segment_name='SIMU_CHANGE';

HEADER_FILE HEADER_BLOCK
----------- ------------
          1       250993


SQL> alter system dump datafile 1 block 250994;

System altered.

SQL> oradebug setmypid;
Statement processed.
SQL> oradebug tracefile_name;
/s01/admin/G10R21/udump/g10r21_ora_22373.trc



Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0008.001.00000db8  0x0480017f.036d.05  ----    1  fsc 0x0000.00000000
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000


data_block_dump,data header at 0x798a65c
===============
tsiz: 0x1fa0
hsiz: 0x14
pbl: 0x0798a65c
bdba: 0x0043d472
     76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x1f80
avsp=0x1f6c
tosp=0x1f6c
0xeti[0]      nrow=1  offs=0
0x12ri[0]     offs=0x1f80
block_row_dump:
tab 0, row 0, @0x1f80
tl: 32 fb: --H-FL-- lb: 0x1  cc: 1
col  0: [28]
49 20 41 4d 20 52 45 43 4f 52 44 20 48 41 53 20 42 45 45 4e 20 43 48 41 4e
47 45 44
end_of_block_dump
End dump data blocks tsn: 0 file#: 1 minblk 250994 maxblk 250994


SQL> alter system dump logfile '/s01/oradata/G10R21/onlinelog/o1_mf_1_7ch812dg_.log';

System altered.


转储current logfile

SQL> oradebug setmypid;
Statement processed.
SQL> oradebug tracefile_name;
/s01/admin/G10R21/udump/g10r21_ora_22378.trc


找到 INSERT 对应的change record

REDO RECORD - Thread:1 RBA: 0x000029.0000000d.0140 LEN: 0x01c0 VLD: 0x01
SCN: 0x0000.00ea50e0 SUBSCN:  4 03/12/2012 13:56:56
...................................................


CHANGE #3 TYP:0 CLS: 1 AFN:1 DBA:0x0043d472 OBJ:56082 SCN:0x0000.00ea50e0 SEQ:  3 OP:11.2
KTB Redo
op: 0x01  ver: 0x01
op: F  xid:  0x0008.001.00000db8    uba: 0x0480017f.036d.05
KDO Op code: IRP row dependencies Disabled
  xtype: XA flags: 0x00000000  bdba: 0x0043d472  hdba: 0x0043d471
itli: 1  ispac: 0  maxfr: 4863
tabn: 0 slot: 0(0x0) size/delt: 32
fb: --H-FL-- lb: 0x1  cc: 1
null: -
col  0: [28]
49 20 41 4d 20 52 45 43 4f 52 44 20 48 41 53 20 42 45 45 4e 20 43 48 41 4e
47 45 44


这里的 xid 和uba 用来 rolling forward (or recovery) block header中的 ITL ， 一条ITL 包含了 XID 和 UBA 记录：


xid:  0x0008.001.00000db8    uba: 0x0480017f.036d.05   itli: 1

  Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0008.001.00000db8  0x0480017f.036d.05  ----    1  fsc 0x0000.00000000


如果redo 只记录 变化的数据如 op code :INSERT DATA: 49 20 41 4d 20 52 45 43 4f 52 44 20 48 41 53 20 42 45 45 4e 20 43 48 41 4e 47 45 44， 显然不足以物理上恢复整个块。
所以 uba 和 xid 对前滚是必要的。

Maclean Liu(刘相兵

Oracle Database stores undo data inside the database rather than in external logs. Undo data is stored in blocks that are updated just like data blocks, with changes to these blocks generating redo.

In this way, Oracle Database can efficiently access undo data without needing to read external logs.

rolling forward 依赖于redo ， rolling forward 完成后 可以开始 begin trans recovery(Rolling back) ，并打开数据库 OPEN DATABASE， OPEN DATABASE不需要等待 Rolling Backup 完成。

trans recovery(Rolling back) 不依赖于 redo (external logs)， 前滚完成后 Undo是consistent的， SMON 直接SCAN Undo Segment header 就可以知道哪些Transaction Need Recover(Rollback)，  即回滚 不依赖于 redo。

lghwf

UNDO 信息在写入磁盘之前 是不是也是要先写到SGA缓存里呢？ 如果这样会不会也象普通的脏数据块一样 还没有写出磁盘，数据库DOWN了 而发生丢失UNDO信息的事情呢？
  这种情况下，INSTANCE RECOVERY  进行前滚的时候，系统是不是利用REDO 里的信息重构随后的ROLL BACK 用到的UNDO 信息呢？
  这几天实在是为此事困惑，REDO里 到底有没有BEFORRE IMAGE数据呢？
官方文档里 哪部分资料 对这个 REDO &UNDO 说的比较详细呢 ？ 自己瞎琢磨 确实挺困惑

[ 本帖最后由 lghwf 于 2012-3-15 19:08 编辑 ]