RMAN各種情況下的備份恢復
【ORACLE】RMAN各種情況下的備份恢復
小編通過三天總結出來這片RMAN各種情況恢復的文章，希望能幫助大家解決一些生產上出現的問題。
眾所周知，RMAN是ORACLE最常用的物理備份手段，也是資料庫中最重要的知識點之一，但是也最容易被人忽略，小編一向本著實驗證明真理的角度去儘力做好這個公眾號，而且RMAN的操作也是需要大量的實驗去驗證和學習，所以我們今天來模擬一下各種情況下導致的資料庫崩潰恢復情況。
這裡先介紹一下試驗環境：
單實例資料庫：192.168.1.20
實例名：orcl
歸檔：開啟
人們常說有了全被都不怕，現在先對資料庫做一次全備
我們得到了以下的備份文件
下面我們就根據不同的情況進行資料庫恢復：
1.數據文件丟失，一般是人為誤操作，或者是磁碟出現問題的常見故障導致。
情況一：應用數據文件丟失資料庫重啟
我們刪除了用戶數據文件之後發現，資料庫重啟只能開啟到mount狀態data file 5丟失。
現在即可打開資料庫。
情況二：應用數據文件丟失沒有重啟。
有時候磁碟出故障，導致數據文件丟失之後資料庫在短暫時間之內是正常運行的，insert，select，這個表空間內的表都是正常的，我們來模擬一下
我們發現依舊可以插入，可以查詢，這是因為控制文件依舊認為資料庫是正常的，而且手動觸發check point的時候還能落盤，commit操作也可以，有點不合常理，這裡的原因可能是因為資料庫這個時候的插入操作依舊插入到內存之中，沒有落到磁碟里，這是linux的緩存特性導致的，linux下有句話稱為『殺不了的oracle』，即使資料庫數據文件被刪除，但是依舊有緩存信息在內存當中，直至真正發現其文件丟失，這時alert日誌記錄依舊正常。
多次執行alter system flush buffer_cache之後我們發現報錯會被拋出，而且也無法查詢和寫入這個表了
我們在這種情況下恢復資料庫的時候只能採用強制重啟到mount的時候操作。
recover database ;
如果數據文件丟失資料庫沒有發現其數據文件丟失，我們可以將這個數據文件offline掉，之後將其恢復，不用關閉資料庫。
注意：這裡一定要offline數據文件，不能offline表空間，表空間無法offline
我們在offline 數據文件之後，我們查看數據文件狀態,已經成為recover模式，這個時候就可以根據備份恢復了
接下來我們進行恢復操作
我們去資料庫中查看數據文件狀態，已經從recover 狀態變成了offline狀態。
我們將它online，這裡可以使用datafile，也可以使用tablespace
恢復完成~~~~~~
這裡可能有人要問，那system表空間如果丟失能用這種方法嗎？我們通過實驗看一看
果然是不行的，system表空間不能直接offline，系統的動態視圖都在這裡記錄，怎麼可能offline呢。
2.oradata全部丟失
有的時候當資料庫磁碟損壞，導致所有的oradata下的文件全部丟失，這種情況下有備份在其他磁碟上的話，可以進行恢復，接下來實驗鑒定真理。
我先在test.a表裡面插入一條數據，之後再去說我的用意
刪除oradata所有文件
這個時候，資料庫有可能還能用，就是因為我之前說的，linux的緩存體系導致的，現在他的信息記錄在緩存當中，所以資料庫可能暫時還是可以使用的。但是即使能用，高興不了多久，馬上就會連登陸都難。
好，那我們來進行恢復。
首先我們先把資料庫的進程殺掉。針對linux系統來說資料庫是多進程的，我們只需要kill掉pmon或者是smon的話所有進程就都被幹掉了。
進程都沒有了，我們現在能把資料庫開到nomount狀態，因為我們的參數文件還在，參數文件是放在$ORACLE_HOME/dbs下的。或者更悲觀的spfile不見了，我們也可以先通過pfile手動寫入將其開到nomount狀態，再把spfile恢復，之後用spfile啟動，這裡不做多餘實驗，很簡單的。
現在我們是在nomount狀態下，我們知道restore database的時候必須資料庫要在mount模式才能使用，然而從nomount到mount又需要我們的controlfile，這個時候就要恢復我們的controlfile。
恢復完之後我們發現資料庫的controlfile一個恢復到了oradata，然而還有一個放在了閃回區當中，這個時候我們可以把資料庫開啟到mount狀態下，我們去看一下數據文件是否恢復回來了。
控制文件回來了，我們再往下進行restore database
注意這裡在recover的時候恢復到了第180號歸檔，這裡一定要注意，因為我們在操作資料庫的時候，沒有對當前的日誌進行歸檔操作，所以，在沒有生成歸檔的時候我們刪除了redolog，這裡控制文件當中已經記錄了181號歸檔，但是沒有生成對應的181號，所以這裡的恢復成功也會丟失掉我們插入的數據。
在這裡我們需要恢復完之後，我們開啟資料庫提示需要resetlogs，這是因為在我們在對資料庫進行恢復的時候，controlfile file丟失，我們使用備份的control file進行恢復，所以需要將資料庫開啟的時候resetlogs，日誌的序號重新從1開始，並且這個操作會生成一個新的incarnation，這裡先不說incarnation的問題，我會在文章會提到，只需要記住的是，一旦將資料庫resetlogs打開之後，就一定要為資料庫創建一次全備。
我們查看資料庫發現已經是open狀態了
我們去查一下test.a的那張表
我們發現，之前我們插入的id=5的數據丟失了，這是因為當時我們在插入test.a id=5,name=d的時候，我沒有手動生成歸檔，當時的使用的redo日誌文件沒有生成歸檔就被我刪除了，所以恢復完成後的scn號要早於我插入時的scn，所以當前的恢復丟了一部分數據，這裡一定要注意的是，已經進行了resetlogs的操作，這樣就會生成一個新的incarnation，也就是說進入了一個新的狀態，我們之後做實驗進行恢復的時候，就不能在使用之前的數據文件備份，否則只能恢復到值前的incarnation最後的一個狀態。（關於incarnation，我會在後續出文章）
3.基於時間點的資料庫恢復操作
這種恢復一般用在把資料庫恢復到某一個時間點狀態的情況下，比如說有人誤刪了一個表，有人誤刪了一個用戶的操作，這裡一定要注意，這種恢復是將整個資料庫回退到某一個時間點當中。不是恢復一張表，一個用戶。
我們先模擬一下場景：
想要恢復到一個指定scn 的話一定要將資料庫開啟到mount狀態下。生產上不要學我Startup force很危險。
比較簡單，切記，這種數據丟失的操作一定需要resetlog開啟資料庫。並且數據已經回到這個時間點了。
我還要多一句嘴，有些時候要是誤操作的時候可能沒有辦法確定誤操作前的scn是多少，所以可能需要進行日誌挖掘，這是一件特別頭疼的事情，當然ORACLE也提供了基於時間進行數據恢復的操作。
set until time="to_date("2018-04-19 15:27:00","yyyy-mm-dd hh24:mi:ss")";
這種用法在生產上用的更多一點，但是粒度可能會更大一點，也就是回滾的內容可能會更多，擇優考慮。
4.redo日誌的丟失
其實redolog丟失不需要rman的幫助，因為他在/oradata/下所以我就把它放在這裡講了，一般情況下，我們作為一個合格的dba，都會配置多個group 組去提升資料庫性能，並且為每個group下去添加多個member保證冗餘，但是這裡是極端情況下丟失redolog的情況。
其實這種恢復方法有多種，我們一一描述一下：
情況一：丟了inactive的日誌
我們去刪除資料庫對應的redo02.log
這個時候如果歸檔切了，資料庫就會甩出一個報錯，這種其實就是active狀態的logfile丟失的恢復手段。
這裡使用unarchived的原因是，current狀態的日誌丟失，沒有生對應得歸檔文件，但是關閉的方法是一致性關閉，這裡也就是強制將資料庫日誌清空。所以可能導致以後通過歸檔恢複數據的時候會數據丟失。
這樣redo02就回來了。對應的日誌狀態也就成了unused狀態了。
如果我們redolog丟的就是inactive的並且沒有切到丟失的日誌上，恢復起來就比較簡單，這裡就不需要讓它不記錄歸檔，因為inactive狀態的日誌已經被歸檔了。
情況二：丟了active的日誌
我們上面也說了一種inactive日誌丟失的情況，因為他們已經生成對應的歸檔，所以我們可以清空日誌。只需要alter database clear logfile group 2;這裡也沒啥區別。
情況三：非一致性關閉資料庫
我前面的兩個實驗多次強調的是一定要shutdown immediate一致性關閉資料庫，這是因為在一致性關閉資料庫的時候其生成了對應的歸檔文件，使用alter database clear的冰凌可以直接清空日誌並且將其打開，如果是非一致性關閉，是不能這樣操作的。
這個時候有兩種方法可以解決這種問題：
第一種，採用欺騙的手段：假裝做一次回復操作，實則沒有回復，進行非一致性恢復操作。
這裡找不到對應的3號，歸檔因為在非一致性關閉的時候沒有生成歸檔日誌，所以會丟失。看一下最新生成的歸檔是2號歸檔
恢復完之後雖然有報錯，但是我們不要管他，直接alter database open resetlogs; 打開，如果可以，那麼就證明恢復成功，如果不行，那麼就需要進行隱藏參數的方法。下圖就是不能恢復的情況陷入了一個死循環，一般是在非貴黨模式下導致的。
第二種，隱藏參數「_allow_resetlogs_corruption"":
這種方法是一種特殊方法，通過在參數文件當中配置隱藏參數，在資料庫開啟的時候跳過一致性檢驗，可以強制將資料庫拉起來，同時，在開啟該參數之後開啟資料庫，也一定要把這個參數關掉，否則會經常報出ora-00600的各種報錯，十分頭疼。
將資料庫重啟到mount狀態，並且將其resetlog打開：
註：如果資料庫開啟了閃回，那麼是不允許其使用backup controlfile 恢復
THAT"S ALL
BY CUI PEACE!!!
TAG:最帥dba工作筆記 |