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，最大限度的保障數據安可恢復，避免出現數據丟失風險。