Focus On Oracle

Installing, Backup & Recovery, Performance Tuning,
Troubleshooting, Upgrading, Patching


当前位置: 首页 » 技术文章 » 备份恢复

Rolling forward/Rolling Back Undo/Redo

system change number (SCN) is a logical, internal time stamp used by Oracle Database. SCNs order events that occur within the database, which is necessary to satisfy the ACID properties of a transaction. Oracle Database uses SCNs to mark the SCN before which all changes are known to be on disk so that recovery avoids applying unnecessary redo. The database also uses SCNs to mark the point at which no redo exists for a set of data so that recovery can stop.


There are four type SCN in Database
System Checkpoint  SCN --->V$DATABASE -->X$KCCDI,X$KCCDI2    
Datafile Checkpoint SCN ---
                           \
                            --->v$Datafile -->X$KCVDF
                           /
               Stop SCN ---
              Start SCN --->v$Datafile_Header -->X$KCVFH
              

通过White Paper我们可以看到这些视图的定义              
V$DATABASE displays information about the database from the control file.
CHECKPOINT_CHANGE#,Last SCN checkpointed.It's the earliest thread checkpoint_change# from all open threads.

V$DATAFILE displays datafile information from the control file.
CHECKPOINT_CHANGE#,SCN at last checkpoint
      LAST_CHANGE#,Last change number made to this data file (null if the data file is being changed)

V$DATAFILE_HEADER displays data file information from the data file headers.
CHECKPOINT_CHANGE#,Data file checkpoint change#

在正常Shutdown情况下,会触发Checkpoint,并且把SCN纪录写回。数据库在Open时,Oracle会检查Datafile Header中的Start Scn和ControlFile中Datafile的Scn是否一致,如果一致,会继续检查Start Scn和Stop Scn是否一致,如果仍然相同,数据库就会正常开启,否则就需要Recovery。

在非正常Shutdown情况下,不会触发Checkpoint,下次启动时必须进行Crash Recovery。

数据库启动

A.首先会检测数据文件头部和控制文件中数据文件Checkpoint Count。如果两者不一致,则说明数据文件或者控制文件是通过备份还原的。Datafile Header的Start SCN当然也就不等于储存于ControlFile中Datafile的SCN(还存在需要的数据文件不存在这种可能性),则需要进行Media Recovery。如果相同,会继续B操作

Note:Checkpoint Count,她是一直递增的,即使表空间处于HotBackuMode(热备时文件的Checkpoint Change会被Frozen),她存在于数据文件头部和控制文件中数据文件部分,如果两者不匹配,说明控制文件/数据文件是通过备份还原的。不同表空间/数据文件的Checkpoint Count一般是不同的,因为创建的时间不一样。

B.检查数据文件头的开始SCN和控制文件中对应的数据文件的结束SCN是否一致。如果一致,打开数据库.。将每个数据文件的结束SCN设置为无穷大.

    如Stop Scn is Null则需要进行Crash Recovery(正常运行时Stop SCN为空,表示SCN正在改变。如果是关闭状态,Stop SCN为空的话表示数据库非正常关闭)


Recovery
数据库Crash瞬间,Buffer Cache中可能存在一部分脏数据块还没有被Flush到数据文件中,还可能存在正在执行的事务,这些事务可能没有Commit/Rollback,这时的数据库是不一致的。下次启动时,会由SMON进程自动进行实例恢复,会从控制文件中获得检查点(恢复的起点为low cache rba,恢复的终点为on disk rba)位置,并找到在Redolog File中这个点,应用所有的从这个点开始的Redo Record,这个称为Rolling Forward。前滚完成后,然后会把扫描到的之前没有Commit的事务回退,这个称为Rolling Back。

Note:Redo中记录的有数据库块的修改信息、数据块的Undo信息、Commit标志等。Crash之后,在下次启动时,Oracle会读取Redo日志,Apply那些已提交但还未更新到数据块的Redo(即Roll Forward)。然后根据Redo中记录的Undo信息,回滚那些没有Commit/Rollback的事务,最后打开数据库。Redo的前滚也是Undo的回滚,即Commit的重新写入,未Commit的回滚

