關於switchover的流程和補充

對於Oracle Data Guard中的Switchover一般是計劃內的操作，自己其實也處理了不少的故障，也算是輕門熟路。複雜的事情簡單做，簡單的事情重複做，重複的事情用心做，想必很多事情都是這個理吧。
發現很多事情雖然做了很多遍，但是每次都會有不同的體會，而這些積累下來的經驗才讓我們的經驗更加寶貴。
一般來說Oracle的Switchover需要考慮的細節較多，大體有以下的流程。

1.在遷移之前明確目標伺服器IP，發出維護公告 
這個無需多說，本身就是跨部門，多部門的協調工作，說簡單簡單，說複雜複雜，技術層面的事情就是需要提供給各業務部門相關聯的伺服器資訊，讓他們提前準備。
2.設定zabbix的維護視窗 
為了避免很多批次緊急的報警，我們需要一個明確的維護視窗，把主備庫環境都納入維護視窗，這樣會避免很多不必要的報警簡訊和報警解釋。
3.DG Broker的驗證
在切換前，需要保證DG Broker一定是正常的狀態，我們可以有一下幾種驗證方式。
    把備庫置於read-only狀態，如果是11gADG，需要檢視select open_mode from v$database一定需要時READ ONLY WITH APPLY,如果是10g版本，這個步驟尤其重要，如果切換之後，因為各種奇葩的原因，備庫無法正常使用就歇菜了，備庫的臨時表空間，日誌等問題需要提前檢查好，因為這些對於備庫來說都不會直接影響主從一致性，但是備庫變主庫就尤其重要。
    檢視主備庫的延遲情況，這個在11g中可以透過show database verbose xxx的方式看出備庫的延遲情況，而對於10g來說，這些屬性還沒有，我們可以檢視主備庫的SCN情況，甚至在主庫做一個日誌切換，在備庫檢視應用的情況。
4.停止資料庫,釋放連線
為了儘可能在維護的可控範圍內，保證很多活躍會話的事務一致性，最好還是能夠在switchover前重啟一下資料庫，釋放資料庫連線，當然很多應用有重連機制，我們可以停掉其它的監聽埠，設定一個獨立的埠留給Data Guard，當然這也是一把雙刃劍，如果埠剛好被很多應用所用，你是沒法完全控制的，可能處理不當，DG Broker都不能正常使用了，因小失大。
5.Switchover
切換是這個過程的核心，我們可以使用DG Broker來完成，這個過程本身就沒有太多的技術亮點，但是最大的坎就是心靈壓力了，我碰到過在Solaris下Failover網路連線超時的切換，切換時間極長，後臺沒有任何日誌輸出，這個過程只有經歷了才會更懂，有些切換的時候可能檢查沒有做徹底，或多或少會碰到一些問題，這個時候我的建議是準備好兩套方案，如果一旦DG Broker切換中出現任何問題，我們可以完全手工來接管。畢竟切換的過程就是轉換資料庫角色，一定要沉著冷靜，當然沉著冷靜這個是在不斷的經歷中鍛煉出來的。
6.同步listener.ora,tnsnames.ora，/etc/hosts
主備庫切換需要同步監聽，tns,主機的資訊，這些資訊比較瑣碎，可以提前準備好一個臨時檔案，到時候直接替換即可，特別注意需要保證主備庫的監聽埠是一致的。
7.防火牆同步
防火牆資訊需要提前準備，需要提前告知相應的部門。我們在切換前就可以提前安排，把防火牆資訊同步過來，需要注意網路卡的名稱是否一致，是否主備庫有特殊的設定策略。
8.修改客戶端的連線IP
有些伺服器會透過服務端TNS來連線要切換的資料庫，我們可以從防火牆中得到一個概要資訊，哪些DB伺服器中的tnsnames.ora裡面包含了目標資料庫，修改tnsnames.ora中的IP即可。
9.修改Database Link中的IP對應防火牆許可權
比如目標資料庫含有50個Database Link,可能會訪問多個資料來源，那麼這個過程是執行時觸發，在切換中是不會發現的，我們需要提前從db link對應的tns中進行過濾，檢視那些伺服器是否已經開啟了防火牆許可權，指定的埠已經開啟。
10.crontab 修改 
同步主備庫的crontab的資訊，保證主備庫的這些JOB能夠正常執行，有些JOB如果執行頻度極高，需要考慮暫時在切換的過程中先禁用，保證在切換Release環境之後正常開啟。
11.修改orabbix配置 
主備庫的IP發生改變，我們就需要重新配置Orabbix中的連線資訊。
12.檢視是否還有連線在備庫存在
這個是一個持續性的過程，需要留意是否有計劃外的會話依然在備庫，可以使用netstat -nalp來得到一個基本的網路訪問情況
13.留意觀察Scheduler JOB執行正常
檢視是否資料庫內的Scheduler能夠正常執行。