| 導購 | 订阅 | 在线投稿
分享
 
 
 

帶你深入了解Oracle數據庫的熱備份原理

來源:互聯網  2008-06-01 03:26:45  評論

這篇論壇文章(賽迪網技術社區)深入分析了Oracle數據庫的熱備份原理,更多內容請參考下文。

我們都知道oracle的備份有幾鍾方式,冷備,熱備,rman,imp等,我們注意到當我們采取熱備的時候,需要對每個要備份的表空間置爲backup模式。通常的熱備腳本都是這樣的:

alter tablespace XXX begin backup;

cp XXX ....

alter tablespace XXX end backup;

(這裏需要注意一點,oracle的最小存儲單位是一個數據塊,一個塊的大小通常設置爲8k,而操作系統的塊通常是512bytes,這樣的話一個oracle的數據由很多個操作系統的塊組成。而且對于一個數據文件來說,它的所有塊對應的操作系統的塊並不是按順序存儲的,當運行cp等操作系統命令時並不能指定從那個oracle數據塊開始拷貝。)當open數據庫的時候,oracle會去比較控制文件中數據文件記錄和數據文件頭的checkpoint cnt,如果兩者相同,則判斷不需要介質恢複,如果不同,這時候oracle就會報某某文件需要介質恢複。然後拷貝回數據文件備份我們開始recover,這時候就從上次做備份時的scn開始恢複,運用日志,直到恢複結束。當cp數據文件時,比如說我們拷貝的第一個塊可能是scn爲100的數據塊,當我們完成這個塊的拷貝後,這個塊有可能被別的進程多次修改,scn變爲900。我們知道當數據庫發生檢查點時會去更新數據文件頭和控制文件中的checkpoint scn,如果當我們在cp數據文件的同時發生了n次checkpoint,這時候數據文件頭的scn可能被更新了很多次。這時候cp的進程去拷貝數據文件頭所在的操作系統塊,可能這個數據文件頭的塊因爲被checkpoint了很多次導致它的scn爲1000,這時候整個數據文件會出現不一致,當用這個備份文件去恢複時,恢複進程會從scn=1000開始恢複,這樣的話開始那個scn=100的塊將丟失從scn100-scn1000的數據,因爲數據塊並不應用scn在1000以前的日志,而且這樣做的話可能出現一些數據塊的corruption,所以不置成backup模式備份的話並不可取。當然,如果你能確保當cp的時候不發生checkpoint,或者你的操作系統塊的大小不小于oracle的數據塊大小,這些情況下不置backup mode拷貝出來的文件也是有效的。

現在我們知道了爲什麽不能不設置backup模式,下面來講講alter tablespace XXX begin backup做了什麽?

當數據文件置于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會去建議塊的一致性,所以不用複制鏡像塊到日志。

這篇論壇文章(賽迪網技術社區)深入分析了Oracle數據庫的熱備份原理,更多內容請參考下文。 我們都知道oracle的備份有幾鍾方式,冷備,熱備,rman,imp等,我們注意到當我們采取熱備的時候,需要對每個要備份的表空間置爲backup模式。通常的熱備腳本都是這樣的: alter tablespace XXX begin backup; cp XXX .... alter tablespace XXX end backup; (這裏需要注意一點,oracle的最小存儲單位是一個數據塊,一個塊的大小通常設置爲8k,而操作系統的塊通常是512bytes,這樣的話一個oracle的數據由很多個操作系統的塊組成。而且對于一個數據文件來說,它的所有塊對應的操作系統的塊並不是按順序存儲的,當運行cp等操作系統命令時並不能指定從那個oracle數據塊開始拷貝。)當open數據庫的時候,oracle會去比較控制文件中數據文件記錄和數據文件頭的checkpoint cnt,如果兩者相同,則判斷不需要介質恢複,如果不同,這時候oracle就會報某某文件需要介質恢複。然後拷貝回數據文件備份我們開始recover,這時候就從上次做備份時的scn開始恢複,運用日志,直到恢複結束。當cp數據文件時,比如說我們拷貝的第一個塊可能是scn爲100的數據塊,當我們完成這個塊的拷貝後,這個塊有可能被別的進程多次修改,scn變爲900。我們知道當數據庫發生檢查點時會去更新數據文件頭和控制文件中的checkpoint scn,如果當我們在cp數據文件的同時發生了n次checkpoint,這時候數據文件頭的scn可能被更新了很多次。這時候cp的進程去拷貝數據文件頭所在的操作系統塊,可能這個數據文件頭的塊因爲被checkpoint了很多次導致它的scn爲1000,這時候整個數據文件會出現不一致,當用這個備份文件去恢複時,恢複進程會從scn=1000開始恢複,這樣的話開始那個scn=100的塊將丟失從scn100-scn1000的數據,因爲數據塊並不應用scn在1000以前的日志,而且這樣做的話可能出現一些數據塊的corruption,所以不置成backup模式備份的話並不可取。當然,如果你能確保當cp的時候不發生checkpoint,或者你的操作系統塊的大小不小于oracle的數據塊大小,這些情況下不置backup mode拷貝出來的文件也是有效的。 現在我們知道了爲什麽不能不設置backup模式,下面來講講alter tablespace XXX begin backup做了什麽? 當數據文件置于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會去建議塊的一致性,所以不用複制鏡像塊到日志。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有