閃回資料庫這個特性在很多oracle dba眼裡就是雞肋特性，因為誰會因為恢復資料而需要在主庫閃回，最後可能丟掉更多的資料，這個觀點沒錯。
但是如果是備庫呢，這個特性就順利成章的滿足了絕大多數的恢復需求，無論你是truncate，還是一些drop table的操作都是可以輕而易舉的恢復。所以更多的時候我們其實更偏愛於data guard基礎上的這種資料恢復方式，而原本的邏輯備份exp,expdp，物理備份rman就顯得有些臃腫了。
拿乙個真實的小案例來說明，有一次因為資料查詢的sql有問題，結果查出的資料結果有問題，但是發現的時候這個時間已經過去了好幾天，要追溯到那天那個時間點的資料狀態，使用備份是完全不可能的。這個時候因為備庫開啟了閃回，我們可以很輕鬆的恢復到幾天前的任意乙個時間點，就這樣這個問題就引刃而解了。這也算是閃回資料庫嘗到了一些甜頭。所以在後來這個特性我也會逐步放開手腳去使用。
但是對於閃回資料庫，很多場景雖然恢復起來全然沒有問題，但是它可能不是罪完美的，如果讓你說出個一二三，可能也會不是很肯定。
其實閃回資料庫不是資料恢復的「萬金油」，有一些場景它是無法實現閃回的。我們要清楚的這個這個邊界才能在資料恢復的時候更加充滿信心。這個資訊還是從官方文件中能夠得到要合適一些。（
大體來說，有下面的幾個場景是無法實現閃回的。
1.通過閃回資料庫來修復介質問題或者是資料檔案丟失
2.如果對資料檔案做了收縮操作，比如資料檔案為200m,我們收縮為190m,那麼這個我們是無法閃回到收縮前的狀態的。
3.如果drop datafile這樣的操作，本身也是無法支援閃回的，而且在10g的子版本中，這個操作直接會導致mrp異常終止。
4.一些特殊的nologging操作是不支援閃回的，比如做乙個direct path的資料匯入，比如持續時間是9:00~9:15，啟用了nologging,如果你要閃回到9:07的這個狀態是不可以的。
總體來看上面的幾個場景，也算是極為罕見了。而且放開所有的許可權，開發同學是全然沒有這些許可權去破壞和操作的。
我們來簡單做乙個例子來強化理解一下。
那麼我們在備庫端取消日誌應用，準備開始閃回。
sql> recover managed standby database cancel;
media recovery complete.
sql> alter database close;
database altered.開始閃回資料庫到收縮前的狀態。
明確了這些問題，其實閃回資料庫還是大有可為。
eTOM並非萬金油
支撐系統不僅支撐操作層 通訊產業報 您認為在運營支撐系統建設中需要注意哪些問題？王衛鄉 作為乙個企業來講，從管理的角度可以分為三層。最上面是決策層，中間是管理層，最下面是操作層。整個結構基本上是乙個金字塔形的。最下面的操作層最大，最上面的決策層最小。現在的運營支撐系統最早是從電信網路的執行維護管理系...
開源CFD並非萬金油
今天有在群裡討論開發cfd軟體的事情，眾說紛紜，有提到 沒有必要開發cfd軟體了，直接使用開源openfoam就行 但個人認為這說法還是有一些需要商榷的地方，開源軟體也不是萬金油。以下部分內容翻譯自 caewatch，有修改。當人們在談論開源cfd解決方案時，經常會聽到下面的這兩種描述 開源cfd並...
zabbix 萬金油 新浪部落格
zabbix 可以監控指令碼 zabbix 自定義監控專案 root web1 wc l etc passwd 41 etc passwd root web1 cat etc passwd wc l 41 root web1 sed n etc passwd 41 root web1 awk end...