OracleAcs資深顧問羅敏老羅技術核心感悟：失去了一次露臉機會

來源：懂視網責編：小采時間：2020-11-09 13:00:36

OracleAcs資深顧問羅敏老羅技術核心感悟：失去了一次露臉機會

OracleAcs資深顧問羅敏老羅技術核心感悟：失去了一次露臉機會:作者為: SHOUG成員 – ORACLE ACS高級顧問羅敏某日與Oracle同事一同在某移動公司進行技術交流，涵蓋12c、云技術、數據庫整合、容災、OEM等多個專題領域。臨近中午時分，一直噴到了Oracle最適合于人工錯誤恢復的FLASHBACK技術。正在唾沫四濺之際，突

推薦度：

點擊下載本文 文檔為doc格式

導讀OracleAcs資深顧問羅敏老羅技術核心感悟：失去了一次露臉機會:作者為: SHOUG成員 – ORACLE ACS高級顧問羅敏某日與Oracle同事一同在某移動公司進行技術交流，涵蓋12c、云技術、數據庫整合、容災、OEM等多個專題領域。臨近中午時分，一直噴到了Oracle最適合于人工錯誤恢復的FLASHBACK技術。正在唾沫四濺之際，突

作者為:? SHOUG成員 – ORACLE ACS高級顧問羅敏某日與Oracle同事一同在某移動公司進行技術交流，涵蓋12c、云技術、數據庫整合、容災、OEM等多個專題領域。臨近中午時分，一直噴到了Oracle最適合于人工錯誤恢復的FLASHBACK技術。正在唾沫四濺之際，突然接到

作者為:?

SHOUG成員 – ORACLE ACS高級顧問羅敏

某日與Oracle同事一同在某移動公司進行技術交流，涵蓋12c、云技術、數據庫整合、容災、OEM等多個專題領域。臨近中午時分，一直噴到了Oracle最適合于人工錯誤恢復的FLASHBACK技術。正在唾沫四濺之際，突然接到客戶DBA電話：“羅工，能不能暫停一下技術交流，我們正好有三張表剛被人意外刪除了，能不能過來幫忙用你剛剛介紹的FLASHBACK技術把這三張表搶救回來？”

世界上怎么還有這么巧合的事情？已經由不得我有半分遲疑，特別是任何私心雜念了。諸如：“羅工，這不正好讓你展現Oracle技術特點，給你次露臉機會了。”。“羅工，你不挺能吹的嗎？看你能不能展示真才實學了”… …。于是，我端起筆記本電腦，直奔現場，一邊下樓，一邊趕緊看FLASHBACK相關資料。俗話說：臨陣磨，不快也光。呵呵。

銷售同事也看出了情形的緊迫和老羅的“窘”態，想盡一切可能在幫忙：幫我拆筆記本電源線，幫我提著礦泉水，更恨不得攙扶著正閱讀文檔，步履有點蹣跚的老羅同志一同下樓，哈哈！

待我趕到機器旁邊時，資料也已經看完了，心中也有底了。于是，在簡單詢問了問題現象之后，趕腳讓第三方公司DBA輸入如下命令：

SELECT original_name, object_name,

type, ts_name, droptime, related, space

FROM user_recyclebin

WHERE can_undrop = ‘YES';

咦，怎么是空？再在sys用戶下輸入：

Select * from dba_recyclebin;

還是空！怎么回事？難道刪除這三張表的客戶不是意外操作，而是誠心搞破壞，用了“drop table … purge”命令，或者清空了回收站（Recycle Bin），從而徹底刪除了這三張表？與客戶進一步確認：這三張表的確是誤刪除的，沒有使用上述命令。

既然如此，為什么回收站沒有這三表表的數據呢？稍一思忖，想起來了！Oracle還有個初始化參數（RECYCLEBIN），可控制是否使用FLASHBACK DROP。一檢查，果然如此！原來DBA把RECYCLEBIN設置成OFF，從而關閉了FLASHBACK DROP功能。唉！遺憾啊，老羅同志失去了一次露臉的機會，Oracle更失去一次展現技術特點的機會！

本來可以通過“flashback table to before drop”一條簡單命令，在數秒鐘之內就能恢復被誤刪除表，結果害得客戶從生產系統去重新抓取數據，同時恢復被刪除的索引、Constraint等數據，整整折騰了一個多小時。客戶慶幸的是：幸虧生產系統還有數據，否則叫天不應，喊地不靈。

待一切恢復正常了，我還是詢問DBA了：“為什么要關閉FLASHBACK DROP功能呢？”回答是：“你們Oracle Flashback太消耗資源了，影響性能，我們不敢打開。”

哦，原來如此。這也是本文的主題：從技術上言，Flashback不是單一技術，而是一個技術家簇。以下就是各種Flashback技術的綜合對比：

Flashback技術	主要目的	級別	配置方式	技術原理	恢復期限	適應場景
Flashback Database	快速恢復數據庫	數據庫級	基于存儲在Flashback Recovery Area中的 Flashback log	取決于Flashback Recovery Area容量和db_flashback_retention_target參數	大規模數據誤操作應用測試與Data Guard綜合使用
Flashback Table	整表恢復到指定時間	表級	缺省	基于Undo技術	取決于UNDO表空間大小，UNDO_retention參數	各種DML錯誤的表級恢復
Flashback Query/ DBMS_FLASHBACK包	查詢過去時間點的記錄	記錄級	缺省	基于Undo技術	取決于UNDO表空間大小，UNDO_retention參數	恢復錯誤記錄對歷史記錄進行分析、統計
Flashback Drop	快速恢復Drop Table操作	表級	缺省	Recyclebin(該表所在的表空間)	自動管理（FIFO算法）。由表空間的空閑空間確定	錯誤Drop 表操作
Flashback Versions Query	訪問事務歷史情況	記錄級	缺省	基于Undo技術	取決于UNDO表空間大小，UNDO_retention參數	訪問事務歷史情況安全審計
Flashback Transaction Query	查詢UNDO語句	記錄級	缺省	基于Undo技術	取決于UNDO表空間大小，UNDO_retention參數	查詢事務詳細情況查詢UNDO_SQL語句
11g Total-Recall(Flashback Data Archive)	歷史數據存儲和利用	表級	需要配置	基于FDA區域	取決于FDA區域表空間大小	歷史數據長久存儲對歷史數據的分析、統計安全審計

各位看見了嗎？上述表格中每種Flashback技術原理、目的、是否是缺省配置、適應場景等都是不一樣的。沒錯，某些Flashback技術，特別是Flashback Database是需要進行專門配置的，例如創建Flashback Recovery Area，還會產生大量Flashback log，也的確對性能有一定影響的。但是，很多Flashback技術一方面是缺省配置的，另一方面是基于Undo技術的，并不額外產生資源開銷的，對性能的影響也非常有限。例如Flashback Drop技術僅僅在刪除表時才會有一定操作，難道我們的系統成天都有Drop Table操作？大家沒事天天刪表玩兒？不可能吧，呵呵。

唉，這就是國內IT行業的常態之一：不分青紅皂白；技術運用簡單化；動輒一刀切；缺乏對相關技術的深入研究；什么新特性都不敢用；想當然地自己嚇自己……

我們時候才能真正做到嚴謹、科學、務實、專業、積極、進取，充分評估、大膽運用各種IT新技術、新特性啊？

唉…………………