保持資料一致性和完整性，是每一款成功商業資料庫
軟體都必須要做到的基本要求。從故障中恢復
，保證acid原則，保證事務完整性，一直是oracle資料庫核心功能組成部分。本篇主要介紹oracle例項意外終止（斷電或者強制關閉）之後，重新啟動時發生的恢復過程，也可以稱作「前滾
和回滾」。
基礎知識說明
為了更明確的說明問題，筆者首先介紹一下本文涉及到的一些重要知識。
資料庫例項失敗
我們經常說的資料庫伺服器
failure是有多層含義的。oracle資料庫是乙個由多程序元件共同構成的結構體系。最重要的部分包括***、oracle資料庫例項兩個部分，當然還包括各類檔案，更廣義的還有硬體和作業系統os。不同部分的failure現象和處理方法都有所不同。本文所闡述的過程是oracle例項失敗後的自動恢復過程。
在例項失敗的時候，往往是突然性的終止。此時oracle資料庫可能在進行一系列完成或者未完成的事務。例項失敗恢復，就是要將這些狀態進行還原，恢復到資料完整性的狀態。
寫日誌（redo log）在先機制
oracle資料庫是採用「日誌在先」機制的。當我們對資料庫資料進行修改時，並不是立即將修改寫入到檔案中，而是寫入到共享記憶體sga空間中的buffer cache裡。同時，將修改的日誌不斷的寫入到sga中另一塊log buffer快取中。有乙個後台程序lgwn不斷的將log buffer快取中的日誌內容寫入到online redo log檔案中。
寫入log buffer快取和lgwn寫入檔案的過程是非同步進行的。觸發lgwn工作的時點有幾個：
ü 使用者進行直接的commit操作；
ü 日誌進行切換；
ü 距離上次lgwn寫入操作超過三秒；
ü redo buffer資料超過1/3或者超過1m大小；
ü dbwn啟動，將buffer cache中的髒資料寫入到檔案中；
而資料檔案寫入程序dbwn工作的觸發點，則比較平緩和低頻率。
ü 當buffer cache中缺少用於寫入資料的clean block的時候，dbwn會開始將一些髒塊「dirty block」寫入到檔案中，清理出一些可以使用的clean block；
ü 週期性的checkpoint寫入，當ckpt程序進行檢查點打入的時候，dbwn會啟動進行寫入；
綜合dbwn和lgwn工作的特點，我們可以得到日誌檔案的幾個特點：
首先，日誌檔案的寫入是很頻繁的。lgwn會不斷將日誌資訊從log buffer中寫入online redo log；
其次，在日誌檔案上，可以有三個型別的事務事件。
1、事務結束，已經被commit，之後打過checkpoint檢查點。這種事務記錄在log file上，但是變化資訊已經被dbwn寫入進資料檔案；
2、事務結束，已經被commit，之後沒有打入checkpint檢查點。這種情況下，log file已經寫入了日誌專案，資料檔案可能包括髒資料，也可能沒有寫入髒資料；
3、事務未結束，沒有commit。這種時候，資料塊dirty block上面是有事務槽資訊，表示未結束事務，是不會將資料寫入到資料檔案中。但是，日誌log buffer可能將部分未提交的dml操作專案寫入到log file中；
檢查點checkpoint
檢查點checkpoint是資料庫一致性檢查的乙個標記。簡單的說，就是在這個點上，oracle保證各個檔案（資料、控制、日誌等）是一致的。檢查點的作用就是在進行例項恢復的時候，告訴smon程序，這個點之前的內容不需要進行恢復。
前滾和回滾介紹
「前滾和回滾」是oracle資料庫例項發生意外崩潰，重新啟動的時候，由smon進行的自動恢復過程。下面通過模擬例項和講解介紹這個過程。
失敗前場景說明
日誌中記錄過程如下：
1、事務a進行之後，結束commit。之後系統進行了一次checkpoint a；
2、checkpoint之後，進行事務b，結束commit；
3、進行事務c，c事務量較大，其中進行了一定量的redo log檔案寫入。之後系統斷電；
1、系統啟動過程，進入例項恢復階段
當例項意外中斷的時候，各型別檔案，包括控制檔案、資料檔案和日誌檔案上，會存在不一致的問題。這種不一致主要體現在scn值的差異上。
例項在啟動的時候，經過三階段（nomount、mount和open）。在open之前，會進行這種不一致現象的檢查，如果出現不一致，要啟動smon程序的恢復流程。
smon是oracle例項的乙個後台程序，主要負責進行系統監控恢復。進行恢復的依據主要是redo log記錄。
2、前滾程序
smon首先找到最後scn記錄的redo log file。尋找最後乙個打入的checkpoint。
順序找到checkpoint a之後，表示a之前的所有事務都是完全寫入到資料檔案中，不存在不一致性問題。恢復過程從checkpoint a開始，oracle開始依據重做日誌redo log的系列條目，進行推進。
這樣，事務b全部實現，最終將通過dbwn完全寫入到資料檔案中。所以，例項失敗之前提交commit的事務b，完全恢復。
進入事務c的範疇，由於一部分事務c的redo log條目已經進入redo log file中，所以在進行前滾的時候，一定會replay到這部分的內容。不過，這部分內容中不可能出現commit的標記。所以，前滾的結果一定是遇到例項突然中斷的那個時點。此時replay的結果是，事務c沒有提交。這樣結束了前滾過程，進入回滾階段。
3、回滾過程
對事務c，要進行回滾過程，釋放所有相關資源。從undo空間中尋找到舊版本scn的資料塊資訊，來進行sga中buffer cache資料塊恢復。
4、說說恢復過程的損耗
很多時候，由於我們事務規模較大，當出現例項崩潰的時候，重啟所需要的時間很多。有一種經驗說法是，事務有多長，前滾和回滾所消耗的時間有多長×2。而且，如果不能完成smon恢復過程，資料庫是不能算作正常的open的。
smon的恢復過程是oracle強制進行的乙個過程，即使恢復中發生斷電或者其他中斷失敗事件。oracle在下一次啟動的時候，還是會繼續這個過程，只有耐心等待。
通過檢查一些內部檢視（x$檢視），可以觀察到恢復程序和速度，但是絲毫不能影響到最終恢復的過程。
這個過程雖然可以保證資料一致性，但是也帶來了系統不能啟動，影響生產環境的問題。我們可以通過兩個方式進行緩解：
首先，我們在設計開發系統時，要保證事務規模的可控性，不要讓事務規模在技術
層面上過大。避免一旦發生崩潰，大規模強制回滾的發生；
其次，一旦出現了這個強制回滾，要注意對生產環境的影響。可以採用備庫standby進行頂替，讓主庫安靜的慢慢恢復；
oracle 資料恢復 回滾資料
1.查詢你執行update 語句之前的資料 精確到什麼時間 select from 表名 as of timestamp to timestamp 2017 07 21 17 16 38 yyyy mm dd hh24 mi ss 2.開啟可移動資料命令，執行完就可以回滾資料 alter table...
mysql恢復和回滾資料
資料庫不小心刪除或者表不小心刪除，通過mysql恢復的話需要確保刪除前是mysql是開啟binlog。具體步驟 1.查詢binlog狀態以及位置。在 etc my.cfg檢視binlog開啟狀態 可以看到binlog開始狀態是開啟的。2.mysql查詢執行的binlog檔案。目標檔案是mysql b...
資料回滾例項
資料回滾 public class databasetransaction catch exception e catch sqlexception se public void viewtable rst.close catch exception e public static void mai...