一、項目背景
通過架設activephysical standby dataguard，将現有2-node 11gr2 rac資料庫遷移到新硬體裝置(更換伺服器和存儲)，且生産環境又增加一套雙節點備庫。
實施過程中我們用orion做了io性能測試，也用spa性能對比分析，這些都是前期工作，這裡不做贅述。
1、技術架構
2、資料庫環境
3、網絡配置
二、實施流程
三、實施前準備工作
rac to rac 11g r2dataguard 所需要的初步需求已經建立好了,下面是主從部分。
1、primary site
資料庫目前已是adg主庫
2、standby site
（1）雙節點linux安裝和配置
（2）雙節點oracle11g grid infrastructure安裝和配置
（3）雙節點oracle11g rac software安裝和配置
rac的安裝我們這裡不做贅述。
四、實施步驟
1、現有環境調整
（1）/etc/hosts/設定
--主備4台主機添加主備scan ip解析資訊
2、配置primaryrac database的參數
（1）檢查force logging
--目前應該是開啟的
（2）建立standby日志
--檢視現有redo日志構成
（3）修改dataguard相關的初始化參數
--修改前後檢視參數資訊
（4）建立standby資料庫的pfile
--建立一個臨時的備份路徑
（5）更新tnsnames.ora
（6）備份資料庫
--通過下面腳本全備資料庫
3、準備standby rac database
（1）建立相關目錄
（2）拷貝備份檔案
（3）複制密碼檔案
--配置dataguard 需要兩邊資料庫密碼保持一緻
（4）建立參數檔案
（5）修改環境變量
（6）添加tnsnames.ora
4、建立physical standby database
（1）連接配接測試
--在所有主備節點分别執行
（2）将standby執行個體啟動到momount狀态
（3）恢複資料庫
（4）檢查參數
（5）建立online redo，standby redo，重新開機資料庫
--建立standbyredo logs
（6）standby database注冊到ocr裡
（7）開啟日志應用
（8）檢查日志應用進度
5、實體standby和physical切換
rac環境的切換必須是單執行個體狀态下去完成，是以要關閉一個節點。
（1）switchover切換時需要考慮的操作
如果在執行switchover時不想指定with session shutdown，以下過程可能需要在主備庫上操作：
（2）檢查現有的事務
（3）檢查各執行個體alert日志
檢查主備庫各執行個體的alert日志是否正常。
（4）主庫隻保留一個執行個體
--在主rac和備rac的第二節點分别執行
（5）檢查備庫日志應用情況
（6）主庫上操作
（7）備庫上操作
（8）備用主備庫另外節點
（9）确認新備庫的日志應用情況
6、切換後的資料确認
理論上，實體standby database與primary database是相同的資料庫，switchover操作也不會導緻資料丢失。為安全起見，仍需對資料庫做一系列檢查，包括：
五、實施影響評估
（1）主備角色切換過程中，涉及到啟停資料庫。為了順利啟停資料庫，需要避免在有大事務運作期間執行主備切換。否則會延長資料庫的停機時間。建議在業務量小的時間段進行操作。
（2）通常情況下，dataguard switchover操作不會引起資料丢失，并且切換的過程是可逆的。
（3）adg主備切換會啟停資料庫，手動切換時間正常情況下不超過3分鐘。切換完成後，業務通路資料庫的位址需要更改。
六、應急回退措施
如果在切換過程中存在異常且會影響業務停機時間，建議停止adg主備切換操作，重新選擇合适的切換時間。
如果實體備用資料庫發生錯誤的情況，并且不可能繼續切換，可能需要将已轉換成實體備用角色的資料庫回退到主資料庫角色。以下是回退步驟：
七、趟過的坑
我們的生産庫上之前還有一個單機adg的，前面為了表述簡單，我将這個細節給去了。
我們在做測試的時候因為裝置不夠，沒有模拟到這個環節。在進行切換的時候，出現下面的情形：
作者介紹：郭軍偉
中科大軟體工程碩士
曾供職于阿裡巴巴，華夏媒體資訊技術有限公司
現供職于某第三方支付公司進階資料庫工程師
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-03-25</b>