SnapAssure备份实施运维最佳实践_redo日志篇

时间 2021-01-19

标签 html git github 数据库安全 oracle less 运维 ide 性能栏目 HTML 繁體版

原文原文链接

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
1、非归档
一般状况下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;html

LOG_MODE FORCE_LOGGINGgit

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 ALLgithub

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_LOGGINGoracle

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 ALLless

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? Typeide

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以及以前的版本。
2、归档
归档模式的数据库能够对联机重作日志进行归档，联机重作日志是循环覆盖的，归档能够长时间保存重作日志，这样可以避免循环覆盖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

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.

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

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以及以前的版本。

3、综述在DSG SnapAssure实施运维过程当中须要注意Redo日志模式，对于非归档模式启动最小附加日志会影响一部分系统性能，尤为对于平常比较繁忙的库，须要客户综合考虑数据安全和性能因素，建议客户在非归档模式下启用force_loggiing和最小附加日志，归档模式下启动force_logging，最大限度的保障数据安可恢复，避免出现数据丢失风险。