關於Data Guard在我原來印象中是有陰影的，起源是在OCM考試中，有很多同學在一個小時內搭建出Data Guard環境，但是做了主備切換，反覆切換的時候出了問題。而自己在搜狐暢遊的一大收穫也算是Data Guard了，因為接觸各類的環境，碰到了太多的問題，所以就觸發了很多的感受或者不滿。
所以在某種程度上對已有的方案就有很多的改進。
其實在2017年的時候，就已經在規劃一本新書是關於災備，但是拖延症的我確實拖了太久，事情懸而未決，想起來就上火。
其實很多人都會帶著疑問說，現在Data Guard技術已經很成熟，而且文件齊全，做這件事情的意義是什麼？我的想法如下：
1.官方文件本身寫了Data Guard的很多內容，從文件來說，內容已經相當全面了，所以我的入手點絕對不是官方文件的內容。
2.在11g開始，Data Guard已經不簡單是一個備庫的角色了，它開始承載很多更有實際價值的任務，比如批次查詢任務，比如透過快照資料庫來評估DML,DDL等，所以基於這個重大的變化和方向，我覺得對Data Guard值得深入研究。
3.從實際的使用來看，Data Guard出現問題的情況很多和官方文件的系統性差別很多，或者說官方文件是實用不實用的內容都有，需要甄別，比如備庫有兩種型別，幾乎99%以上都是Physical Standby,而Logical Standby的應用場景是截然不同的。
4.問題的場景化程度不夠，解決問題比較好的入手方式就是案例，透過案例可以舉一反三，觸類旁通，搞明白一個問題，才可能搞定一類問題。比如解決問題的時候，問題現象是同一個，但是對於不同的版本，解決方案和入手點就截然不同。
5.目前對於新版本的技術解讀還比較少，如果能夠與時俱進，算是一個亮點吧。
所以這些算是我對於這個災備書籍的一個入手點和出發點。至於稿酬，如果你認真了，開始你就輸了。還有個不是理由的理由，那就是這算是自己規劃的一個方向，這個任務解決了，自己就不用那麼糾結了。
細節的內容暫時先不公開，我就列出來一部分之前整理的大綱。
比如搭建Data Guard,其實有一些基本的技巧和策略，不同的場景可以選擇使用，總之在這種情況下，你的思想就是一個百寶箱，最終的結果是解決問題，但是如果高效快速的解決問題才是王道。
如果我要寫這本書，大家從自己的理解來說，是否靠譜。
想聽聽你們的想法。