Undo和Redo


UNDO REDO
Record of How to undo a change How to reproduce a change
Used for Rollback, Read-Consistency Rolling Forward DB Changes
Stored in Undo segments Redolog files
Protect Against Inconsistent reads in multiuser systems Data loss

当一个事务执行时,第一件事情是要找一个地方存放Undo信息。这些Undo信息存放在Undo tablespace或Rollback segment(9i之前)。Oracle存放Undo的方式存放像Table/Index一样,只不过Undo中记录的是Transaction Table信息,事务提交时会更新transaction table的信息。这些回滚段的object_id为4294967295(可通过x$bh/v$bh查看),通过dba_objects是查不到这些回滚段的信息。

SQL> select file#,block#,class#,status,dirty,objd from v$bh where objd=4294967295 and file#=1;
     FILE#     BLOCK#     CLASS# STATUS     D       OBJD
---------- ---------- ---------- ---------- - ----------
         1          3         12 xcur       N 4294967295
         1        557         16 xcur       N 4294967295
         1          2         13 xcur       N 4294967295
         1          2         13 xcur       N 4294967295
         1        128         15 xcur       N 4294967295
SQL> 

查询Undo block的脏块

SQL> select file#,block#,class#,status,dirty,objd from v$bh where objd=4294967295 and dirty='Y' and rownum <5;
     FILE#     BLOCK#     CLASS# STATUS     D       OBJD
---------- ---------- ---------- ---------- - ----------
         3       2517         36 xcur       Y 4294967295
         3        272         35 xcur       Y 4294967295
SQL>

回滚段有2中类型,包含SYSTEM回滚段和Undo表空间的回滚段,SYSTEM回滚段主要用于系统用户,普通用户不能使。如果你有兴趣,可以把undo_tablespace修改为SYSTEM测试

SQL> select owner,segment_name,segment_type,header_file,header_block,blocks from dba_segments where segment_type in ('ROLLBACK','TYPE2 UNDO');
OWNER      SEGMENT_NAME                   SEGMENT_TYPE       HEADER_FILE HEADER_BLOCK     BLOCKS
---------- ------------------------------ ------------------ ----------- ------------ ----------
SYS        SYSTEM                         ROLLBACK                     1          128         48
SYS        _SYSSMU1_3724004606$           TYPE2 UNDO                   3          128        144
SYS        _SYSSMU2_2996391332$           TYPE2 UNDO                   3          144         48
SYS        _SYSSMU3_1723003836$           TYPE2 UNDO                   3          160         56
SYS        _SYSSMU4_1254879796$           TYPE2 UNDO                   3          176        272
SYS        _SYSSMU5_898567397$            TYPE2 UNDO                   3          192        144
SYS        _SYSSMU6_1263032392$           TYPE2 UNDO                   3          208         40
SYS        _SYSSMU7_2070203016$           TYPE2 UNDO                   3          224        144
SYS        _SYSSMU8_517538920$            TYPE2 UNDO                   3          240        144
SYS        _SYSSMU9_1650507775$           TYPE2 UNDO                   3          256        144
SYS        _SYSSMU10_1197734989$          TYPE2 UNDO                   3          272        144
SYS        _SYSSMU11_1873760281$          TYPE2 UNDO                   5          128         16
SYS        _SYSSMU12_3386349400$          TYPE2 UNDO                   5          144         16
SYS        _SYSSMU13_1203648601$          TYPE2 UNDO                   5          160         16
SYS        _SYSSMU14_3485357423$          TYPE2 UNDO                   5          176         16
SYS        _SYSSMU15_2310594585$          TYPE2 UNDO                   5          192         16
SYS        _SYSSMU16_3215538254$          TYPE2 UNDO                   5          208         16
SYS        _SYSSMU17_2201268496$          TYPE2 UNDO                   5          224         16
SYS        _SYSSMU18_2955687966$          TYPE2 UNDO                   5          240         16
SYS        _SYSSMU19_2122790941$          TYPE2 UNDO                   5          256         16
SYS        _SYSSMU20_1483375813$          TYPE2 UNDO                   5          272         16
21 rows selected.


