冷備下類比rm -rf *.dbf恢複案例

冷備下類比rm -rf *.dbf恢複案例

關於備份恢複一直是所有關係型資料庫的重頭戲。下面會介紹冷備資料庫，並類比破壞資料檔案進行恢複資料庫，並涉及到其他相關內容。
[Oracle@localhost ~]$ cat /etc/RedHat-release
Red Hat Enterprise Linux Server release 5.5 (Tikanga)

SQL> select * from v$version where rownum<2;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
首先介紹一下冷備份（完全離線備份），需要把資料庫shutdown後，粘貼複製就可了，先備份先：
SQL> shutdown immediate;
資料庫已經關閉。
已經卸載資料庫。
ORACLE 常式已經關閉。

[oracle@localhost orcl3939]$ cp *.dbf  /home/oracle/beifeng
[oracle@localhost orcl3939]$ cp *.log  /home/oracle/beifeng
[oracle@localhost orcl3939]$ cp *.ctl  /home/oracle/beifeng
控制檔案只需要備份一份就行了，因為是鏡像檔案，完全一樣。
是不是很簡單！
這種方式適合archivelog和noarchivelog,其中涉及到了幾類檔案：
logfile:v$log  v$logfile
controlfile:v$controlfile
datafile:dba_data_files
temp files:dba_temp_files
其中的臨時檔案並不是我們備份的對象，因為備份檔案可以理解成資料庫的虛擬記憶體，如linux中，我們分區時，如果記憶體較小時，可以分配swap分區，作用是交換快取資料,作為記憶體不足的一種選擇而已。
關於archivelog和noarchivelog，生產環境中幾乎都是archivelog：
SQL> archive log list;
資料庫記錄模式            非存檔模式
自動封存            禁用
存檔終點            USE_DB_RECOVERY_FILE_DEST
最早的聯機日誌序列    424
當前日誌序列          426

此時我的練習庫是非歸檔模式，那我們啟動歸檔模式：
SQL> startup mount;
ORACLE 常式已經啟動。
SQL> alter database archivelog;
資料庫已更改。

SQL> select log_mode from v$database;

LOG_MODE
------------
ARCHIVELOG

此時資料庫已經是歸檔模式。
關于歸檔檔案存放位置，看參數：

SQL> show parameter db_recover
NAME                                TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      /u01/app/oracle/flash_recovery
                                                _area
db_recovery_file_dest_size          big integer 3852M

第一個參數是存放位置，第二個參數是該空間的大小。
flash_recovery _area目錄是10g才有的，便於管理歸檔等檔案。
我們可以修改db_recovery_file_dest：
SQL> alter system set db_recovery_file_dest =' ';
系統已更改。
SQL>  show parameter db_recover
NAME                                TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string
db_recovery_file_dest_size          big integer 3852M

此時歸檔檔案存放的目錄回到了10g之前：
SQL> show parameter log_archive_dest
NAME                                TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest                    string
log_archive_dest_1                  string
log_archive_dest_10                  string
log_archive_dest_11                  string
log_archive_dest_12                  string
log_archive_dest_13                  string
log_archive_dest_14                  string
log_archive_dest_15                  string
log_archive_dest_16                  string
log_archive_dest_17                  string
log_archive_dest_18                  string
NAME                                TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_19                  string
log_archive_dest_2                  string
log_archive_dest_20                  string
log_archive_dest_21                  string
log_archive_dest_22                  string
log_archive_dest_23                  string
log_archive_dest_24                  string
log_archive_dest_25                  string
log_archive_dest_26                  string
log_archive_dest_27                  string
log_archive_dest_28                  string
NAME                                TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_29                  string
log_archive_dest_3                  string
log_archive_dest_30                  string
log_archive_dest_31                  string
log_archive_dest_4                  string
log_archive_dest_5                  string
log_archive_dest_6                  string
log_archive_dest_7                  string
log_archive_dest_8                  string
log_archive_dest_9                  string

指定目錄位置即可用，但是這樣很不利於管理。

簡介下SCN:System change number | System Commit Number 但是很多情況下理解成第一種更為準確。

SQL> select current_scn from v$database;
CURRENT_SCN
-----------
          0
SQL> alter database open;
資料庫已更改。
SQL>  select current_scn from v$database;
CURRENT_SCN
-----------
    7232872
SQL>  select current_scn from v$database;
CURRENT_SCN
-----------
    7232878
SQL>  select current_scn from v$database;
CURRENT_SCN
-----------
    7232879
