Oracle閃回技術--Flashback Version Query

Flashback Version Query和Flashback Query從技術基礎上，都是相似的，也就是藉助Oracle的Undo機制。作為一款成功的資料庫產品，Undo和Redo機制是Oracle最核心的技術。Undo記錄的是資料DML操作的前映象，經典的Oracle事務模型中，一旦事務被commit，理論上之後SCN啟動的讀操作都不能讀到之前的映象資料。

Oracle於是利用Undo的機制，提供了短時間內的資料表舊版本查詢。透過as of {timestamp | scn}指定時間點，就可以進行查詢。當然，這個舊版本時間並不是無限長度，這就涉及到undo_retention這個爭議引數。

很多朋友都不是很理解undo_retention，這個以秒為單位的引數經常讓人很抓狂。官方理解是：設定undo_retention之後，可以支援設定秒數的閃回資料查詢。但是在實際工作中，卻發現很多時候超過這個時間的資料也能檢索到，但是有的時候沒有到這個時間間隔舊版本資料，也不能找到。

其實，Undo_retention引數其實是Oracle資料庫給使用者建議的一個“理想值”。試想一下，Undo資料是一個不斷迴圈覆蓋使用的空間，舊Undo前映象一定會被新Undo前映象覆蓋。事務負載不同的系統，對Undo的使用情況也是不同的。

如果Undo_Retention保留的時間比較長，而恰恰資料庫系統是一個事務操作頻繁的系統，那麼Oracle如果想要堅持undo_retention，就必須維持一個比較大可擴充的Undo Tablespace。這時候，如果恰恰Undo Tablespace的檔案被設定為不可擴充的，那麼Oracle也就不能保證undo_retention的理想值了。

引數retention grantee是設定在undo tablespace的引數設定。如果設定了這個引數，就表示Oracle一定要保證undo_retention的理想設定值，即使不能完成事務過程。

Flashback Query和Flashback Version Query，都是依賴Undo過期資料的來構建前映象的操作。

與Flashback Query不同的是，Flashback Version Query引入了一些資料表“偽列”，可以提供對資料版本的操作和檢索。

工作心得：我師傅的師傅的師傅，流傳給我們一句話：備份--備份---備份；備份永遠最重要。但是我們很多人，工作的時間越久越膽小，主要是兩個方面的原因：首先是備份的有效性，雖然有各種備份系統負責備份工作（特別是2012年以後，國內出現了很多國產的資料備份廠商），但是備份是不是有效一直是運維工程師心中的噩夢。第二個因素是恢復時間，大部分的Media Recovery都需要停機停服務，這對於7*24小時的高可用應用是不能允許的。另一方面，在現代企業級別資料中心環境下，如果存在正當的管理流程和方法，大規模資料恢復、回退的情況是比較少見的。

相應的，小規模資料恢復，如資料表一行資料被莫名誤修改、資料表誤刪除等需要恢復的需求卻不斷增加。在傳統的恢復技術中，這樣粒度的恢復操作一般是不能支援的。

                                             申明：部分內容轉載子其他部落格。