Oracle熱備份原理分析

資料庫要求在自動歸檔模式下。

假設開始對 users 表空間檔案進行begin backup 。

我們檢視 dba_data_files ， v$backup 來觀察資料檔案備份狀態變化 。

sql> alter tablespace users begin backup;
tablespace altered.
sql> list
1 select d.file_name filename,d.tablespace_name ts_name,b.status
2 from dba_data_files d,v$backup b
3* where d.file_id=b.file#
sql> /

filename ts_name status
---------------------------------------- ---------- ------------------
/u02/oradata/sales/system01.dbf system not active
/u02/oradata/sales/undotbs01.dbf undotbs1 not active
/u02/oradata/sales/sysaux01.dbf sysaux not active
/u02/oradata/sales/users01.dbf users active
/u02/oradata/sales/example01.dbf example not active

users 表空間檔案處於backup 狀態 (active) . 這個時候到底資料庫作了些什麼？ 我們執行alter tablespace users begin backup 的時候鎖定了users表空間對應的資料檔案頭的change scn ( 見下面查詢的 sql>select name,tablespace_name,status,checkpoint_change# from v$datafile_header; 中users 檔案的 checkpoint_change# )。

首先考慮一下資料庫怎麼用日誌檔案做恢復：查詢不一致的資料檔案（根據檔案頭中舊的scn）

如果鎖定了檔案頭，這個檔案頭中的scn就不會改變（當然了資料塊還是會變化的，還可以做讀寫）。

然後就會應用這個scn到現在的日誌。那我鎖定了scn，不管你後邊怎麼修改，

總之做恢復的時候是應用鎖定的時候的scn一直到現在的日誌（完全恢復的話）

舉個例子：

a,b兩個資料檔案，把a置於備份模式，b正常

這時候兩個change scn都是100，然後開始備份

這期間有資料庫的修改，備份完成的時候，scn變成了200。但是由於a的備份模式，

所以a的檔案頭中記錄的scn還是100，b是200。

某個時間，假設scn 500

這時候a丟失

copy回a的備份，然後recover,完全恢復的話資料庫就應用100—500這段的日誌，自然也就不會丟失資料了。

因為不管在我copy備份的過程中你做什麼操作，總之都在鎖定的時change scn之後，

所以應用的日誌就不會有遺漏了。這時候應該能理解為什麼要資料庫處於archived模式了

看看資料檔案頭的change scn


sql>select name,tablespace_name,status,checkpoint_change# from v$datafile_header;
name tablespace status checkpoint_change#
-------------------------------- ---------- -------------- ------------------
/u02/oradata/sales/system01.dbf system online 545926
/u02/oradata/sales/undotbs01.dbf undotbs1 online 545926
/u02/oradata/sales/sysaux01.dbf sysaux online 545926
/u02/oradata/sales/users01.dbf users online 545498
/u02/oradata/sales/example01.dbf example online 545926
/u02/oradata/sales/perfstat.dbf perfstat online 545926

6 rows selected.


顯然，在將users表空間置於backup狀態的時候，相應的datafile的檔案頭的scn就不會再發生改變，

發生檢查點也不會改變。


sql> alter system checkpoint;
system altered.

sql> select name,tablespace_name,status,checkpoint_change# from v$datafile_header;
name tablespace status checkpoint_change#
-------------------------------- ---------- -------------- ------------------

/u02/oradata/sales/system01.dbf system online 546196
/u02/oradata/sales/undotbs01.dbf undotbs1 online 546196
/u02/oradata/sales/sysaux01.dbf sysaux online 546196
/u02/oradata/sales/users01.dbf users online 545498
/u02/oradata/sales/example01.dbf example online 546196
/u02/oradata/sales/perfstat.dbf perfstat online 546196

6 rows selected.


下面end backup,看看scn


sql> alter tablespace users end backup;
tablespace altered.

sql> alter system checkpoint;
system altered.

sql>select name,tablespace_name,status,checkpoint_change# from v$datafile_header;

name tablespace status checkpoint_change#
-------------------------------- ---------- -------------- ------------------
/u02/oradata/sales/system01.dbf system online 546467
/u02/oradata/sales/undotbs01.dbf undotbs1 online 546467
/u02/oradata/sales/sysaux01.dbf sysaux online 546467
/u02/oradata/sales/users01.dbf users online 546467
/u02/oradata/sales/example01.dbf example online 546467
/u02/oradata/sales/perfstat.dbf perfstat online 546467

6 rows selected.

===============================================================

當資料檔案置於backup模式時，oracle會去鎖定資料檔案頭，這時候資料庫發生檢查點的話將不會修改檔案頭的checkpoint scn，而只是增加checkpoint cnt，所以不管執行cp的時候作業系統塊的複製順序是如何，oracle總會從檔案頭的scn開始恢復，這樣的話也就避免了資料丟失和資料塊corruption.如果大家用的是rman來備份，那麼就不會有這個問題，因為rman備份的時候rman會去對比資料塊的頭尾標誌，如果發現不一致，那麼它將會再去讀這個塊，直到讀到一致的塊才往備份集裡寫。

但是alter tablespace XXX begin backup帶來的另一個問題是會導致產生多餘的日誌，透過一個小小的試驗就可以證明這一點。

SQL> select name,value from v$sysstat where name='redo size';

NAME VALUE
---------------------------------------------------------------- ----------
redo size 43408

SQL> update test set a=a;

1 row updated.

SQL> commit;

Commit complete.

SQL> select name,value from v$sysstat where name='redo size';

NAME VALUE
---------------------------------------------------------------- ----------
redo size 44060

SQL> ALTER SYSTEM DUMP LOGFILE '/netappredo/redo05.log';

System altered.

一個update的動作產生44060－43408＝652bytes的redo

把表空間置為backup mode

SQL> alter tablespace test begin backup;

Tablespace altered.

SQL> select name,value from v$sysstat where name='redo size';

NAME VALUE
---------------------------------------------------------------- ----------
redo size 44732

SQL> update test set a=a;

1 row updated.

SQL> commit;

Commit complete.

SQL> select name,value from v$sysstat where name='redo size';

NAME VALUE
---------------------------------------------------------------- ----------
redo size 53560

SQL> alter tablespace test end backup;

Tablespace altered.

一個update的動作產生53560－44732＝8828bytes的redo

看看到底是記了些什麼？

SQL> ALTER SYSTEM DUMP LOGFILE '/netappredo/redo05.log';

System altered.

REDO RECORD - Thread:2 RBA: 0x00004e.000000b0.0128 LEN: 0x01b0 VLD: 0x01
SCN: 0x0000.19ed24f7 SUBSCN: 1 06/29/2004 15:05:32
CHANGE #1 TYP:0 CLS:29 AFN:33 DBA:0x08400029 SCN:0x0000.19ed24f2 SEQ: 1 OP:5.2
...... (改動向量1，記載對undo header事務表的修改)
CHANGE #2 TYP:0 CLS:30 AFN:33 DBA:0x0840002e SCN:0x0000.19ed24f0 SEQ: 1 OP:5.1
...... (改動向量2，記載對undo block的修改)
CHANGE #3 TYP:2 CLS: 1 AFN:51 DBA:0x0cc0000f SCN:0x0000.19ed24e8 SEQ: 1 OP:11.5
KTB Redo (改動向量3，記載對資料塊的修改，也就是在資料塊上執行update test set a=a）
op: 0x11 ver: 0x01
op: F xid: 0x0007.001.00014ece uba: 0x0840002e.0859.38
Block cleanout record, scn: 0x0000.19ed24f7 ver: 0x01 opt: 0x02, entries follow...
itli: 1 flg: 2 scn: 0x0000.19ed24e8
KDO Op code: URP row dependencies Disabled
xtype: XA bdba: 0x0cc0000f hdba: 0x0cc0000b
itli: 2 ispac: 0 maxfr: 4858
tabn: 0 slot: 0(0x0) flag: 0x2c lock: 2 ckix: 0
ncol: 1 nnew: 1 size: 0
col 0: [ 2] c1 02
CHANGE #4 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:5.20
......(改動向量4，一些標記）

我們看到了正常的日誌記錄，此外還有些block cleanout及回滾段改變的日誌記錄，但是相比較不是backup模式的日誌來說多了這一部分。
Log block image redo entry
Dump of memory from 0x0AE48820 to 0x0AE4A808
AE48820 00280001 00002C32 19ED24E6 1FE80000 [..(.2,...$......]
AE48830 00321F02 0CC00009 00210005 000307F1 [..2.......!.....]
AE48840 0840000E 0021100C 00002001 19ED24E8 [..@...!.. ...$..]
AE48850 001F0016 0001A94C 0840007C 000D0C08 [....L...|.@.....]
AE48860 00008000 19ED2468 00000000 00000000 [....h$..........]
AE48870 00020100 00160001 1F791F8C 00001F79 [..........y.y...]
AE48880 1F920002 0F88FFFF 0ED00F2C 0E180E74 [........,...t...]
AE48890 0D600DBC 0CA80D04 0BF00C4C 0B380B94 [..`.....L.....8.]
AE488A0 0A800ADC 09C80A24 0910096C 085808B4 [....$...l.....X.]
AE488B0 07A007FC 06E40744 06240684 056405C4 [....D.....$...d.]
......
這一部分是對更改的資料塊做的一個映象，把這個塊完全記錄到redo裡面去了，但是為什麼要這麼做呢。
這就又牽扯到一個概念，'block split'，當資料檔案在備份cp時，因為oracle資料塊和作業系統塊的差異，一個資料塊可能由16個作業系統塊組成（8k 資料塊,512bytes 系統塊），這樣的話可能出現一個資料塊包含了幾個不同版本的作業系統塊，會導致資料塊的不一致，所以在備份模式下如果有語句對備份塊產生更新，那麼oracle會先把當前塊複製一份到redo，當恢復的時候如果碰到資料塊不一致就從redo把這個映象複製回去，然後在這個一致性的映象開始恢復。 如果使用rman來備份可以避免產生過多的塊，就像上面所說的，rman會去建議塊的一致性，所以不用複製映象塊到日誌。