Redo日志在数据库库恢复过程中扮演着重要角色，恢复的精髓在于redo日志，而redo日志分为归档、非归档，自10g还引入了force_logging，force_logging也分为库级别、表空间级别，表级别；除此之外还有附加日志而附加日志又分为库级别和表级别，本文只讨论不同日志模式对备份恢复数据库的影响，形成最佳实践来指导SnapAssure备份软件实施运维和恢复。
测试环境介绍：
操作系统：CentOS Linux release 7.4.1708 (Core)
数据库版本：oracle 12c 12.2.0.1 (18c 19c的redo日志模式和12c 12.2.0.1差异不大)
oracle 11.2.0.4 rac
测试schemas来自oracle Sample Schemas，关于12c的Sample Schemas安装请移步google搜索，值得一说的是12c的schemas需要去github下载安装，安装软件不在提供安装。
Github地址：https://github.com/oracle/db-sample-schemas/releases
一、非归档
通常情况下oracle中的操作都会记录redo日志，有些时候为了减少redo生成（或者不生成），会使用Direct Loader方式加载数据提高效率，但这对恢复是有影响的，在oracle备份恢复手册有解释，Oracle Database Backup and Recovery Advanced User's Guide：
You can create tables and indexes with the CREATE TABLE AS SELECT statement. You can also specify that the database create them with the NOLOGGING option. When you create a table or index as NOLOGGING, the database does not generate redo log records for the operation. Thus, you cannot recover objects created with NOLOGGING, even if you are running in ARCHIVELOG mode.
Be aware that when you perform. media recovery, and some tables or indexes are created normally whereas others are created with the NOLOGGING option, the NOLOGGING objects are marked logically corrupt by the RECOVER operation.
Any attempt to access the unrecoverable objects returns an ORA-01578 error message. Drop the NOLOGGING objects and re-create
them if needed.
尽管是非归档模式，SnapAssure软件仍旧可以将redo读出来放到存储上，不存在redo循环覆盖的情况，即使redo切换频繁有丢失redo的可能，仍旧可以通过增加redo组数加大单组redo文件大小的方式来避免未备份出redo的情况，DSG SnapAssure可以不依赖oracle的自带的归档模式。
12c模拟过程
SQL> select log_mode,force_logging from v$database;
LOG_MODE FORCE_LOGGING
NOARCHIVELOG NO
SQL> SELECT supplemental_log_data_min min,
2 supplemental_log_data_pk pk,
3 supplemental_log_data_ui ui,
4 supplemental_log_data_fk fk,
5 supplemental_log_data_all allc
6 FROM v$database;
MIN PK UI FK ALL
NO NO NO NO NO
SQL> conn scott/tiger
Connected.
SQL> show user
USER is "SCOTT"
SQL>
SQL> create table t nologging as select from emp;
Table created.
SQL> insert into t select from t;
1792 rows created.
SQL> commit;
Commit complete.
SQL> insert into t select * from t;
3584 rows created.
SQL> commit;
Commit complete.
SQL>
Dump一下redo日志
SQL> alter system dump logfile '/u01/oracle/oradata/db2/redo01.log';
System altered.
SQL>
CHANGE #1 INVLD CON_ID:0 AFN:7 DBA:0x01c30153 BLKS:0x000b OBJ:74696 SCN:0x00000000001bc4ba SEQ:1 OP:19.2 ENC:0 FLG:0x0000
Direct Loader invalidate block range redo entry
REDO RECORD - Thread:1 RBA: 0x00001f.000004e1.0100 LEN: 0x004c VLD: 0x01 CON_UID: 0
SCN: 0x00000000001bc4ba SUBSCN: 2 04/30/2020 10:42:04
CHANGE #1 CON_ID:0 TYP:0 CLS:8 AFN:7 DBA:0x01c30150 OBJ:74696 SCN:0x00000000001bc4ba SEQ:1 OP:13.22 ENC:0 RBL:0 FLG:0x0000
Redo on Level1 Bitmap Block
Redo for state change
Len: 11 Offset: 3 newstate: 1
出现了Direct Loader invalidate block range redo entry，通常出现这种invalidate block，那么这个对象在应用redo恢复过程中会出错，那么对应的对象是不是模拟的表呢，OBJ:74696
在库中查询
SQL> select owner,object_name,object_type from dba_objects where object_id=74696;
OWNER OBJECT_NAME OBJECT_TYPE
SCOTT T TABLE
是scott下的T表。
1.1启动force_logging
那么如何规避这种情况呢，在建T表的时候使用了nologging，那是不是这个导致？那就用到force_logging了，关于force_logging
Some data definition language statements (such as CREATE TABLE) allow the NOLOGGING clause, which causes some database operations not to generate redo records in the database redo log. The NOLOGGING setting can speed up operations that can be easily recovered outside of the database recovery mechanisms, but it can negatively affect media recovery and standby databases.
Oracle Database lets you force the writing of redo records even when NOLOGGING has been specified in DDL statements. The database never generates redo records for temporary tablespaces and temporary segments, so forced logging has no affect for objects.
启动库级别的force logging
SQL> alter database force logging;
Database altered.
SQL> select log_mode,force_logging from v$database;
LOG_MODE FORCE_LOGGING
NOARCHIVELOG YES
SQL>
启动forcelogging后drop掉scott.t，继续创建表T，然后dump日志
SCN: 0x00000000001bc6dd SUBSCN: 1 04/30/2020 10:59:31
CHANGE #1 INVLD CON_ID:0 AFN:7 DBA:0x01c30153 BLKS:0x000b OBJ:74697 SCN:0x00000000001bc6dd SEQ:1 OP:19.2 ENC:0 FLG:0x0000
Direct Loader invalidate block range redo entry
REDO RECORD - Thread:1 RBA: 0x000020.00000013.00c4 LEN: 0x004c VLD: 0x01 CON_UID: 0
SCN: 0x00000000001bc6dd SUBSCN: 2 04/30/2020 10:59:31
CHANGE #1 CON_ID:0 TYP:0 CLS:8 AFN:7 DBA:0x01c30150 OBJ:74697 SCN:0x00000000001bc6dd SEQ:1 OP:13.22 ENC:0 RBL:0 FLG:0x0000
Redo on Level1 Bitmap Block
Redo for state change
Len: 11 Offset: 3 newstate: 1
对象OBJ:74697仍旧有Direct Loader invalidate block range redo entry，将这个redo用于恢复仍旧会报错。
那怎么减少这种情况的影响呢？oracle日志中还有附加日志，关于附加日志
Database level supplemental logging is an Oracle requirement that ensures that the Oracle redo log on the source database contains the information required to describe all data changes completely. Enabling supplemental logging is a requirement for all redo log mining replication solutions and not specific to Dbvisit Replicate.
Turning on supplemental logging ensures additional information is inserted into redo stream in order to facilitate replication. The extra level of overhead of adding this information into the redo log is generally less than 1%.
1.2 启动最小附加日志
这里只启动库级别最小附加日志，关于其他级别的附加日志之间的关系请移步oracle ACE的文章：http://www.dbsnake.net/oracle-supplemental-logging.html。
SQL> alter database add supplemental log data;
Database altered.
SQL> SELECT supplemental_log_data_min min,
2 supplemental_log_data_pk pk,
3 supplemental_log_data_ui ui,
4 supplemental_log_data_fk fk,
5 supplemental_log_data_all allc
6 FROM v$database;
MIN PK UI FK ALL
YES NO NO NO NO
SQL>
CHANGE #2 CON_ID:0 TYP:1 CLS:1 AFN:7 DBA:0x01c30153 OBJ:74698 SCN:0x00000000001bcc79 SEQ:1 OP:19.1 ENC:0 RBL:0 FLG:0x0000
Direct Loader block redo entry
Block header dump: 0x00000000
Object id on Block? Y
seg/obj: 0x123ca csc: 0x00000000001bcc75 itc: 3 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1c30150 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x00000000001bcc75
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
bdba: 0x00000000
data_block_dump,data header at 0x7ff2ff79e090
tsiz: 0x1f80
hsiz: 0x166
pbl: 0x7ff2ff79e090
76543210
flag=--------
ntab=1
nrow=170
frre=-1
fsbo=0x166
fseo=0x49b
avsp=0x335
tosp=0x335
0xe:pti[0] nrow=170 offs=0
0x12:pri[0] offs=0x1f57
0x14:pri[1] offs=0x1f2f
0x16:pri[2] offs=0x1f09
0x18:pri[3] offs=0x1ede
0x1a:pri[4] offs=0x1eb8
0x1c:pri[5] offs=0x1e92
0x1e:pri[6] offs=0x1e6b
block_row_dump:
tab 0, row 0, @0x1f57
tl: 41 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 3] c2 4e 53
col 1: [ 5] 43 4c 41 52 4b
col 2: [ 7] 4d 41 4e 41 47 45 52
col 3: [ 3] c2 4f 28
col 4: [ 7] 77 b5 06 09 01 01 01
col 5: [ 3] c2 19 33
col 6: NULL
col 7: [ 2] c1 0b
tab 0, row 1, @0x1f2f
tl: 40 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 3] c2 4e 59
col 1: [ 5] 53 43 4f 54 54
col 2: [ 7] 41 4e 41 4c 59 53 54
col 3: [ 3] c2 4c 43
col 4: [ 7] 77 bb 04 13 01 01 01
col 5: [ 2] c2 1f
col 6: NULL
col 7: [ 2] c1 15
tab 0, row 2, @0x1f09
tl: 38 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 3] c2 4f 28
col 1: [ 4] 4b 49 4e 47
col 2: [ 9] 50 52 45 53 49 44 45 4e 54
col 3: NULL
col 4: [ 7] 77 b5 0b 11 01 01 01
col 5: [ 2] c2 33
col 6: NULL
col 7: [ 2] c1 0b
可以看到OBJ:74698提示Direct Loader block redo entry，并且已经有data_block信息以及block_row信息，这样就能用于恢复了，不会出现恢复问题。
1.3 lob表
生产环境中lob对象是普遍存在的，仅仅测试普通表有局限，那么lob表会如何呢？
Redo日志模式为非归档，强制库级别force_logging，库级别最小附加日志。
这里lob表使用sample schemas pm下online_media表进行测试。
SQL> conn pm/tiger
Connected.
SQL> show user
USER is "PM"
SQL>
SQL>
SQL> desc pm.online_media
Name Null? Type
PRODUCT_ID NOT NULL NUMBER(6)
PRODUCT_PHOTO ORDSYS.ORDIMAGE
PRODUCT_PHOTO_SIGNATURE ORDSYS.ORDIMAGESIGNATURE
PRODUCT_THUMBNAIL ORDSYS.ORDIMAGE
PRODUCT_VIDEO ORDSYS.ORDVIDEO
PRODUCT_AUDIO ORDSYS.ORDAUDIO
PRODUCT_TEXT CLOB
PRODUCT_TESTIMONIALS ORDSYS.ORDDOC
SQL>
SQL> create table t nologging as select * from online_media;
Table created.
SQL> insert into t select * from t;
9 rows created.
SQL> commit;
Commit complete.
SQL> insert into t select * from t;
18 rows created.
SQL> commit;
Commit complete.
SQL>
Dump相应的redo信息
CHANGE #2 CON_ID:0 TYP:1 CLS:1 AFN:7 DBA:0x01c31813 OBJ:74699 SCN:0x00000000001bdca0 SEQ:1 OP:19.1 ENC:0 RBL:0 FLG:0x0000
Direct Loader block redo entry
Block header dump: 0x00000000
Object id on Block? Y
seg/obj: 0x123cb csc: 0x00000000001bdc9d itc: 3 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1c31810 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x00000000001bdc9d
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
bdba: 0x00000000
data_block_dump,data header at 0x7ff2ff79e090
tsiz: 0x1f80
hsiz: 0x14
pbl: 0x7ff2ff79e090
76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0xe20
avsp=0xe0c
tosp=0xe0c
0xe:pti[0] nrow=1 offs=0
0x12:pri[0] offs=0xe20
block_row_dump:
tab 0, row 0, @0xe20
tl: 4448 fb: --H-FL-- lb: 0x0 cc: 80
col 0: [ 3] c2 20 07
col 1: [ 1] 00
col 2: [38]
00 70 00 01 01 0c 00 80 00 01 00 00 00 01 00 00 00 11 5f 77 00 12 40 90 00
0c 21 00 56 f5 01 00 01 01 c3 16 71 03
col 3: [ 4] 46 49 4c 45
col 4: [ 9] 4d 45 44 49 41 5f 44 49 52
col 5: [12] 6b 65 79 62 6f 61 72 64 2e 6a 70 67
col 6: [ 7] 78 78 04 1b 0c 25 1c
col 7: [ 2] c1 02
col 8: [ 3] c2 03 1a
col 9: [ 2] c2 04
col 10: [ 4] c3 03 17 3e
col 11: [ 4] 4a 46 49 46
col 12: [ 8] 32 34 42 49 54 52 47 42
col 13: [ 4] 4a 50 45 47
col 14: [10] 69 6d 61 67 65 2f 6a 70 65 67
col 15: [ 1] 00
col 16: [30]
00 70 00 01 01 0c 00 80 00 01 00 00 00 01 00 00 00 11 5f 78 00 0a 48 90 00
04 00 00 00 00
col 17: [ 1] 00
col 18: [1483]
00 70 00 01 01 0c 00 80 00 01 00 00 00 01 00 00 00 11 5f 79 05 b7 48 90 05
b1 01 00 05 ac 01 ff d8 ff ed 00 ae 50 68 6f 74 6f 73 68 6f 70 20 33 2e 30
00 38 42 49 4d 04 04 00 00 00 00 00 7d 1c 02 00 00 02 00 02 1c 02 78 00 0a
20 20 20 20 20 20 20 20 20 20 1c 02 69 00 08 4b 65 79 62 6f 61 72 64 1c 02
6e 00 12 4f 72 61 63 6c 65 20 43 6f 72 70 6f 72 61 74 69 6f 6e 1c 02 73 00
17 49 6e 74 65 72 6e 61 6c 20 44 69 67 69 74 61 6c 20 43 61 6d 65 72 61 1c
02 37 00 08 32 30 30 34 31 30 31 32 1c 02 5a 00 06 4e 61 73 68 75 61 1c 02
5f 00 02 4e 48 1c 02 65 00 03 55 53 41 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 ff e0 00 10 4a 46 49 46 00 01 02 01 01 2c 01 2c
00 00 ff ed 00 ae 50 68 6f 74 6f 73 68 6f 70 20 33 2e 30 00 38 42 49 4d 04
OBJ:74699对应的对象为
SQL> select owner,object_name,object_type from dba_objects where object_id=74699;
OWNER OBJECT_NAME OBJECT_TYPE
PM T TABLE
SQL>
出现Direct Loader block redo entry，并且已经有data_block信息以及block_row信息，这样就能用于恢复了。
1.4 结论
通过以上的模拟测试，在非归档下需要启动库级别force_logging以及库级别的最小附加日志才能恢复Direct loader这种方式加载的表，9i的库由于没有force_logging，因此不适合oracle 9i以及之前的版本。
二、归档
归档模式的数据库可以对联机重做日志进行归档，联机重做日志是循环覆盖的，归档可以长时间保存重做日志，这样能够避免循环覆盖redo的情况发生（DSG SnapAssure可以不用归档模式也能实现）。
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/oracle/arch
Oldest online log sequence 33
Next log sequence to archive 35
Current log sequence 35
SQL> select log_mode,force_logging from v$database;
LOG_MODE FORCE_LOGGING
ARCHIVELOG NO
SQL>
SQL> create table t nologging as select * from emp;
Table created.
SQL> insert into t select * from t;
1792 rows created.
SQL> commit;
Commit complete.
SQL> insert into t select * from t;
3584 rows created.
SQL> commit;
Commit complete.
SQL>
Dump相关的redo日志
SCN: 0x00000000001c2bae SUBSCN: 1 04/30/2020 14:44:35
CHANGE #1 INVLD CON_ID:0 AFN:7 DBA:0x01c31833 BLKS:0x000b OBJ:74730 SCN:0x00000000001c2bae SEQ:1 OP:19.2 ENC:0 FLG:0x0000
Direct Loader invalidate block range redo entry
REDO RECORD - Thread:1 RBA: 0x000024.00000241.0100 LEN: 0x004c VLD: 0x01 CON_UID: 0
SCN: 0x00000000001c2bae SUBSCN: 2 04/30/2020 14:44:35
CHANGE #1 CON_ID:0 TYP:0 CLS:8 AFN:7 DBA:0x01c31830 OBJ:74730 SCN:0x00000000001c2bae SEQ:1 OP:13.22 ENC:0 RBL:0 FLG:0x0000
Redo on Level1 Bitmap Block
Redo for state change
Len: 11 Offset: 3 newstate: 1
OBJ:74730对应的对象在恢复后会出现错误，因为已经标记不可用的块了invalidate block，这个对象就是测试对象scott.T表
SQL> select owner,object_name,object_type from dba_objects where object_id=74730;
OWNER OBJECT_NAM OBJECT_TYPE
SCOTT T TABLE
SQL>
2.1 开启force_logging
SQL> alter database force logging;
Database altered.
SQL> select log_mode,force_logging from v$database;
LOG_MODE FORCE_LOGGING
ARCHIVELOG YES
SQL>
Drop掉scott下的T表，并重新创建t表进行模拟。
启动force logging后redo记录有了data block信息，以及相关的字段信息，这样就可以用来恢复用了。
CHANGE #1 CON_ID:0 TYP:1 CLS:1 AFN:7 DBA:0x01c31833 OBJ:74731 SCN:0x00000000001c2d51 SEQ:1 OP:19.1 ENC:0 RBL:0 FLG:0x0000
Direct Loader block redo entry
Block header dump: 0x00000000
Object id on Block? Y
seg/obj: 0x123eb csc: 0x00000000001c2d4e itc: 3 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1c31830 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x00000000001c2d4e
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
bdba: 0x00000000
data_block_dump,data header at 0x7f2e53702090
tsiz: 0x1f80
hsiz: 0x166
pbl: 0x7f2e53702090
76543210
tab 0, row 0, @0x1f57
tl: 41 fb: --H-FL-- lb: 0x0 cc: 8
col 0: [ 3] c2 4e 53
col 1: [ 5] 43 4c 41 52 4b
col 2: [ 7] 4d 41 4e 41 47 45 52
col 3: [ 3] c2 4f 28
col 4: [ 7] 77 b5 06 09 01 01 01
col 5: [ 3] c2 19 33
col 6: NULL
col 7: [ 2] c1 0b
SQL> select owner,object_name,object_type from dba_objects where object_id=74731;
OWNER OBJECT_NAM OBJECT_TYPE
SCOTT T TABLE
SQL>
2.2 lob表
生产环境中lob对象是普遍存在的，仅仅测试普通表有局限，那么lob表会如何呢？
Redo日志模式为归档，强制库级别force_logging。
SQL> select log_mode,force_logging from v$database;
LOG_MODE FORCE_LOGGING
ARCHIVELOG YES
SQL> SELECT supplemental_log_data_min min,
2 supplemental_log_data_pk pk,
3 supplemental_log_data_ui ui,
4 supplemental_log_data_fk fk,
5 supplemental_log_data_all allc
6 FROM v$database;
MIN PK UI FK ALL
NO NO NO NO NO
SQL>
这里lob表使用sample schemas pm下online_media表进行测试。
SQL> conn pm/tiger
Connected.
SQL> show user
USER is "PM"
SQL>
SQL>
SQL> desc pm.online_media
Name Null? Type
PRODUCT_ID NOT NULL NUMBER(6)
PRODUCT_PHOTO ORDSYS.ORDIMAGE
PRODUCT_PHOTO_SIGNATURE ORDSYS.ORDIMAGESIGNATURE
PRODUCT_THUMBNAIL ORDSYS.ORDIMAGE
PRODUCT_VIDEO ORDSYS.ORDVIDEO
PRODUCT_AUDIO ORDSYS.ORDAUDIO
PRODUCT_TEXT CLOB
PRODUCT_TESTIMONIALS ORDSYS.ORDDOC
SQL>
SQL> create table t nologging as select * from online_media;
Table created.
SQL> insert into t select * from t;
9 rows created.
SQL> commit;
Commit complete.
SQL> insert into t select * from t;
18 rows created.
SQL> commit;
Commit complete.
SQL>
Dump相应的redo信息
CHANGE #2 CON_ID:0 TYP:1 CLS:1 AFN:7 DBA:0x01c31813 OBJ:74699 SCN:0x00000000001bdca0 SEQ:1 OP:19.1 ENC:0 RBL:0 FLG:0x0000
Direct Loader block redo entry
Block header dump: 0x00000000
Object id on Block? Y
seg/obj: 0x123cb csc: 0x00000000001bdc9d itc: 3 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1c31810 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0xffff.000.00000000 0x00000000.0000.00 C--- 0 scn 0x00000000001bdc9d
0x02 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x03 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
bdba: 0x00000000
data_block_dump,data header at 0x7ff2ff79e090
tsiz: 0x1f80
hsiz: 0x14
pbl: 0x7ff2ff79e090
76543210
flag=--------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0xe20
avsp=0xe0c
tosp=0xe0c
0xe:pti[0] nrow=1 offs=0
0x12:pri[0] offs=0xe20
block_row_dump:
tab 0, row 0, @0xe20
tl: 4448 fb: --H-FL-- lb: 0x0 cc: 80
col 0: [ 3] c2 20 07
col 1: [ 1] 00
col 2: [38]
00 70 00 01 01 0c 00 80 00 01 00 00 00 01 00 00 00 11 5f 77 00 12 40 90 00
0c 21 00 56 f5 01 00 01 01 c3 16 71 03
col 3: [ 4] 46 49 4c 45
col 4: [ 9] 4d 45 44 49 41 5f 44 49 52
col 5: [12] 6b 65 79 62 6f 61 72 64 2e 6a 70 67
col 6: [ 7] 78 78 04 1b 0c 25 1c
col 7: [ 2] c1 02
col 8: [ 3] c2 03 1a
col 9: [ 2] c2 04
col 10: [ 4] c3 03 17 3e
col 11: [ 4] 4a 46 49 46
col 12: [ 8] 32 34 42 49 54 52 47 42
col 13: [ 4] 4a 50 45 47
col 14: [10] 69 6d 61 67 65 2f 6a 70 65 67
col 15: [ 1] 00
col 16: [30]
00 70 00 01 01 0c 00 80 00 01 00 00 00 01 00 00 00 11 5f 78 00 0a 48 90 00
04 00 00 00 00
col 17: [ 1] 00
col 18: [1483]
00 70 00 01 01 0c 00 80 00 01 00 00 00 01 00 00 00 11 5f 79 05 b7 48 90 05
b1 01 00 05 ac 01 ff d8 ff ed 00 ae 50 68 6f 74 6f 73 68 6f 70 20 33 2e 30
00 38 42 49 4d 04 04 00 00 00 00 00 7d 1c 02 00 00 02 00 02 1c 02 78 00 0a
20 20 20 20 20 20 20 20 20 20 1c 02 69 00 08 4b 65 79 62 6f 61 72 64 1c 02
6e 00 12 4f 72 61 63 6c 65 20 43 6f 72 70 6f 72 61 74 69 6f 6e 1c 02 73 00
17 49 6e 74 65 72 6e 61 6c 20 44 69 67 69 74 61 6c 20 43 61 6d 65 72 61 1c
02 37 00 08 32 30 30 34 31 30 31 32 1c 02 5a 00 06 4e 61 73 68 75 61 1c 02
5f 00 02 4e 48 1c 02 65 00 03 55 53 41 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 ff e0 00 10 4a 46 49 46 00 01 02 01 01 2c 01 2c
00 00 ff ed 00 ae 50 68 6f 74 6f 73 68 6f 70 20 33 2e 30 00 38 42 49 4d 04
OBJ:74699对应的对象为
SQL> select owner,object_name,object_type from dba_objects where object_id=74699;
OWNER OBJECT_NAME OBJECT_TYPE
PM T TABLE
SQL>
出现Direct Loader block redo entry，并且已经有data_block信息以及block_row信息，这样就能用于恢复了。
2.3 结论
通过以上的模拟测试，在归档下需要启动库级别force_logging能恢复Direct loader这种方式加载的表，9i的库由于没有force_logging，因此不适合oracle 9i以及之前的版本。
三、综述
在DSG SnapAssure实施运维过程中需要注意Redo日志模式，对于非归档模式启动最小附加日志会影响一部分系统性能，尤其对于日常比较繁忙的库，需要客户综合考虑数据安全和性能因素，建议客户在非归档模式下启用force_loggiing和最小附加日志，
归档模式下启动force_logging，最大限度的保障数据安可恢复，避免出现数据丢失风险。