oracle聯(lián)機(jī)熱備份的原理
2024-08-29 13:44:22
供稿：網(wǎng)友
要求歸檔模式SQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination USE_DB_RECOVERY_FILE_DESTOldest online log sequence 14Next log sequence to archive 16Current log sequence 16-------------先看用戶(hù)治理的熱備份看看下面這個(gè)要害的操作，將備份的內(nèi)容置于backup模式，用戶(hù)治理的聯(lián)機(jī)熱備份必需的操作，不然copy備份的數(shù)據(jù)文件不能用來(lái)恢復(fù)，即使用某些放時(shí)恢復(fù)了也會(huì)丟數(shù)據(jù)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/u02/oradata/sales/perfstat.dbf PERFSTAT NOT ACTIVEUSERS表空間現(xiàn)在處于backup模式，究竟這時(shí)候怎么了？在我們alter tablespace users begin backup 的時(shí)候是鎖定了users表空間對(duì)應(yīng)的數(shù)據(jù)文件頭的change scn。首先考慮一下數(shù)據(jù)庫(kù)怎么用日志文件做恢復(fù)：查找不一致的數(shù)據(jù)文件（根據(jù)文件頭中舊的scn）假如鎖定了文件頭，這個(gè)文件頭中的scn就不會(huì)改變（當(dāng)然了數(shù)據(jù)塊還是會(huì)變化的，還可以做讀寫(xiě)）。 然后就會(huì)應(yīng)用這個(gè)scn到現(xiàn)在的日志。那我鎖定了scn，不管你后邊怎么修改，總之做恢復(fù)的時(shí)候是應(yīng)用鎖定的時(shí)候的scn一直到現(xiàn)在的日志（完全恢復(fù)的話(huà)）舉個(gè)例子：a,b兩個(gè)數(shù)據(jù)文件，把a(bǔ)置于備份模式，b正常這時(shí)候兩個(gè)change scn都是100，然后開(kāi)始備份這期間有數(shù)據(jù)庫(kù)的修改，備份完成的時(shí)候，Scn變成了200。但是由于a的備份模式，所以a的文件頭中記錄的scn還是100，b是200。某個(gè)時(shí)間，假設(shè)scn 500這時(shí)候a丟失copy回a的備份，然后recover,完全恢復(fù)的話(huà)數(shù)據(jù)庫(kù)就應(yīng)用100—500這段的日志，自然也就不會(huì)丟失數(shù)據(jù)了。因?yàn)椴还茉谖襝opy備份的過(guò)程中你做什么操作，總之都在鎖定的時(shí)change scn之后，所以應(yīng)用的日志就不會(huì)有遺漏了。這時(shí)候應(yīng)該能理解為什么要數(shù)據(jù)庫(kù)處于archived模式了看看數(shù)據(jù)文件頭的change scnSQL>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 5459266 rows selected.顯然，在將users表空間置于backup狀態(tài)的時(shí)候，相應(yīng)的datafile的文件頭的scn就不會(huì)再發(fā)生改變，發(fā)生檢查點(diǎn)也不會(huì)改變。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 5461966 rows selected.下面end backup,看看scnSQL> 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 5464676 rows selected.------------------再說(shuō)說(shuō)rman備份個(gè)人認(rèn)為理解了用戶(hù)治理的熱備份，rman就已經(jīng)理解了一大半了rman 備份是針對(duì)塊一級(jí)的，支持增量備份，稍后說(shuō)怎么做的增量備份Rman備份并不需要將數(shù)據(jù)庫(kù)或者表空間置于backup狀態(tài)，但是它會(huì)把scn記錄在catalog中對(duì)應(yīng)你的backupset預(yù)備在恢復(fù)的時(shí)候來(lái)使用對(duì)users表空間做一個(gè)完全備份$ rman target sys/Oracle nocatalogRMAN> run {2> allocate channel d1 type disk;3> backup4> format='/u03/oraclebk/%d_%N_%s.bk' tablespace users;5> release channel d1;6> }看一下備份集里都有什么，注重看Ckp SCN 546792,RMAN> list backup of tablespace users;List of Backup Sets===================BS Key Type LV Size Device Type Elapsed Time Completion Time------- ---- -- ---------- ----------- ------------ ---------------3 Full 1M DISK 00:00:02 31-MAR-05 BP Key: 3 Status: AVAILABLE ComPRessed: NO Tag: TAG20050331T153729 Piece Name: /u03/oraclebk/SALES_USERS_4.bk List of Datafiles in backup set 3 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 4 Full 546792 31-MAR-05 /u02/oradata/sales/users01.dbf恢復(fù)的時(shí)候應(yīng)用546792開(kāi)始到現(xiàn)在的歸檔日志和重做日志.---------------rman的增量備份的基本原理其實(shí)原理很簡(jiǎn)單，主要就是弄明白怎么樣在做增量備份時(shí)確定某個(gè)數(shù)據(jù)塊需要備份，哪個(gè)不需要rman在做1級(jí)備份的時(shí)候怎么來(lái)確定0級(jí)備份之后都有哪些數(shù)據(jù)塊做了修改呢？看下面一段Each data block in a datafile contains a system change number (SCN), which is theSCN at which the most recent change was made to the block. During an incrementalbackup, RMAN reads the SCN of each data block in the input file and compares it tothe checkpoint SCN of the parent incremental backup. If the SCN in the input datablock is greater than or equal to the checkpoint SCN of the parent, then RMAN copiesthe block.原來(lái)block里邊也有一個(gè)change scn也就是說(shuō)在做level 1級(jí)備份的時(shí)候，需要掃描所有的數(shù)據(jù)塊并且用塊中記錄修改的SCN跟level 0備份時(shí)的SCN做比較(備份記錄中的Ckp SCN)，來(lái)確定這個(gè)塊是否需要備份。所以?huà)呙枵麄€(gè)數(shù)據(jù)文件是不可避免的 ！這是傳統(tǒng)的rman做增量備份
在10g中rman做增量備份不再需要掃描整個(gè)數(shù)據(jù)文件了10g引入的新特性 block change tracking：Block change tracking進(jìn)程記錄自從上一次備份以來(lái)數(shù)據(jù)塊的變化，并把這些信息記錄在跟蹤文件中。RMAN使用這個(gè)文件判定增量備份中需要備份的變更數(shù)據(jù)。這極大的促進(jìn)了備份性能，RMAN可以不再掃描整個(gè)文件以查找變更數(shù)據(jù)。RMAN's change tracking feature for incremental backups improves incrementalbackup performance by recording changed blocks in each datafile in a change trackingfile. If change tracking is enabled, RMAN uses the change tracking file to identifychanged blocks for incremental backup, thus avoiding the need to scan every block inthe datafile.估計(jì)是使用的位圖文件做的記錄！附：有愛(ài)好的可以看看dump的數(shù)據(jù)塊通過(guò)下面的查詢(xún)找一個(gè)表對(duì)應(yīng)的數(shù)據(jù)塊SQL> select file_id,block_id,blocks 2 from dba_extents 3 where segment_name='EMPLOYEES'; FILE_ID BLOCK_ID BLOCKS---------- ---------- ---------- 5 81 8dump一個(gè)塊到udump的trc文件SQL> alter system dump datafile 5 block 81;System altered.在udump目錄找到對(duì)應(yīng)的trc文件，找到dump那段Start dump data blocks tsn: 6 file#: 5 minblk 81 maxblk 81buffer tsn: 6 rdba: 0x01400051 (5/81)scn: 0x0000.00086c4d seq: 0x01 flg: 0x04 tail: 0x4b502001后面省略了scn: 0x0000.00086c4d是16進(jìn)制你可以換算過(guò)來(lái)552013你可以嘗試做一下修改，不過(guò)一定要保證對(duì)應(yīng)的塊被修改了，并且被寫(xiě)了，才能反映出來(lái)。