SQL>  select current_scn from v$database;
CURRENT_SCN
-----------
    7232905
SQL>  select current_scn from v$database;
CURRENT_SCN
-----------
    7232915
SQL>  select current_scn from v$database;
CURRENT_SCN
-----------
    7232917
SCN是oracle的一種時鐘機制，隨時間而增加，每個資料庫都有一個全域SCN,通過SCN oracle來維護資料庫的一致性。SCN無處不在，resetlogs scn,checkpoint scn.......
除非資料庫重建，否則永遠不會為0，上面出現0，是因為資料庫還沒開啟啦。
此時我們在sysY使用者下：
SQL> show user;
USER 為 "SYS"

SQL> create table tt(id number,scn number);
表已建立。

SQL>  insert into tt values(1,dbms_flashback.get_system_change_number);
已建立 1 行。
SQL> insert into tt values(2,dbms_flashback.get_system_change_number);
已建立 1 行。
SQL> commit;
提交完成。
SQL> select * from tt;
        ID        SCN
---------- ----------
        1    7235265
        2    7235294

通過尋找tt,可以大致估算我們插入資料時的時間。
查看v$log:
SQL> select group#,status,archived,sequence#,first_change#,next_change# from v$log;
GROUP# STATUS          ARC  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------------- --- ---------- ------------- ------------
        1 INACTIVE        YES        424      7179754      7189656
        2 INACTIVE        YES        425      7189656      7227701
        3 CURRENT          NO        426      7227701  2.8147E+14

有上述插入資料的SCN和目前日誌的FIRST_CHANGE#知，上述資料的日誌存放在當前記錄檔中，也就是序號為426。上述的FIRST_CHANGE#表示開始使用該組日誌時的scn,
next_change#表示切換該組日誌時的scn，也就是使用下一組日誌的FIRST_CHANGE#。
分析一下status：
current:表示目前使用的日誌，毫無疑問。
active:已經完成歸檔，記錄檔已經寫入磁碟，可��和該部分日誌相對應的資料區塊的修改還沒有寫入磁碟，在記憶體裡，所以該記錄檔在資料庫crash後恢複可能會用到。
inactive:此時已經完成歸檔，記錄檔和對應修改的資料庫已經寫入磁碟。
由於這三組日誌迴圈切換，產生的日誌我們怎麼標識呢，
這就是序號重要的作用了：
SQL> alter system switch logfile;
系統已更改。
SQL> select name,thread#,sequence#,first_change#,next_change# from v$archived_log WHERE sequence# = 426;
NAME                                                                                  THREAD#  SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------- ---------- ------------- ------------
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_426_bmvr5f9j_.arc                1        426      7227701      7236412
看上面的 name,sequence#，知道序列用來標識歸檔檔案的作用了吧。
THREAD#：因為此時資料庫是在單一實例下，一個資料庫對應一個執行個體：
所以此時thread#可以理解為執行個體編號。
在RAC下，此時的THREAD#對應的是節點號。
我們現在類比：
SQL> insert into tt values(3,dbms_flashback.get_system_change_number 
  2  );
已建立 1 行。
SQL> commit;
提交完成。
SQL> alter system switch logfile;
系統已更改。
SQL> insert into tt values(4,dbms_flashback.get_system_change_number 
  2  );
已建立 1 行。
SQL> COMMIT;
提交完成。
SQL> alter system switch logfile;
系統已更改。
SQL> insert into tt values(5,dbms_flashback.get_system_change_number);
已建立 1 行。
SQL> COMMIT;
提交完成。
SQL> alter system switch logfile;
系統已更改。

SQL> select * from v$log;
  GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS          FIRST_CHANGE# FIRST_TIME    NEXT_CHANGE# NEXT_TIME
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- -------------- ------------ --------------
        1          1        433  52428800        512          1 NO  CURRENT                7239074 27-4月 -15      2.8147E+14
        2          1        431  52428800        512          1 YES ACTIVE                7239029 27-4月 -15          7239057 27-4月 -15
        3          1        432  52428800        512          1 YES ACTIVE                7239057 27-4月 -15          7239074 27-4月 -15

我們此時刪除資料檔案：
[oracle@localhost ~]$ cd /u01/app/oracle/oradata/orcl3939
[oracle@localhost orcl3939]$ rm -rf *.dbf

然後把之前備份的資料檔案移到/u01/app/oracle/oradata/orcl3939，如果全部移動的話，則資料庫可以開啟了，之前對於表tt的操作資料完全丟失
[oracle@localhost beifeng]$ cp *.dbf /u01/app/oracle/oradata/orcl3939

