A 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，她是一直递增的，即使表空间处于HotBackup Mode(热备时数据文件的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.
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: 11ncol: 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
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 metadataSMON checks regularly to see whether it is needed. Other processes can call SMON if they detect a need for it.
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.
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 rollbackCache 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.
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/
