記錄一次ORACLE的不完全恢復

前言：之前說過一句話，備份有時候就是用於資料庫的恢復，雖然很多時候都用不上。但是你永遠不知道什麼時候會用上，這就是備份的意義；

昨天晚上10點多的時候，突然朋友打電話過來，要幫忙做一個資料庫基於時間點的恢復。

 

具體的業務場景是這樣的：2015年2月7日12：00的時候有一個錯誤的操作，導致使用者的資料被覆蓋。但是由於各種原因，到21：00的時候才發現；現在需要恢復一個資料庫到2015年2月7日的12：00：00；

 

整理了一下思路，就開始馬上幹活，不到一個小時整個資料庫就恢復完成了。

 

因為時間過去了9個小時，所以業務肯定已經做了很多操作，所以不能恢復到目前的資料庫上面，而要恢復到另外一臺資料庫上面（不管什麼時候，都不建議直接覆蓋恢復到目前的生產庫上面）：

一、思考需要的資源

1.1 資料庫的全備；

1.2 歸檔日誌的備份；

1.3 另外一臺用於恢復的機器（同樣的作業系統、同一個版本的資料庫、足夠的空間）

 

二、當前可以提供的資源

2.1 該資料庫每天5：00有做一個資料庫全備；

2.2 目前有個測試系統用於開發的測試使用，符合作業系統、資料庫版本、空間的要求；

2.3 由於要恢復到12：00，所以需要進行資料庫歸檔日誌的備份；

 

三、實際的操作如下：

3.1 手工進行歸檔日誌和控制檔案的備份

指令碼：

run{                   allocate channel ch1 device type disk; allocate channel ch2 device type disk; backup FILESPERSET 1 format '/backup/arch_%d_%t_%s_%p_%T' archivelog all delete all input; delete expired archivelog all; BACKUP format '/backup/CRONTROL_%s_%p_%T'  current controlfile; release channel ch1; release channel ch2; }

 

3.2 傳送引數檔案、備份檔案到測試

scp initorcl.ora  oracle@192.168.0.10:/u01/app/oracle/product/OraDb11g_home1/dbs/  （引數檔案測試機，最好是pfile檔案）

scp *20150207   oracle@192.168.0.10:/backup/   （資料庫全備和歸檔日誌的備份到測試機的/backup這個資料夾）

 

3.3 按照pfile的內容建立相應的資料夾

mkdir -p /u01/app/oracle/admin/orcl/adump
mkdir -p /u01/app/oracle/oradata/orcl
mkdir -p /u01/app/oracle/fast_recovery_area/orcl

 

3.4 啟動資料庫到nomount狀態

a、設定系統的環境變數，指令碼： export ORACLE_SID=orcl

b、啟動資料庫到nomount狀態，指令碼：sqlplus > startup nomount;

 

3.5 進行控制檔案的恢復，（需要指定最後備份的那個控制檔案）

run

{

allocate channel ch1 device type disk;

restore controlfile from '/backup/orcl_CONTROL_21879_1_20150207';

release channel ch1;

}

 

3.6 啟動到mount狀態，進行資料庫的restore;

run

{

allocate channel ch1 device type disk;

allocate channel ch2 device type disk;

alter database mount;

restore database from tag=TAG20150207T040022;

release channel ch1;

release channel ch2;

}

 

3.7 進行資料庫基於時間點的recover;

run{

allocate channel ch1 device type disk;

allocate channel ch2 device type disk;

set until time "to_date('2015-02-07 12:00:01','yyyy-mm-dd hh24:mi:ss')";

recover database;

release channel ch1;

release channel ch2;

}

 

3.8 以read only的方式開啟資料庫

SQL> alter database open read only;

說明：一般進行不完全恢復的時候都是以resetlogs的方式開啟資料庫的，但是我們這裡以read only的方式開啟，是基於如下考慮的：雖然業務已經提供了要恢復的時間點，但是為了以防萬一這個時間點有問題，我們以read only方式開啟的時候，萬一時間點不對，還可以繼續往後進行recover，而且這個資料庫也是用來查詢的，不會進行資料操作；

 

3.9 在正式庫上面建立一個dblink指向還原的這個資料庫，這樣便於業務人員可以直接在正式庫上面進行有問題表的資料的比對；

 

總結：

1、以上就是整個恢復的過程，看似很簡單，但是也許你並不知道，我每個月都有在做模擬的資料庫的恢復，並記錄各種場景使用的指令碼，臺上一分鐘，臺下很多功；

2、需要跟業務溝通清楚需要恢復的場景，避免做無用功，在做災難恢復時的場景跟救火的場景很相似的，時間寶貴；

3、一般情景下是不建議任何人員直接連線資料庫進行修改，因為太多的這種操作都是直接誤運算元據庫導致的；

4、還是強調一下資料庫備份的重要性，備份總是要有的，萬一哪天用到了；

 

........................................................................................................................................................................
本文作者：JOHN，某上市公司DBA，業餘時間專注於資料庫的技術管理，從管理的角度去運用技術。

ORACLE技術部落格：ORACLE 獵人筆記               資料庫技術群：367875324 （請備註ORACLE管理 ）  

........................................................................................................................................................................