SQL> startup mount;
ORACLE 常式已經啟動。
Total System Global Area  351522816 bytes
Fixed Size                  1336484 bytes
Variable Size            297798492 bytes
Database Buffers          46137344 bytes
Redo Buffers                6250496 bytes
資料庫裝載完畢。

此時開啟到mount狀態是完全可以的。

SQL> alter database open;
alter database open
*
第 1 行出現錯誤:
ORA-01113: 檔案 1 需要介質恢複
ORA-01110: 資料檔案 1: '/u01/app/oracle/oradata/orcl3939/system01.dbf'

此時我們恢複資料庫：
SQL> recover database;
ORA-00279: 更改 7233493 (在 04/27/2015 13:51:53 產生) 對於線程 1 是必需的 ORA-00289:
建議:
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_426_b
mvr5f9j_.arc
ORA-00280: 更改 7233493 (用於線程 1) 在序列 #426 中
指定日誌: {<RET>=suggested | filename | AUTO | CANCEL}

此時會用到歸檔日誌：/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_426_b
mvr5f9j_.arc
序號為：426,
更改時的scn：7233493
指定日誌分析：
suggest:表示用的歸檔記錄檔位置就是建議的位置
filename:表示歸檔後的日誌若你修改位置，此時你需要指定位置
auto:表示資料庫自動回復
cancle:只恢複到該步驟即停止

下面我們按斷行符號鍵選擇suggest：

ORA-00279: 更改 7236412 (在 04/27/2015 15:09:33 產生) 對於線程 1 是必需的 ORA-00289:
建議:
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_427_b
mvrj552_.arc
ORA-00280: 更改 7236412 (用於線程 1) 在序列 #427 中
指定日誌: {<RET>=suggested | filename | AUTO | CANCEL}

 

ORA-00279: 更改 7236929 (在 04/27/2015 15:15:17 產生) 對於線程 1 是必需的 ORA-00289:
建議:
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_428_b
mvrooz2_.arc
ORA-00280: 更改 7236929 (用於線程 1) 在序列 #428 中
指定日誌: {<RET>=suggested | filename | AUTO | CANCEL}

 

ORA-00279: 更改 7237015 (在 04/27/2015 15:18:13 產生) 對於線程 1 是必需的 ORA-00289:
建議:
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_429_b
mvs29ny_.arc
ORA-00280: 更改 7237015 (用於線程 1) 在序列 #429 中
指定日誌: {<RET>=suggested | filename | AUTO | CANCEL}

 

 

是不是這樣很慢，我這樣是讓大家看到每一步用到的歸檔記錄檔，那下面我們使用auto：
AUTO
ORA-00279: 更改 7237261 (在 04/27/2015 15:24:57 產生) 對於線程 1 是必需的 ORA-00289:
建議:
/u01/app/oracle/flash_recovery_area/ORCL3939/archivelog/2015_04_27/o1_mf_1_430_b
mvvf00h_.arc
ORA-00280: 更改 7237261 (用於線程 1) 在序列 #430 中
已應用的日誌。
完成介質恢複。

此時我們尋找資料檔案的scn（全部來自控制檔案，shutdown之後保留的），以及資料頭的scn（資料頭的scn是舊的，來自拷貝回來的資料檔案頭）
要想資料庫開啟，則兩者scn相等：
SQL> select file#,checkpoint_change# from v$datafile;

    FILE# CHECKPOINT_CHANGE#
---------- ------------------
        1            7259884
        2            7259884
        3            7259884
        4            7259884
        5            7259884
        6            7259884
        7            7259884
        8            7259884
        9            7259884
        10            6980281
        11            7259884
  FILE# CHECKPOINT_CHANGE#
---------- ------------------
        12            7259884
已選擇12行。

SQL> select file#,checkpoint_change# from v$datafile_header;

    FILE# CHECKPOINT_CHANGE#
---------- ------------------
        1            7259884
        2            7259884
        3            7259884
        4            7259884
        5            7259884
        6            7259884
        7            7259884
        8            7259884
        9            7259884
        10            6980281
        11            7259884

    FILE# CHECKPOINT_CHANGE#
---------- ------------------
        12            7259884

已選擇12行。

現在兩者已經對應相等了，此時可以開啟資料庫。

SQL> alter database open;

資料庫已更改。

SQL> select * from tt;

        ID        SCN
---------- ----------
        1    7235265
        2    7235294
        3    7239015
        4    7239050
        5    7239064

資料已經全部恢複回來。