oracle 熱備份

Oracle 熱備份是指數據庫處於open狀態下，對數據庫的數據文件、控制文件、參數文件、密碼文件等
進行一系列備份操作。

熱備是基於用戶管理備份恢復的一種方式，也是除了RMAN備份之外較爲常用的一種備份方式。

進行oracle熱備份日誌必須開啓歸檔模式（數據庫在mount狀態下運行----alter  database archivelog）

SQL> startup  mount;
ORACLE instance started.

Total System Global Area  524288000 bytes
Fixed Size          2022016 bytes
Variable Size         159384960 bytes
Database Buffers      356515840 bytes
Redo Buffers            6365184 bytes
Database mounted.

SQL> archive log list（查看日誌是否歸檔）
Database log mode          Archive Mode
Automatic archival         Enabled
Archive destination        USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     5
Next log sequence to archive   7
Current log sequence           7

SQL> select log_mode from v$database;（查看日誌是否歸檔）

LOG_MODE
------------
ARCHIVELOG
@@@@@
基於表空間的熱備份實驗：
SQL> select checkpoint_change#,name from v$datafile;

CHECKPOINT_CHANGE# NAME
------------------ ----------------------------------------------------------------------------------------------------
        674728 /u01/app/oracle/oradata/orcl/system01.dbf
        674728 /u01/app/oracle/oradata/orcl/undotbs01.dbf
        674728 /u01/app/oracle/oradata/orcl/sysaux01.dbf
        674728 /u01/app/oracle/oradata/orcl/users01.dbf
        674728 /u01/app/oracle/oradata/orcl/example01.dbf


SQL> alter tablespace users begin backup;鎖定了users表空間對應的數據文件頭的change scn。
    數據庫怎麼用日誌文件做恢復：查找不一致的數據文件（根據文件頭中舊的scn）
    如果鎖定了文件頭，這個文件頭中的scn就不會改變（當然了數據塊還是會變化的，還可以做讀寫）。
   然後就會應用這個scn到現在的日誌。
    那我鎖定了scn，不管你後邊怎麼修改，總之做恢復的時候是應用鎖定的時候的scn一直到現在的日誌
  （完全恢復的話）


SQL> select * from v$backup;

     FILE# STATUS        CHANGE# TIME
---------- ------------------ ---------- ------------------
     1 NOT ACTIVE              0
     2 NOT ACTIVE              0
     3 NOT ACTIVE              0
     4 ACTIVE         676082 02-MAR-13
     5 NOT ACTIVE              0

路徑（/u01/app/oracle/oradata/orcl）
 [oracle@station7 orcl]$ cp users01.dbf /home/oracle/backup/（備份users表空間）

SQL> alter tablespace users end backup;

SQL> select * from v$backup;

     FILE# STATUS        CHANGE# TIME
---------- ------------------ ---------- ------------------
     1 NOT ACTIVE              0
     2 NOT ACTIVE              0
     3 NOT ACTIVE              0
     4 NOT ACTIVE         676082 02-MAR-13
     5 NOT ACTIVE              0
@@@@@
熱備份時相關SCN 如何處理？

在開始進行熱備份時，數據文件頭的checkpoint scn 和控制文件中該文件的scn lock住，
但是數據文件的dml操作可以正常進行，也就意味着block 的scn 是正常增加的，數據文件並沒有鎖定。
爲什麼要Lock 文件的checkpoint scn（實際上對應了恢復時的rba）
 主要是爲了標示進行恢復操作時需要的redo log， 這樣就可以保證數據文件內所有的塊都能得到恢復，
因爲在進行數據文件拷貝時無法保證數據文件頭是最先拷貝完成的。
如果先拷貝的是數據文件的其他部分然後才 去拷貝的數據文件頭，
這時候很有可能數據文件頭的checkpoint scn已經改變了而恢復時應用redo log的範圍是由數據文件頭的rba決定的。
當熱備份結束時，在備份結束的時候，oracle會把數據文件頭和control文件中關於這個數據文件的ＳＣＮ號
更新爲數據庫的ＳＣＮ號

@@@@
表空間級檢查點
爲什麼儲存在CONTROL FILE中要分爲兩個地方(SYSTEM CHECKPOINT SCN,DATAFILE CHECKPOINT SCN) ?

當你把一個tbs設爲read-only時，他的SCN會凍結停止，此時DATAFILE CHECKPOINT SCN是不會再遞增改變的，
 但是整體的SYSTEM CHECKPOINT SCN卻仍然會不斷遞增前進。
所以，這就是爲什麼需要分別在兩個地方儲存SCN。
--測試前
SQL> select checkpoint_change#,name from v$database ;

CHECKPOINT_CHANGE# NAME
------------------ ---------
        678717 ORCL

SQL> select checkpoint_change#,name from v$datafile where name like '%user%';

CHECKPOINT_CHANGE#
------------------
NAME
--------------------------------------------------------------------------------
        678717
/u01/app/oracle/oradata/orcl/users01.dbf


--測試
SQL> alter tablespace users read only;

Tablespace altered


--測試後
SQL> select checkpoint_change#,name from v$database ;

CHECKPOINT_CHANGE# NAME
------------------ ---------
        678717（不變） ORCL

SQL> select checkpoint_change#,name from v$datafile where name like '%user%';

CHECKPOINT_CHANGE#
------------------
NAME
--------------------------------------------------------------------------------
        679072（增加）
/u01/app/oracle/oradata/orcl/users01.dbf

@@@@@

select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
--------------------
293184
select name,checkpoint_change#,last_change# from v$datafile where name like '%user%';
NAME CHECKPOINT_CHANGE# LAST_CHANGE#
----------------------------------- -------------------- --------------
/u02/oradata/OMFD1/users01.dbf 293184 293184
正常shutdown database後，SCN會發生什麼變化？
我們可以把數據庫開在mount mode
可以看到儲存在control file中的三個SCN位置都是相同，注意此時的stop scn不會是NULL，而是等於start scn


我們來查詢datafile header SCN:
select name,checkpoint_change# from v$datafile_header where name like '%users01%';
NAME CHECKPOINT_CHANGE#
----------------------------------- --------------------
/u02/oradata/OMFD1/users01.dbf 293184

當clean shutdown 時，checkpoint會進行，並且此時datafile的stop scn和start scn會相同。
 等到我門開啓數據庫時，Oracle檢查datafile header中的start scn和存於control file中的datafile的scn
 是否相同，
 如果相同，接着檢查start scn和stop scn是否相同，如果仍然相同，數據庫就會正常開啓，
 否則就需要recovery...
 等到數據庫開啓後，儲存在control file中的stop scn就會恢復爲NULL值，
 此時表示datafile是open在正常模式下了。
@@@@@
crash recovery 和media recovery 的比較
啓動數據庫時，如果發現STOP SCN = NULL，表示需要進行crash recovery；啓動數據庫時，
如果發現有datafile header的START SCN 不等於儲存於CONTROLFILE的DATAFILE SCN，
表示需要進行Media recovery