SQL> 
Oracle采用了两种机制:Log-Force-At-Commit和Write-Ahead-Log
Log-Force-at-Commit:在事务提交的时候,和这个事务相关的Redolog数据,都必须从Log Buffer中写入Redolog文件。通过这个机制,可以确保即使在Buffer Cache中的脏块还没写入磁盘,这时发生了故障(Crash/Instance),在做恢复的时候,可以通过Redolog的信息,将不一致的数据前滚。

Write-Ahead-Log:先写日志/预写日志的方式,这样在Buffer Cache中更新的但未被提交的数据就可以被写入磁盘(为了提高Buffer Cache的重复利用率,进而提升性能,也为了满足事务的特性),只要这些变更的Undo信息生成写入磁盘即可。大部分数据库系统的Undo和Redo存放在日志文件中,Oracle在这一点和别的不太一样,为了取得更佳效果,Oracle改进了这种常规方法,Oracle通过生成Undo信息的Redo entry,而不需要将Undo的变化信息写入磁盘(文件)。所以当事务发生时,会生成DML操作的Undo信息,这些信息记录在Undo表空间中(用于回滚操作),还会生成Redo信息(用于重做操作),这些Redo信息包括DML的变更和Undo的变更(如果不记录这些变更的话,这些在Buffer Cache中的Undo信息就可能会丢失)。

有了这2种机制,Oracle就很好的实现了ACID的特性
有没有可能Dirty data已经写入磁盘,在Log Buffer中的Redo信息还没有写入Redolog,这时数据库Crash了,这种情况该如何恢复?
Oracle通过以上2种机制,提交必须写日志和日志优先写入的方式。所以在Buffer Cache中的脏块,Redo信息在没有写入Redolog文件之前,这些Buffer是不允许被写入磁盘的。如果Undo的信息没有写入Redolog,这些脏块也是不允许写入磁盘的。所以这种情况是不会发生的。

Crash后再次启动记录的alert信息
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
Started Redo scan
Completed Redo scan
 read 109 KB Redo, 33 data blocks need recovery
Started Redo application at
 Thread 1: logseq 16, block 600
Recovery of Online Redo Log: Thread 1 Group 1 Seq 16 Reading mem 0
  Mem# 0: /oradata/upgr/Redo01.log
Completed Redo application of 0.06MB
Completed crash recovery at
 Thread 1: logseq 16, block 819, scn 14874127694380
 33 data blocks read, 33 data blocks written, 109 Redo k-bytes read
************************************************************
Warning: The SCN headroom for this database is only 9 days!
************************************************************
************************************************************
Warning: The SCN headroom for this database is only 9 days!
************************************************************
Thread 1 advanced to log sequence 17 (thread open)
Thread 1 opened at log sequence 17
  Current log# 2 seq# 17 mem# 0: /oradata/upgr/Redo02.log
Successful open of Redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
[67156] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:277317194 end:277317244 diff:50 (0 seconds)
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Fri Apr 08 23:45:55 2016
QMNC started with pid=20, OS id=67158 
Completed: ALTER DATABASE OPEN
Crash Recovery包含对Redo的Scan和Apply,完成的是Rolling Forward的工作,Completed crash recovery可以看做是前滚完成的标志。tx recovery(Transaction Recovery)发生在Undo Tablespace online之后,由SMON发起,可以看到Rollback的操作是在数据库打开之前完成。

