你的備庫做好準備了嗎

這篇文章計劃了一段時間，本來想寫篇心情文字，還是留到週末再放飛心情吧。
今天的內容是關於資料庫的備庫的思考，當然我們可以自己問自己，我們的備庫準備工作做好了嗎？捫心自問，其實有些工作我也沒有準備好，這是我的建議，其實一個備庫的思考點還是有很多值得考量和斟酌的地方。自己也需要後續完善

備庫總是在容災中有著舉足輕重的作用，但是故障難免，我們的備機備庫是否能夠在危機降臨的時候頂住壓力，這個需要打上一個問號，我會從硬體配置，系統層面，資料庫層面，架構層面和網路層面進行一些分析。
硬體配置
    備庫硬體配置更差
這種情況比較普遍，很多時候備庫的機器配置要比主庫差很遠，在沒有問題的情況下，也是節省了資源，但是一旦問題發生的時候，就不單單是系統，資料問題了，效能問題也會迎面而來。對於高可用的業務來說，這個影響就會放大。

系統的版本不同，有時候會看到這樣的系統版本搭配，redhat 6和redhat 4搭配，redhat 5和redhat 6搭配等等，這些也都算是遺留下來的。

    核心引數設定

這一點還是很容易被輕視的，備庫的核心引數沒有調優，當然對於資料同步是沒有任何問題的，但是一旦切換，可能很多沒有暴露出來的問題都會放大。

網路層面
網路心跳，網路頻寬
    對於網路來說，其實也很重要，如果一個redo 檔案好幾個G，網路環境太差，老是可能丟包，那麼對於備庫的日誌接收就會非常被動，而且可能出問題。
比如出現了問題，需要切換了，結果最新的一個歸檔還沒有傳過去，那麼這種情況下就沒法保證主備切換的時間了。

資料庫層面
備庫是資料庫層面的實現，但是資料庫層面還是問題不少。
    主備的資料庫軟體存在差別
主備庫的資料庫軟體，安裝選項可能不同，這個情況下對於備庫來說還是不夠規範的，目前雖然沒有發現存在什麼問題，但是本身這類問題就很少見。發現了之後還是趁早矯正。
    引數不同 compatible
資料庫層面主備庫可以不一致，但是這種不一致就是潛在的風險和問題，怎麼在後續做好相容和特殊處理。

主庫中的db link在有些業務中還是需要的，而且也確實有一定的存在意義，但是如果在tnsnames.ora，防火牆層面引起關注，最終的問題就會表現為db link的問題。
    sga等引數設定問題    
主備庫的sga的設定不同，在一定程度上也取決於記憶體或者核心引數的限制，最終反映到資料庫層面就是一些記憶體引數大大不同。

11g的備庫在mount階段

架構層面

在架構層面其實也有很多考量的地方，或者設計上有一些潛在的問題。
    同一臺機器上有dg還有邏輯備份

如果一個備庫，同時有dg，同時每天還要做一次邏輯備份，其實對於這個備庫而言，工作量還是蠻大的，尤其消耗比較大的就是邏輯備份。

    一臺機器上有多個備庫
如果一臺機器上有多個備庫，有兩種場景比較讓人糾結，一種是主庫掛掉，切換過去，結果有一主和另一個業務的備庫在同一臺機器上，就會非常糾結。
另一種情況就是如果備機出現問題，那麼搭建備庫就需要搭建好幾個備庫。

    dg broker可以作為參考，不能完全依賴dg broker
dg broker是個好工具，但是很多時候發現越依賴它，發現有時候它其實沒那麼給力，有些場景下還是不能很好的校驗，尤其是10g的dg broker。
而且如果存在主庫的歸檔被刪除的情況，那麼備庫中RFS接受歸檔然後過期刪除，dg broker是校驗不出來的，它只會認為存在gap，但是檢查點都是正常的。
    備庫不是簡單的接受應用歸檔

這一點非常重要，如果在早起的版本中，沒有了adg,其實備庫的作用就非常有限，有了adg這種情況就需要改善了。從開始設計的時候就可以為備庫考慮更多的業務角色，比如報表查詢，比如批次查詢等等。
應用層面
    cpu負荷更高
應用層面理解其實也很容易，11g的adg其實已經有了更多的責任，如果在備庫中存在著大量的問題sql,導致了備庫的cpu負載極高，那麼這種情況下，只能是備庫承載了一些額外的不必要的壓力而已，這些部分還是需要改善，要不就很可能出現備庫總是比主庫還忙，備庫更容易出現問題的情況。

大大小小列了這麼多，也歡迎大家提出意見。