要求歸檔模式
SQL>; archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 14
Next log sequence to archive 16
Current log sequence 16
-------------
先看用戶管理的熱備份
看看下面這個關(guān)鍵的操作，將備份的內(nèi)容置于backup模式,，用戶管理的聯(lián)機(jī)熱備份必需的操作,，不然copy備份的數(shù)據(jù)文件不能用來恢復(fù)，即使用某些放時恢復(fù)了也會丟數(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 ACTIVE
USERS表空間現(xiàn)在處于backup模式,，究竟這時候怎么了,？
在我們alter tablespace users begin backup 的時候是鎖定了users表空間對應(yīng)的數(shù)據(jù)文件頭的change scn。
首先考慮一下數(shù)據(jù)庫怎么用日志文件做恢復(fù)：查找不一致的數(shù)據(jù)文件（根據(jù)文件頭中舊的scn）
如果鎖定了文件頭,，這個文件頭中的scn就不會改變（當(dāng)然了數(shù)據(jù)塊還是會變化的,，還可以做讀寫）,。 然后就會應(yīng)用這個scn到現(xiàn)在的日志。
那我鎖定了scn,，不管你后邊怎么修改,，總之做恢復(fù)的時候是應(yīng)用鎖定的時候的scn一直到現(xiàn)在的日志（完全恢復(fù)的話）
舉個例子：
a,b兩個數(shù)據(jù)文件，把a(bǔ)置于備份模式,，b正常
這時候兩個change scn都是100,，然后開始備份
這期間有數(shù)據(jù)庫的修改，備份完成的時候,，Scn變成了200,。但是由于a的備份模式，所以a的文件頭中記錄的scn還是100,，b是200,。
某個時間，假設(shè)scn 500
這時候a丟失
copy回a的備份,，然后recover,完全恢復(fù)的話數(shù)據(jù)庫就應(yīng)用100—500這段的日志,，自然也就不會丟失數(shù)據(jù)了。
因?yàn)椴还茉谖襝opy備份的過程中你做什么操作,，總之都在鎖定的時change scn之后,，所以應(yīng)用的日志就不會有遺漏了。
這時候應(yīng)該能理解為什么要數(shù)據(jù)庫處于archived模式了
看看數(shù)據(jù)文件頭的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狀態(tài)的時候,，相應(yīng)的datafile的文件頭的scn就不會再發(fā)生改變，發(fā)生檢查點(diǎn)也不會改變,。
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.
------------------
再說說rman備份
個人認(rèn)為理解了用戶管理的熱備份,，rman就已經(jīng)理解了一大半了
rman 備份是針對塊一級的，支持增量備份,，稍后說怎么做的增量備份
Rman備份并不需要將數(shù)據(jù)庫或者表空間置于backup狀態(tài),，但是它會把scn記錄在catalog中對應(yīng)你的backupset
準(zhǔn)備在恢復(fù)的時候來使用
對users表空間做一個完全備份
$ rman target sys/oracle nocatalog
RMAN>; run {
2>; allocate channel d1 type disk;
3>; backup
4>; 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ù)的時候應(yīng)用546792開始到現(xiàn)在的歸檔日志和重做日志.
---------------
rman的增量備份的基本原理
其實(shí)原理很簡單,，主要就是弄明白怎么樣在做增量備份時確定某個數(shù)據(jù)塊需要備份,，哪個不需要
rman在做1級備份的時候怎么來確定0級備份之后都有哪些數(shù)據(jù)塊做了修改呢？看下面一段
Each data block in a datafile contains a system change number (SCN), which is the
SCN at which the most recent change was made to the block. During an incremental
backup, RMAN reads the SCN of each data block in the input file and compares it to
the checkpoint SCN of the parent incremental backup. If the SCN in the input data
block is greater than or equal to the checkpoint SCN of the parent, then RMAN copies
the block.
原來block里邊也有一個change scn
也就是說在做level 1級備份的時候,，需要掃描所有的數(shù)據(jù)塊并且用塊中記錄修改的SCN跟level 0備份時的SCN做比較(備份記錄中的Ckp SCN),，來確定這個塊是否需要備份。
所以掃描整個數(shù)據(jù)文件是不可避免的 ,！
這是傳統(tǒng)的rman做增量備份
在10g中rman做增量備份不再需要掃描整個數(shù)據(jù)文件了
10g引入的新特性 block change tracking：
Block change tracking進(jìn)程記錄自從上一次備份以來數(shù)據(jù)塊的變化,，并把這些信息記錄在跟蹤文件中。RMAN使用這個文件判斷增量備份中需要備份的變更數(shù)據(jù),。這極大的促進(jìn)了備份性能,，RMAN可以不再掃描整個文件以查找變更數(shù)據(jù)。
RMAN‘s change tracking feature for incremental backups improves incremental
backup performance by recording changed blocks in each datafile in a change tracking
file. If change tracking is enabled, RMAN uses the change tracking file to identify
changed blocks for incremental backup, thus avoiding the need to scan every block in
the datafile.
估計是使用的位圖文件做的記錄,！
附：
有興趣的可以看看dump的數(shù)據(jù)塊
通過下面的查詢找一個表對應(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 8
dump一個塊到udump的trc文件
SQL>; alter system dump datafile 5 block 81;
System altered.
在udump目錄找到對應(yīng)的trc文件,，找到dump那段
Start dump data blocks tsn: 6 file#: 5 minblk 81 maxblk 81
buffer tsn: 6 rdba: 0x01400051 (5/81)
scn: 0x0000.00086c4d seq: 0x01 flg: 0x04 tail: 0x4b502001
后面省略了
scn: 0x0000.00086c4d是16進(jìn)制你可以換算過來552013
你可以嘗試做一下修改，不過一定要保證對應(yīng)的塊被修改了,，并且被寫了,，才能反映出來
天涯明月刀 回復(fù)于：2005-08-27 20:07:22
:em06: 俺寫的貼子好像真的很少人回啊
連意見都沒有
bulletming 回復(fù)于：2005-08-28 06:03:03
絕對好文,支持!
remen 回復(fù)于：2005-08-28 08:31:47
樓主傷自尊了，呵呵,，支持一個
czpzc 回復(fù)于：2005-09-02 16:36:41
有點(diǎn)意思恍然大悟
*Daemon* 回復(fù)于：2005-09-02 17:51:30
支持樓主?。?br>
janews2005 回復(fù)于：2005-09-03 11:23:17
支持一下,！
janews2005 回復(fù)于：2005-09-03 11:26:34
樓主你好,！我是新手！可以教我一下雙機(jī)熱備份的具體的操作步驟嗎,！有文檔嗎,？可以發(fā)到我信箱里！
[email protected]
謝謝了,！
TigerEye 回復(fù)于：2005-09-03 13:53:17
缺少人氣
superscreen 回復(fù)于：2005-09-03 16:54:30
頂,，不錯，簡單明了
btw： end backup 的時候是根據(jù)控制文件中對應(yīng)的數(shù)據(jù)文件的結(jié)束scn來設(shè)置該數(shù)據(jù)文件頭中的開始scn的,，對吧,？oracle 為什么一定要鎖定這個scn呢，如果只是為了一個備份開始點(diǎn)的紀(jì)錄,，可以在內(nèi)存中紀(jì)錄阿,，是不是為了防止其他的事件之間的沖突？
天涯明月刀 回復(fù)于：2005-09-03 17:09:52
引用：原帖由 "superscreen" 發(fā)表：
oracle 為什么一定要鎖定這個scn呢,，如果只是為了一個備份開始點(diǎn)的紀(jì)錄,，可以在內(nèi)存中紀(jì)錄阿，是不是為了防止其他的事件之間的沖突,？
為了保證備份的文件里也有備份開始點(diǎn)的記錄阿
畢竟你是用的copy,，它不會自動給你保存開始點(diǎn)的記錄的
流川 回復(fù)于：2005-09-04 16:12:27
樓主的貼,,,都是好貼
小弟不才,,,,,,才識學(xué)淺
幫頂一個
wulang2005 回復(fù)于：2005-09-06 21:24:57
不好意思,我們用PostgreSQL做集群,還是支持一下.
blue_stone 回復(fù)于：2005-09-06 22:06:15
引用：原帖由 "superscreen" 發(fā)表：
頂，不錯,，簡單明了
btw： end backup 的時候是根據(jù)控制文件中對應(yīng)的數(shù)據(jù)文件的結(jié)束scn來設(shè)置該數(shù)據(jù)文件頭中的開始scn的,，對吧？oracle 為什么一定要鎖定這個scn呢,，如果只是為了一個備份開始點(diǎn)的紀(jì)錄,，可以在內(nèi)存?.........
如果這個時候系統(tǒng)掛了怎么辦呢？
內(nèi)存中的內(nèi)容都丟失了，恢復(fù)的時候怎么恢復(fù),？
麻雷 回復(fù)于：2005-09-10 22:04:05
很好,，支持。
星海夜航 回復(fù)于：2005-09-12 08:59:29
在tablespace被置為backup狀態(tài)后,對這個tablespace中數(shù)據(jù)得修改呢?是繼續(xù)改還是先放在臨時tablespace中,等end backup后再做修改?
天涯明月刀 回復(fù)于：2005-09-12 09:31:42
引用：原帖由 "星海夜航"]在tablespace被置為backup狀態(tài)后,對這個tablespace中數(shù)據(jù)得修改呢?是繼續(xù)改還是先放在臨時tablespace中,等end backup后再做修改?
發(fā)表：
跟平時一樣修改
只不過不會修改數(shù)據(jù)文件頭的change scn
星海夜航 回復(fù)于：2005-09-12 12:10:54
謝謝樓主
轉(zhuǎn)貼一些scn的文章,偶是新手,對scn不是很了解
關(guān)于scn的理解
系統(tǒng)檢查點(diǎn)scn(v$database(checkpoint_change#))
數(shù)據(jù)文件檢查點(diǎn)（v$datafile(checkpoint_change#)）
數(shù)據(jù)文件終止scn(v$datafile(last_change#))
數(shù)據(jù)文件中存放的檢查點(diǎn)
啟動scn (v$datafile_header(checkpoint_change#)
1,、系統(tǒng)檢查點(diǎn)scn
當(dāng)一個檢查點(diǎn)動作完成之后,，Oracle就把系統(tǒng)檢查點(diǎn)的SCN存儲到控制文件中。
select checkpoint_change# from v$database
2,、數(shù)據(jù)文件檢查點(diǎn)scn
當(dāng)一個檢查點(diǎn)動作完成后,，Oracle就把每個數(shù)據(jù)文件的scn單獨(dú)存放在控制文件中。
select name,checkpoint_change# from v$datafile
3,、啟動scn
Oracle把這個檢查點(diǎn)的scn存儲在每個數(shù)據(jù)文件的文件頭中,，這個值稱為啟動scn，
因?yàn)樗糜谠跀?shù)據(jù)庫實(shí)例啟動時,，檢查是否需要執(zhí)行數(shù)據(jù)庫恢復(fù),。
select name,checkpoint_change# from v$datafile_header
4、終止scn
每個數(shù)據(jù)文件的終止scn都存儲在控制文件中,。
select name,last_change# from v$datafile
在正常的數(shù)據(jù)庫操作過程中,，所有正處于聯(lián)機(jī)讀寫模式下的數(shù)據(jù)文件的終止scn都為null.
5、在數(shù)據(jù)庫運(yùn)行期間的scn值
在數(shù)據(jù)庫打開并運(yùn)行之后,，控制文件中的系統(tǒng)檢查點(diǎn),、控制文件中的數(shù)據(jù)文件檢查點(diǎn)scn
和每個數(shù)據(jù)文件頭中的啟動scn都是相同的?？刂莆募械拿總€數(shù)據(jù)文件的終止scn都為null.
在安全關(guān)閉數(shù)據(jù)庫的過程中,，系統(tǒng)會執(zhí)行一個檢查點(diǎn)動作，這時所有數(shù)據(jù)文件的終止scn
都會設(shè)置成數(shù)據(jù)文件頭中的那個啟動scn的值,。在數(shù)據(jù)庫重新啟動的時候,，
Oracle將文件頭中的那個啟動scn與數(shù)據(jù)庫文件檢查點(diǎn)scn進(jìn)行比較，
如果這兩個值相互匹配,，oracle接下來還要比較數(shù)據(jù)文件頭中的啟動scn和控制文件
中數(shù)據(jù)文件的終止scn,。如果這兩個值也一致，就意味著所有數(shù)據(jù)塊多已經(jīng)提交,，所有
對數(shù)據(jù)庫的修改都沒有在關(guān)閉數(shù)據(jù)庫的過程中丟失,，因此這次啟動數(shù)據(jù)庫的過程
也不需要任何恢復(fù)操作，此時數(shù)據(jù)庫就可以打開了,。當(dāng)所有的數(shù)據(jù)庫都打開之后,，
存儲在控制文件中的數(shù)據(jù)文件終止scn的值再次被更改為null，
這表示數(shù)據(jù)文件已經(jīng)打開并能夠正常使用了,。
------------------------------------------
澄清幾個概念
1)系統(tǒng)當(dāng)前SCN并不是在任何的數(shù)據(jù)庫操作發(fā)生時都會改變,SCN是在事務(wù)提交或回滾時改變,
2)在控制文件,數(shù)據(jù)文件頭,數(shù)據(jù)塊,日志文件頭,日志文件change vector中都有SCN,但其作用各不相同數(shù)據(jù)文件頭中包含了該數(shù)據(jù)文件的checkpoint SCN,表示給數(shù)據(jù)文件最近一次執(zhí)行檢查點(diǎn)操作時的SCN.日志文件頭中包含了low scn,next scn,表示給日志文件包含有從low scn到next scn的redo record.控制文件中包含了每個數(shù)據(jù)文件的checkpoint SCN,stop SCN,每個日志文件的low scn,next scn.控制文件中checkpoint scn同數(shù)據(jù)文件頭中checkpoint scn相同,除非數(shù)據(jù)文件被手工替換掉.控制文件中的low scn,next scn同日志文件中l(wèi)ow scn和next scn相同在數(shù)據(jù)庫正常運(yùn)行時,控制文件中對應(yīng)數(shù)據(jù)文件的stop SCN都是最大值.在正常關(guān)閉數(shù)據(jù)庫的情況下,在關(guān)閉前會執(zhí)行一次檢查點(diǎn)工作當(dāng)oracle會將數(shù)據(jù)緩沖區(qū)上的內(nèi)容全部寫回到磁盤中,然后更新控制文件中對應(yīng)數(shù)據(jù)文件的stop SCN,使其等于checkpoint SCN
但在異常當(dāng)機(jī)的情況下,由于最后一次檢查點(diǎn)未進(jìn)行或進(jìn)行中間被中止,因而在控制文件,就存在部分的數(shù)據(jù)文件stop SCN為最大值,在數(shù)據(jù)庫重新啟動后,會檢查控制文件中對應(yīng)每個數(shù)據(jù)文件的stop SCN,如果stop SCN不等于控制文件中對應(yīng)每個數(shù)據(jù)文件的checkpoint SCN,就會使用日志文件redo從checkpoint SCN開頭到stop SCN為止的全部數(shù)據(jù)庫操作.在定位到底是使用哪一個redo log文件時,就用到了日志文件頭中的low scn,next scn,也就是說要使用的redo log 的low scn ,next scn必須包含數(shù)據(jù)文件重做所須的change vector.
在確定了哪個數(shù)據(jù)文件須redo后,oracle會比較change vector中的SCN和數(shù)據(jù)文件數(shù)據(jù)塊中的SCN,如果change vector的SCN小于數(shù)據(jù)塊的scn,則跳過此change vector,否則redo
數(shù)據(jù)塊中ITL中還有SCN,但它的作用是用于產(chǎn)生一致性讀快照 | | |
|