下面的的测试是switch到一个新的日志文件,然后更新OHS表的一条记录,然后再switch到一个新的日志文件,这样就可以dump我们需要的那个日志文件,里面会包含最少的的Redo,方便我们查看。
SQL> alter system checkpoint;
System altered.
SQL> alter system switch logfile;
System altered.
SQL> archive log list;
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            /u01/oracle/product/112/dbs/arch
Oldest online log sequence     17
Current log sequence           19

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------- ------------ ---------
         1          1         19   52428800        512          1 NO  CURRENT             1.4874E+13 11-APR-16   2.8147E+14
         2          1         17   52428800        512          1 NO  INACTIVE            1.4874E+13 08-APR-16   1.4874E+13 11-APR-16
         3          1         18   52428800        512          1 NO  INACTIVE            1.4874E+13 11-APR-16   1.4874E+13 11-APR-16

SQL> conn ohsdba

Enter password: 
Connected.
SQL> update ohsdba.ohs set a=100;
1 row updated.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> alter system checkpoint;
System altered.
SQL> conn / as sysdba
Connected.
SQL> alter system dump logfile '/oradata/upgr/Redo01.log';
System altered.
SQL> oradebug setmypid;
Statement processed.
SQL> oradebug tracefile_name;
/u01/oracle/diag/rdbms/upgr/upgr/trace/upgr_ora_74970.trc
SQL> 
Redo RECORD - Thread:1 RBA: 0x000013.00000009.00c0 LEN: 0x0060 VLD: 0x01
SCN: 0x0d87.27194ed1 SUBSCN:  1 04/11/2016 16:23:02
CHANGE #1 TYP:0 CLS:17 AFN:3 DBA:0x00c00080 OBJ:4294967295 SCN:0x0d87.27194ed0 SEQ:1 OP:5.4 ENC:0 RBL:0
ktucm Redo: slt: 0x0015 sqn: 0x000002f7 srt: 0 sta: 9 flg: 0x2 ktucf Redo: uba: 0x00c00459.00ae.2a ext: 2 spc: 2638 fbi: 0 
 
Redo RECORD - Thread:1 RBA: 0x000013.0000000a.0010 LEN: 0x025c VLD: 0x0d
SCN: 0x0d87.27194ed6 SUBSCN:  1 04/11/2016 16:23:09
(LWN RBA: 0x000013.0000000a.0010 LEN: 0002 NST: 0001 SCN: 0x0d87.27194ed5)

CHANGE #1 TYP:2 CLS:1 AFN:4 DBA:0x010000ae OBJ:87501 SCN:0x0d87.27194bf2 SEQ:2 OP:11.19 ENC:0 RBL:0
KTB Redo 
op: 0x11  ver: 0x01  
compat bit: 4 (post-11) padding: 1
op: F  xid:  0x0002.021.000003ce    uba: 0x00c0011c.00e8.06
Block cleanout record, scn:  0x0d87.27194ed4 ver: 0x01 opt: 0x02, entries follow...
  itli: 1  flg: 2  scn: 0x0d87.27194bf2

Array Update of 1 rows: 
tabn: 0 slot: 0(0x0) flag: 0x2c lock: 2 ckix: 11
ncol: 1 nnew: 1 size: 0
KDO Op code:  21 row dependencies Disabled
  xtype: XAxtype KDO_KDOM2 flags: 0x00000080  bdba: 0x010000ae  hdba: 0x010000aa
itli: 2  ispac: 0  maxfr: 4858
vect = 0
col  0: [ 2]  c2 02  --->变更后的值
CHANGE #2 TYP:0 CLS:19 AFN:3 DBA:0x00c00090 OBJ:4294967295 SCN:0x0d87.27194dbe SEQ:1 OP:5.2 ENC:0 RBL:0
ktudh Redo: slt: 0x0021 sqn: 0x000003ce flg: 0x0012 siz: 188 fbi: 0
            uba: 0x00c0011c.00e8.06    pxid:  0x0000.000.00000000
            
