oracle聯機熱備份的原理

要求歸檔模式

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



-------------

先看用戶管理的熱備份

看看下面這個關鍵的操作，將備份的內容置于backup模式，用戶管理的聯機熱備份必需的操作，

不然copy備份的數據文件不能用來恢復，即使用某些放時恢復了也會丟數據

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表空間現在處于backup模式，究竟這時候怎么了？

在我們alter tablespace users begin backup 的時候是

鎖定了users表空間對應的數據文件頭的change scn。

首先考慮一下數據庫怎么用日志文件做恢復：查找不一致的數據文件（根據文件頭中舊的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.



------------------

再說說rman備份

個人認為理解了用戶管理的熱備份，rman就已經理解了一大半了

rman 備份是針對塊一級的，支持增量備份，稍后說怎么做的增量備份



Rman備份并不需要將數據庫或者表空間置于backup狀態，但是它會把scn記錄

在catalog中對應你的backupset準備在恢復的時候來使用



對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

恢復的時候應用546792開始到現在的歸檔日志和重做日志.

---------------

rman的增量備份的基本原理

其實原理很簡單，主要就是弄明白怎么樣在做增量備份時確定某個數據塊需要備份，哪個不需要

rman在做1級備份的時候怎么來確定0級備份之后都有哪些數據塊做了修改呢？看下面一段

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級備份的時候，需要掃描所有的數據塊并且用塊中記錄修改的SCN

跟level 0備份時的SCN做比較(備份記錄中的Ckp SCN)，來確定這個塊是否需要備份。

所以掃描整個數據文件是不可避免的 ！

這是傳統的rman做增量備份

在10g中rman做增量備份不再需要掃描整個數據文件了

10g引入的新特性 block change tracking：

Block change tracking進程記錄自從上一次備份以來數據塊的變化，并把這些信息記錄在跟蹤文件中。

RMAN使用這個文件判斷增量備份中需要備份的變更數據。這極大的促進了備份性能，

RMAN可以不再掃描整個文件以查找變更數據。

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的數據塊

通過下面的查詢找一個表對應的數據塊

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目錄找到對應的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進制你可以換算過來552013

你可以嘗試做一下修改，不過一定要保證對應的塊被修改了，并且被寫了，才能反映出來。 

原文轉自：http://www.kjueaiud.com