冷備下模擬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 中
指定日志: {
=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 中
指定日志: {=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 中
指定日志: {=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 中
指定日志: {=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
數據已經全部恢復回來。