CHANGE #3 TYP:0 CLS:19 AFN:3 DBA:0x00c00090 OBJ:4294967295 SCN:0x0d87.27194ed6 SEQ:1 OP:5.4 ENC:0 RBL:0  ---->提交事务
ktucm Redo: slt: 0x0021 sqn: 0x000003ce srt: 0 sta: 9 flg: 0x2 ktucf Redo: uba: 0x00c0011c.00e8.06 ext: 3 spc: 7150 fbi: 0 

CHANGE #4 TYP:0 CLS:20 AFN:3 DBA:0x00c0011c OBJ:4294967295 SCN:0x0d87.27194dbd SEQ:1 OP:5.1 ENC:0 RBL:0
ktudb Redo: siz: 188 spc: 7340 flg: 0x0012 seq: 0x00e8 rec: 0x06
            xid:  0x0002.021.000003ce  
ktubl Redo: slt: 33 rci: 0 opc: 11.1 [objn: 87501 objd: 87501 tsn: 4]
Undo type:  Regular undo        Begin trans    Last buffer split:  No 
Temp Object:  No 
Tablespace Undo:  No 
             0x00000000  prev ctl uba: 0x00c0011c.00e8.05 
prev ctl max cmt scn:  0x0d87.27194ad1  prev tx cmt scn:  0x0d87.27194ad2 
txn start scn:  0x0d87.27194ed1  logon user: 84  prev brb: 12583160  prev bcl: 0 BuExt idx: 0 flg2: 0
KDO undo record:
KTB Redo 
op: 0x04  ver: 0x01  
compat bit: 4 (post-11) padding: 1
op: L  itl: xid:  0x0002.005.000003be uba: 0x00c0012a.00d5.05

                      flg: C-U-    lkc:  0     scn: 0x0d87.271916a5

Array Update of 1 rows: 

tabn: 0 slot: 0(0x0) flag: 0x2c lock: 0 ckix: 11 
ncol: 1 nnew: 1 size: 0
KDO Op code:  21 row dependencies Disabled
  xtype: XAxtype KDO_KDOM2 flags: 0x00000080  bdba: 0x010000ae  hdba: 0x010000aa
itli: 2  ispac: 0  maxfr: 4858

vect = 0

col  0: [ 2]  c1 64  --->变更前的值

END OF Redo DUMP


SQL> select dump(99) from dual;
DUMP(99)
--------------------
Typ=2 Len=2: 193,100
SQL> select dump(100) from dual;
DUMP(100)
------------------
Typ=2 Len=2: 194,2
SQL> 
SQL> select * from ohsdba.ohs;
         A
----------
       100
