關於10G DATAGUARD實施的幾點總結

上個星期剛和客戶做完一次Oracle 10G DATAGUARD 的實施，  在方案的整理，實施過程中遇到了大大小小的問題，現在做下記錄總結：

1.此次standby 庫是直接透過 客戶生產環境的資料庫集中備份方式恢復，備份是rman備份，所以我們的思路便是：
（1）集中備份前天晚上進行日常備份，此時備份的控制檔案什麼的都是current control file ；
（2） 透過集中備份rman 恢復前一天晚上資料；
（3）生產primary庫 生成pfile ,standby control file 複製到standby庫；
（4）追平歸檔。

2.      嚴格按照步驟，實施文件要多次稽核。
此次有兩個低階錯誤浪費了較長時間：
（1）在建立密碼檔案的步驟，認為之前主機工程師應該是生產全軟體目錄已經恢復過去，於是無需再次建立，於是當時跳過該步驟，導致後來 日誌一直無法同步，檢視alert日誌才知 一直報了 ORA-16191錯誤 。最後  從primary庫     將密碼檔案複製standby庫即可。
（2）看錯目錄，這是非常低階都不好意思說的，在寫文件時將startup nomount pfile=‘xxx'的目錄寫錯了，於是在standby   庫啟動資料庫時一直報pfile有問題，         ORA-01078: failure in processing system parameters,一直以為是修改pfile檔案時搞壞了。後來才發現目錄寫錯了。。太粗心了，DBA大忌。                  
           
3.    standby庫恢復完成之後還是要手工建立一次standby;

4.      恢復完成後在執行recover standby database until cancel 追歸檔時報一下錯誤。                                                                  

ORA-00283: recovery session canceled due to errors
ORA-19909: datafile 1 belongs to an orphan incarnation
ORA-01110: data file 1: '/oracle/oradata/xxxxx '                          

MOS上說：
The Standby Database has been activated, then flashback to be Physical Standby again. 
Cause
This is caused by Bug 6035495 ORA-19909 during MRP / RMAN-600 on resync
Fixed-Releases: 10.2.0.4, 11.1.0.0
Details:
ORA-19909 during MRP or RMAN-600 (8201) during RMAN resync can occur.
MRP encounter same error and standby has resetlogs done

實際上這一步 歸檔沒做完全，繼而導致後面standby庫接收日誌後一直是 沒有apply，最終導致 切換時standby一直提示要 recover needed。
當時，並沒有那麼多時間，考慮到資料庫並不大，於是 重新直接在主庫生重新生成standby control file後 重新恢復，然後才成功。

5.oracle 10 g dataguard 生產使用broker的案例比較少，還是建議少用 。

6.資料庫在做dataguard 切換時，切記保證無連線存在，此時最好停止業務應用。

7.listener問題，其實在建立監聽的時可以將的監聽與生產使用監聽分別獨立開來，就是重開一個監聽埠供dataguard使用，客戶有出現過dataguard出現bug致使 監聽無法啟動從而影響了生產業務的案例。

大概就這麼多了。引以為戒吧！