這裡討論的並不單單是恢復上的技巧問題，還有如何對你的db管理規劃的問題。
案例情形：
某個生產環境的業務表(不大，100m左右）被誤刪除了乙個字段，現在要盡快找回這些被刪除的業務資料（資料庫容量為700多g,有乙個實時恢復的物理備庫，主要的表空間為該所在表空間bis和另外乙個表空間,各自300多g,單個資料檔案統一8g乙個).
情況很樂觀：有誤操作之前rman全備份和到現在連續的歸檔日誌，也就是說用rman的不完全恢復可以找到為刪除之前的資料。
這是乙個看似很基礎和簡單的案例，但作為db的管理維護人員，尤其是作為服務型的人員角色來說，如何縮短故障的解決時間，將直接決定你的服務質量和客戶的滿意度。
不妨讓我們思考一下，面對這個案例，有什麼樣的技巧可以縮短恢復的進度時間呢？
也許很多人都認同這個這麼乙個方法：採用基於表空間的不完全恢復。恢復system表空間、undo表空間和故障表所在的表空間，將其餘表空間全部 offline。在我們這個案例中，單故障表所在的表空間有將近300g的資料，去恢復這個大的容量，花費的時間無疑還是不容樂觀的。
有沒有更快的辦法呢？
對於這種情形，實際上我們只需要去恢復幾個檔案即可。因為表是被drop列的，誤操作前後該object的物理位置並沒有多大改變，我們可以獲得該錶所在的datafile。由於表所在的表空間datafile為8g乙個，所以，需要恢復的檔案只是system檔案,undo檔案和1(2)個8g的 datafile檔案。單從數字上你就會明白兩種恢復方法速度上的差別—乙個涉及的檔案30多g,而另外乙個足有300g多。
查詢誤操作表所在的檔案和需要恢復的系統檔案：
sql> select file_id,file_name,tablespace_name from dba_data_files where tablespace_name in (』system』,'undotbs1′) union all
select distinct a.file_id,b.file_name,b.tablespace_name from dba_extents a,dba_data_files b where a.segment_name=』tb_new_config』 and a.file_id=b.file_id;
file_id file_name tablespace_name
———- —————————— ——————————
1 /data/nl/system01.dbf system
2 /data/nl/undotbs01.dbf undotbs1
3 /data/nl/undotbs02.dbf undotbs1
14 /data/nl/bis04.dbf bis
因此接下來只需要恢復1.2.3.14這個四個檔案即可。
(1).使用rman進行檔案restore
[oracle@bisdb ~]$ rman target /
[uniread] loaded history (180 lines)
recovery manager: release 10.2.0.4.0 - production on mon jul 13 19:14:37 2009
connected to target database: bisdb (dbid=1978090465, not open)
rman> restore datafile 1,2,3,14;
starting restore at 13-jul-09
using target database control file instead of recovery catalog
allocated channel: ora_disk_1
channel ora_disk_1: sid=156 devtype=disk
channel ora_disk_1: starting datafile backupset restore
channel ora_disk_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /data/nl/system01.dbf
channel ora_disk_1: reading from backup piece /backup/full_172_1
…………………
(2).將datafile 1，2，3，14之外的全部檔案offline drop
sql>alter database datafile 4 offline drop;
…..(略)…….
sql>alter database datafile 101 offline drop;
(3).進行不完全恢復
特別需要注意這一步：該步需要使用sqlplus進行。如果你使用rman做recover，你會發現行不通。因為rman依然會對錶空間內 offline過的檔案做recover，因為我們只restore了表空間其中的乙個檔案，所以使用rman恢復該錶空間的時候被報錯,具體可自行驗證。
sql> recover database until change 129856635;
ora-00279: change 129853929 generated at 07/13/2009 17:54:52 needed for thread 1
ora-00289: suggestion : /arch/nl/1_1165_689680541.dbf
ora-00280: change 129853929 for thread 1 is in sequence #1165
specify log:
auto
ora-00279: change 129856633 generated at 07/13/2009 19:02:06 needed for thread 1
ora-00289: suggestion : /arch/nl/1_1166_689680541.dbf
ora-00280: change 129856633 for thread 1 is in sequence #1166
ora-00278: log file 『/arch/nl/1_1165_689680541.dbf』 no longer needed for this
recovery
————-
sql> recover database until change 129856635;
ora-00279: change 129856635 generated at 07/13/2009 19:02:07 needed for thread 1
ora-00289: suggestion : /arch/nl/1_1177_689680541.dbf
ora-00280: change 129856635 for thread 1 is in sequence #1177
specify log:
cancel
media recovery cancelled.
(4).alter database open resetlogs
之後，進行資料的業務邏輯處理補入。
後記：這個案例可以引起我們的一些思索：
1. 資料檔案大小規劃
比較幸運的是，這個案例中單個資料檔案比較小，這對我們縮短恢復時間提供了關鍵因素。在實際環境中，過大的資料檔案並不可取。
2.datadurd規劃
這是個有dataguard環境的主庫，可以設定備庫延遲主庫一段時間的日誌檔案應用。這樣可以在及時捕獲誤操作的情況下降低故障處理時間。在delay的時間策略上，需要我們根據業務系統要求靈活處理
記錄一次ORACLE的不完全恢復
前言 之前說過一句話，備份有時候就是用於資料庫的恢復，雖然很多時候都用不上。但是你永遠不知道什麼時候會用上，這就是備份的意義 昨天晚上10點多的時候，突然朋友打 過來，要幫忙做乙個資料庫基於時間點的恢復。具體的業務場景是這樣的 2015年2月7日12 00的時候有乙個錯誤的操作，導致使用者的資料被覆...
VM解除安裝不完全，重灌的乙個下午
玩軟體就是隨時面臨著重新來過的危險。今天一不小心就把vm給高爆了，爆的很高的那種。解除安裝不完全的vm如何在不重灌系統的情況下安裝。首先第一步，肯定是通過控制面板去解除安裝vm，但是。但是。我靠嘞，總是處於占用狀態卸不了。把vm的所有服務全部停了，本來打算去把登錄檔項也給刪了。結果刪了半個小時沒刪完...
WPF處理窗體的最小化事件及恢復正常窗體事件
wpf中沒有resize事件。那麼如何處理wpf中的窗體最小化和恢復正常窗體事件呢。經過一番查詢知道在wpf中存在statechanged事件。在xaml中新增statechanged window statechanged 使用如下 可以處理。private void window statech...