SQL> 
REDO Change Vecto OPCODE的说明:
  Layer 1 : Transaction Control - KCOCOTCT     
         Opcode 1 : KTZFMT 
         Opcode 2 : KTZRDH 
         Opcode 3 : KTZARC
         Opcode 4 : KTZREP    
    Layer 2 : Transaction Read -  KCOCOTRD         
    Layer 3 : Transaction Update -  KCOCOTUP     
    Layer 4 : Transaction Block -  KCOCOTBK     [ktbcts.h]
         Opcode 1 : Block Cleanout 
         Opcode 2 : Physical Cleanout 
         Opcode 3 : Single Array Change
         Opcode 4 : Multiple Changes to an Array
         Opcode 5 : Format Block    
    Layer 5 : Transaction Undo -  KCOCOTUN     [ktucts.h]
         Opcode 1 : Undo block or undo segment header - KTURDB
         Opcode 2 : Update rollback segment header - KTURDH
         Opcode 3 : Rollout a transaction begin 
         Opcode 4 : Commit transaction (transaction table update) - no undo record 
         Opcode 5 : Create rollback segment (format) - no undo record 
         Opcode 6 : Rollback record index in an undo block - KTUIRB
         Opcode 7 : Begin transaction (transaction table update) 
         Opcode 8 : Mark transaction as dead 
         Opcode 9 : Undo routine to rollback the extend of a rollback segment 
         Opcode 10 :Redo to perform the rollback of extend of rollback segment 
                    to the segment header. 
         Opcode 11 :Rollback DBA in transaction table entry - KTUBRB 
         Opcode 12 :Change transaction state (in transaction table entry) 
         Opcode 13 :Convert rollback segment format (V6 -> V7) 
         Opcode 14 :Change extent allocation parameters in a rollback segment 
         Opcode 15 :
         Opcode 16 :
         Opcode 17 :
         Opcode 18 :
         Opcode 19 : Transaction start audit log record
         Opcode 20 : Transaction continue audit log record     
         Opcode 24 : Kernel Transaction Undo Relog CHanGe - KTURLGU
    Layer 6 : Control File -  KCOCODCF     [tbs.h]    
    Layer 10 : INDEX -  KCOCODIX     [kdi.h]
         Opcode 1 : load index block (Loader with direct mode) 
         Opcode 2 : Insert leaf row 
         Opcode 3 : Purge leaf row 
         Opcode 4 : Mark leaf row deleted 
         Opcode 5 : Restore leaf row (clear leaf delete flags) 
         Opcode 6 : Lock index block 
         Opcode 7 : Unlock index block 
         Opcode 8 : Initialize new leaf block 
         Opcode 9 : Apply Itl Redo 
         Opcode 10 :Set leaf block next link 
         Opcode 11 :Set leaf block previous link 
         Opcode 12 :Init root block after split 
         Opcode 13 :Make leaf block empty 
         Opcode 14 :Restore block before image 
         Opcode 15 :Branch block row insert 
         Opcode 16 :Branch block row purge 
         Opcode 17 :Initialize new branch block 
         Opcode 18 :Update keydata in row 
         Opcode 19 :Clear row's split flag 
         Opcode 20 :Set row's split flag 
         Opcode 21 :General undo above the cache (undo) 
         Opcode 22 :Undo operation on leaf key above the cache (undo) 
         Opcode 23 :Restore block to b-tree 
         Opcode 24 :Shrink ITL (transaction entries) 
         Opcode 25 :Format root block Redo 
         Opcode 26 :Undo of format root block (undo) 
         Opcode 27 :Redo for undo of format root block 
         Opcode 28 :Undo for migrating block
         Opcode 29 :Redo for migrating block
         Opcode 30 :IOT leaf block nonkey update
         Opcode 31 :Cirect load root Redo
         Opcode 32 :Combine operation for insert and restore rows     
    Layer 11 : Row Access -  KCOCODRW     [kdocts.h]
         Opcode 1 : Interpret Undo Record (Undo) 
         Opcode 2 : Insert Row Piece 
         Opcode 3 : Drop Row Piece 
         Opcode 4 : Lock Row Piece 
         Opcode 5 : Update Row Piece 
         Opcode 6 : Overwrite Row Piece 
         Opcode 7 : Manipulate First Column (add or delete the 1rst column) 
         Opcode 8 : Change Forwarding address 
         Opcode 9 : Change the Cluster Key Index 
         Opcode 10 :Set Key Links (change the forward & backward key links 
                    on a cluster key) 
         Opcode 11 :Quick Multi-Insert (ex: insert as select ...) 
         Opcode 12 :Quick Multi-Delete 
         Opcode 13 :Toggle Block Header flags     
    Layer 12 : Cluster -  KCOCODCL     [?]   
    Layer 13 : Transaction Segment -  KCOCOTSG     [ktscts.h]
         Opcode 1 : Data segment format 
         Opcode 2 : Merge 
         Opcode 3 : Set link in block 
         Opcode 4 : Not used 
         Opcode 5 : New block (affects segment header) 
         Opcode 6 : Format block (affects data block) 
         Opcode 7 : Record link 
         Opcode 8 : Undo free list (undo) 
         Opcode 9 : Redo free list head (called as part of undo) 
         Opcode 9 : Format free list block (freelist group) 
         Opcode 11 :Format new blocks in free list 
         Opcode 12 :free list clear 
         Opcode 13 :free list restore (back) (undo of opcode 12)     
    Layer 14 : Transaction Extent -  KCOCOTEX     [kte.h]
         Opcode 1 : Add extent to segment 
         Opcode 2 : Unlock Segment Header 
         Opcode 3 : Extent DEaLlocation (DEL) 
         Opcode 4 : Undo to Add extent operation (see opcode 1) 
         Opcode 5 : Extent Incarnation number increment 
         Opcode 6 : Lock segment Header 
         Opcode 7 : Undo to rollback extent deallocation (see opcode 3) 
         Opcode 8 : Apply Position Update (truncate) 
         Opcode 9 : Link blocks to Freelist 
         Opcode 10 :Unlink blocks from Freelist 
         Opcode 11 :Undo to Apply Position Update (see opcode 8) 
         Opcode 12 :Convert segment header to 6.2.x type      
    Layer 15 : Table Space -  KCOCOTTS     [ktt.h]
        Opcode 1 : Format deferred rollback segment header 
        Opcode 2 : Add deferred rollback record 
        Opcode 3 : Move to next block 
        Opcode 4 : Point to next deferred rollback record    
    Layer 16 : Row Cache -  KCOCOQRC        
    Layer 17 : Recovery (Redo) -  KCOCORCV     [kcv.h]
         Opcode 1 : End Hot Backup : This operation clears the hot backup 
                    in-progress flags in the indicated list of files 
         Opcode 2 : Enable Thread : This operation creates a Redo record 
                    signalling that a thread has been enabled 
         Opcode 3 : Crash Recovery Marker 
         Opcode 4 : Resizeable datafiles
         Opcode 5 : Tablespace ONline
         Opcode 6 : Tablespace OFFline
         Opcode 7 : Tablespace ReaD Write
         Opcode 8 : Tablespace ReaD Only
         Opcode 9 : ADDing datafiles to database
         Opcode 10 : Tablespace DRoP
         Opcode 11 : Tablespace PitR     
    Layer 18 : Hot Backup Log Blocks -  KCOCOHLB     [kcb.h]
         Opcode 1 : Log block image 
         Opcode 2 : Recovery testing     
    Layer 19 : Direct Loader Log Blocks - KCOCODLB     [kcbl.h]
         Opcode 1 : Direct block logging 
         Opcode 2 : Invalidate range 
         Opcode 3 : Direct block relogging
         Opcode 4 : Invalidate range relogging     
    Layer 20 : Compatibility Segment operations - KCOCOKCK  [kck.h]
         Opcode 1 : Format compatibility segment -  KCKFCS
         Opcode 2 : Update compatibility segment - KCKUCS
    Layer 21 : LOB segment operations - KCOCOLFS     [kdl2.h]
         Opcode 1 : Write data into ILOB data block - KDLOPWRI
    Layer 22 : Tablespace bitmapped file operations -  KCOCOTBF [ktfb.h]
         Opcode 1 : format space header - KTFBHFO
         Opcode 2 : space header generic Redo - KTFBHRedo
         Opcode 3 : space header undo - KTFBHUNDO
         Opcode 4 : space bitmap block format - KTFBBFO
         Opcode 5 : bitmap block generic Redo - KTFBBRedo 
    Layer 23 : write behind logging of blocks - KCOCOLWR [kcbb.h]
         Opcode 1 : Dummy block written callback - KCBBLWR
    Layer 24 : Logminer related (DDL or OBJV# Redo) - KCOCOKRV [krv.h]
         Opcode : common portion of the ddl - KRVDDL
         Opcode : direct load Redo - KRVDLR 
         Opcode : lob related info - KRVLOB
         Opcode : misc info - KRVMISC 
         Opcode : user info - KRVUSER          

SMON

The System Monitor Process (SMON) is the most critical background process for Oracle Database.It performs critical tasks such as instance recovery,dead transaction recovery and maintenance tasks such as temporary space reclamation, data dictionary cleanup, and Undo tablespace management.

SMON performs many database maintenance tasks, including the following:
    1. Creates and manages the temporary tablespace metadata
    2.Reclaims space used by orphaned temporary segments
    3.Maintains the Undo tablespace by onlining, offlining, and shrinking the Undo segments based on Undo space usage statistics
    4.Cleans up the data dictionary when it is in a transient and inconsistent state
    5.Maintains the SCN to time mapping table used to support Oracle Flashback features
    6.In an Oracle RAC database, the SMON process of one instance can perform instance recovery for other instances that have failed.
SMON checks regularly to see whether it is needed. Other processes can call SMON if they detect a need for it.

If the SMON is busy doing the transaction recovery you should never attempt a shutdown abort and restarting the database. The entire work done till that point needs to be done again.

Instance Recovery is performed in two steps: rollforward and rollback
Cache Recovery/Rollforward
The first phase of instance recovery is called cache recovery or rolling forward, and involves reapplying all of the changes recorded in the online Redo log to the data files. Because rollback data is recorded in the online Redo log, rolling forward also regenerates the corresponding Undo segments.
Rolling forward proceeds through as many online Redo log files as necessary to bring the database forward in time. After rolling forward, the data blocks contain all committed changes recorded in the online Redo log files. These files could also contain uncommitted changes that were either saved to the data files before the failure, or were recorded in the online Redo log and introduced during cache recovery.

Transaction Recovery/Rollback
After the roll forward, any changes that were not committed must be Undone. Oracle Database uses the checkpoint position, which guarantees that every committed change with an SCN lower than the checkpoint SCN is saved on disk. Oracle Database applies Undo blocks to roll back uncommitted changes in data blocks that were written before the failure or introduced during cache recovery. This phase is called rolling back or transaction recovery.

Rolling Back

The use of rollback segments to Undo uncommitted changes applied to the database during the rolling forward stage of recovery.


Rolling Forward

The application of Redo records or incremental backups to data files and control files to recover changes to those files.


Instance Recovery
In an Oracle RAC configuration, the application of Redo data to an open database by an instance when this instance discovers that another instance has crashed.
Whether instance recovery is required depends on the state of the Redo threads. A Redo thread is marked open in the control file when a database instance opens in read/write mode, and is marked closed when the instance is shut down consistently. If Redo threads are marked open in the control file, but no live instances hold the thread enqueues corresponding to these threads, then the database requires instance recovery.

Crash Recovery
The automatic application of online Redo records to a database after either a single-instance database crashes or all instances of an Oracle Real Applications Cluster configuration crash. Crash recovery only requires Redo from the online logs; archived Redo logs are not required.

Media Recovery
The application of Redo or incremental backups to a restored backup data file or individual data block.
When performing media recovery, you can recover a database, tablespace, data file, or set of blocks within a data file. Media recovery can be either complete recovery (in which all changes in the Redo logs are applied) or incomplete recovery (in which only changes up to a specified point in time are applied). Media recovery is only possible when the database is in ARCHIVELOG mode.

Reference
http://docs.oracle.com/database/121/REFRN/GUID-7BF7955C-9705-40F4-B2F6-5D7F3A32DD30.htm
http://docs.oracle.com/database/121/REFRN/GUID-23BA7CDD-D642-4CE7-83E2-69B7CFC328A1.htm
http://docs.oracle.com/database/121/REFRN/GUID-C62A7B96-2DD4-4E70-A0D9-26EE4BFBE256.htm
http://docs.oracle.com/database/121/CNCPT/transact.htm
http://docs.oracle.com/database/121/CNCPT/memory.htm
http://docs.oracle.com/database/121/BRADV/glossary.htm?type=popup#BRADV90243

https://jonathanlewis.wordpress.com/2010/02/09/why-undo/


Top
Cell186-9589-1286
QQ 375349564