熱備份原理分析
2024-07-21 02:34:24
供稿：網(wǎng)友
我們都知道Oracle的備份有幾鐘方式，冷備，熱備，rman，imp等，我們注重到當(dāng)我們采取熱備的時(shí)候，需要對(duì)每個(gè)要備份的表空間置為backup模式。通常的熱備腳本都是這樣的
alter tablespace XXX begin backup;
cp XXX ....
alter tablespace XXX end backup;
（這里需要注重一點(diǎn)，oracle的最小存儲(chǔ)單位是一個(gè)數(shù)據(jù)塊，一個(gè)塊的大小通常設(shè)置為8k，而操作系統(tǒng)的塊通常是512bytes，這樣的話(huà)一個(gè)oracle的數(shù)據(jù)由很多個(gè)操作系統(tǒng)的塊組成。而且對(duì)于一個(gè)數(shù)據(jù)文件來(lái)說(shuō)，它的所有塊對(duì)應(yīng)的操作系統(tǒng)的塊并不是按順序存儲(chǔ)的，當(dāng)運(yùn)行cp
等操作系統(tǒng)命令時(shí)并不能指定從那個(gè)oracle數(shù)據(jù)塊開(kāi)始拷貝。）
當(dāng)open數(shù)據(jù)庫(kù)的時(shí)候，oracle會(huì)去比較控制文件中數(shù)據(jù)文件記錄和數(shù)據(jù)文件頭的checkpoint cnt，假如兩者相同，則判定不需要介質(zhì)恢復(fù)，假如不同，這時(shí)候oracle就會(huì)報(bào)某某文件需要介質(zhì)恢復(fù)。然后拷貝回?cái)?shù)據(jù)文件備份我們開(kāi)始recover，這時(shí)候就從上次做備份時(shí)的scn開(kāi)始恢復(fù)，運(yùn)用日志，直到恢復(fù)結(jié)束。當(dāng)cp數(shù)據(jù)文件時(shí)，比如說(shuō)我們拷貝的第一個(gè)塊可能是scn為100的數(shù)據(jù)塊，當(dāng)我們完成這個(gè)塊的拷貝后，這個(gè)塊有可能被別的進(jìn)程多次修改，scn變?yōu)?00。我們知道當(dāng)數(shù)據(jù)庫(kù)發(fā)生檢查點(diǎn)時(shí)會(huì)去更新數(shù)據(jù)文件頭和控制文件中的checkpoint scn，假如當(dāng)我們?cè)赾p數(shù)據(jù)文件的同時(shí)發(fā)生了n次checkpoint，這時(shí)候數(shù)據(jù)文件頭的scn可能被更新了很多次。這時(shí)候cp的進(jìn)程去拷貝數(shù)據(jù)文件頭所在的操作系統(tǒng)塊，可能這個(gè)數(shù)據(jù)文件頭的塊因?yàn)楸籧heckpoint了很多次導(dǎo)致它的scn為1000，這時(shí)候整個(gè)數(shù)據(jù)文件會(huì)出現(xiàn)不一致，當(dāng)用這個(gè)備份文件去恢復(fù)時(shí)，恢復(fù)進(jìn)程會(huì)從scn＝1000開(kāi)始恢復(fù)，這樣的話(huà)開(kāi)始那個(gè)scn=100的塊將丟失從scn100-scn1000的數(shù)據(jù)，因?yàn)閿?shù)據(jù)塊并不應(yīng)用scn在1000以前的日志,而且這樣做的話(huà)可能出現(xiàn)一些數(shù)據(jù)塊的corruption，所以不置成backup模式備份的話(huà)并不可取。當(dāng)然，假如你能確保當(dāng)cp的時(shí)候不發(fā)生checkpoint，或者你的操作系統(tǒng)塊的大小不小于oracle的數(shù)據(jù)塊大小，這些情況下不置backup mode拷貝出來(lái)的文件也是有效的。現(xiàn)在我們知道了為什么不能不設(shè)置backup模式，下面來(lái)講講alter tablespace XXX begin backup做了什么？
當(dāng)數(shù)據(jù)文件置于backup模式時(shí)，oracle會(huì)去鎖定數(shù)據(jù)文件頭，這時(shí)候數(shù)據(jù)庫(kù)發(fā)生檢查點(diǎn)的話(huà)將不會(huì)修改文件頭的checkpoint scn，而只是增加checkpoint cnt，所以不管執(zhí)行cp的時(shí)候操作系統(tǒng)塊的拷貝順序是如何，oracle總會(huì)從文件頭的scn開(kāi)始恢復(fù)，這樣的話(huà)也就避免了數(shù)據(jù)丟失和數(shù)據(jù)塊corruption.假如大家用的是rman來(lái)備份，那么就不會(huì)有這個(gè)問(wèn)題，因?yàn)閞man備份的時(shí)候rman會(huì)去對(duì)比數(shù)據(jù)塊的頭尾標(biāo)志，假如發(fā)現(xiàn)不一致，那么它將會(huì)再去讀這個(gè)塊，直到讀到一致的塊才往備份集里寫(xiě)。 但是alter tablespace XXX begin backup帶來(lái)的另一個(gè)問(wèn)題是會(huì)導(dǎo)致產(chǎn)生多余的日志，通過(guò)一個(gè)小小的試驗(yàn)就可以證實(shí)這一點(diǎn)。SQL> select name,value from v$sysstat where name='redo size';NAME VALUE
---------------------------------------------------------------- ----------
redo size 43408SQL> 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. 一個(gè)update的動(dòng)作產(chǎn)生44060－43408＝652bytes的redo把表空間置為backup modeSQL> alter tablespace test begin backup;Tablespace altered.SQL> select name,value from v$sysstat where name='redo size';NAME VALUE
---------------------------------------------------------------- ----------
redo size 44732SQL> 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.一個(gè)update的動(dòng)作產(chǎn)生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
...... (改動(dòng)向量1，記載對(duì)undo header事務(wù)表的修改)
CHANGE #2 TYP:0 CLS:30 AFN:33 DBA:0x0840002e SCN:0x0000.19ed24f0 SEQ: 1 OP:5.1
...... (改動(dòng)向量2，記載對(duì)undo block的修改)
CHANGE #3 TYP:2 CLS: 1 AFN:51 DBA:0x0cc0000f SCN:0x0000.19ed24e8 SEQ: 1 OP:11.5
KTB Redo (改動(dòng)向量3，記載對(duì)數(shù)據(jù)塊的修改，也就是在數(shù)據(jù)塊上執(zhí)行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
......(改動(dòng)向量4，一些標(biāo)記）
我們看到了正常的日志記錄，此外還有些block cleanout及回滾段改變的日志記錄，但是相比較不是backup模式的日志來(lái)說(shuō)多了這一部分。
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.]
......
這一部分是對(duì)更改的數(shù)據(jù)塊做的一個(gè)鏡像，把這個(gè)塊完全記錄到redo里面去了，但是為什么要這么做呢。
這就又牽扯到一個(gè)概念，'block split'，當(dāng)數(shù)據(jù)文件在備份cp時(shí)，因?yàn)閛racle數(shù)據(jù)塊和操作系統(tǒng)塊的差異，一個(gè)數(shù)據(jù)塊可能由16個(gè)操作系統(tǒng)塊組成（8k 數(shù)據(jù)塊,512bytes 系統(tǒng)塊），這樣的話(huà)可能出現(xiàn)一個(gè)數(shù)據(jù)塊包含了幾個(gè)不同版本的操作系統(tǒng)塊，會(huì)導(dǎo)致數(shù)據(jù)塊的不一致，所以在備份模式下假如有語(yǔ)句對(duì)備份塊產(chǎn)生更新，那么oracle會(huì)先把當(dāng)前塊復(fù)制一份到redo，當(dāng)恢復(fù)的時(shí)候假如碰到數(shù)據(jù)塊不一致就從redo把這個(gè)鏡像拷貝回去，然后在這個(gè)一致性的鏡像開(kāi)始恢復(fù)。 假如使用rman來(lái)備份可以避免產(chǎn)生過(guò)多的塊，就像上面所說(shuō)的，rman會(huì)去建議塊的一致性，所以不用復(fù)制鏡像塊到日志。
