今天琢磨一個問題，在平時的工作中如果碰到一些不規范的操作，drop,truncate,delete，恢復起來還是很困難的，drop操作在Oracle中如果開啟了recycle bin還是基本安全的，delete操作可以借助flashback delete操作，可能有些更細微的操作update，insert等等操作導致了問題，需要做數據修復的時候，這個時候可以使用flashback query來輔助，如果來一個truncate，那就沒轍了，其實在truncate操作完成後，一般來說數據還都是在數據文件裡的，這個時候可以借助第三方的數據恢復工具來嘗試恢復，這個時候數據恢復就不是毫秒級了，容忍度在分鐘甚至小時都是沒有辦法的事情。
不過在Oracle中，如果你之前開啟了閃回數據庫功能，那truncate的數據就能找回來了。但是話說過來，整個系統都讓重啟給弄停了，這個影響可能更大。如果不使用flashback database，直接通過dataguard來做時間點恢復或者其它的標准恢復到數據刪除之前，也是一種方法。
所以說在Oracle中對於數據的恢復方法很多，使用場景也可以根據需要來選擇。
在MySQL中數據恢復可供選擇的方案相對就比較少了。不過有一個亮點就是MySQL中的redo日志是可讀的，mysqlbinlog可以很輕松地解析出來裡面的內容。不過truncate,drop,一些DML失誤操作場景來說，對於MySQL來說就比較困難了。
一旦發生了問題，做數據的恢復就只能借助於最近的備份了，需要相應的備份，然後在最近的備份基礎上通過解析相關的binlog，直到把數據變更時間點的數據恢復。
這個過程總體來說還是需要不少的時間的，首先就是判斷備份和binlog的時間點，可以在其它測試環境中完成，需要花費的時間應該不短。
我想了下面這個方案，把Oracle和mysql結合起來，充分利用Oracle的強大的閃回功能，可能這種方案對於很多數據恢復都有不少的亮點。
還沒有在本地測試，因為也需要一些額外的定制和數據類型映射，所以只是一個大概的思路。
首先還是保持MySQL原有的架構，一個主庫，兩個備庫。因為主庫中的binlog是做數據同步的關鍵，所以可以考慮設置一個路徑做sql解析，sql解析還是使用binlog，然後再做適當的變更。這個過程可以是一個異步的過程，然後和Oracle結合起來部署到Oracle中的schema中。
MySQL中的數據量相對來說還不是很大，所以可以考慮多個MySQL database和一個Oracle中的多個schema映射起來，數據類型可以適當做一些類型映射，比如，MySQL中的big int,small int等和Oracle中的number直接映射。varchar和varchar2映射等等。
數據到位之後，就可以考慮通過各種閃回特性來做數據的恢復了。發生了truncate之類的操作可以使用flashback database來恢復，drop操作可以通過recycle bin,flashback database或者基於時間點等來恢復。delete可以通過閃回刪除，閃回查詢等來恢復。update可以通過閃回查詢來恢復等等。得到了相應的技術局之後，可以直接導出csv文件，或者insert語句來。在MySQL中通過mysqlimport或者insert來完成數據的部署。
這個過程中可以使得MySQL端始終保持前行，可以打一個比方，比如一個部隊在行軍，結果突然某個軍官發現自己的地圖沒帶，落下半路上了，這個時候可以派一個士兵騎馬去取地圖。這個時候Oracle就是那個士兵，能夠完成這個艱巨的任務，部隊依舊行進，不會產生其他影響。
