記一次奇葩的ADG搭建過程

起因

一次主庫問題導緻需要做failover切換，切換後需要重新搭建備庫，但是當初設計的時候，備庫的環境本不是做此用途的，是以環境差異較大，導緻了這次奇葩問題的出現。

問題描述

 主備庫都是ASM環境，不過切換後的主庫規劃的是單個較大的磁盤組，而備庫是多個較小的磁盤組，如下圖所示：

    主庫

    備庫

可以看到，即使備庫的磁盤組使用的是external模式，單個磁盤組的最大容量也隻在9T左右，而主庫資料檔案的總大小接近9T，于是第一次duplicate之後，發現報錯了，容量不夠存放所有的檔案了……

解決方法嘗試

碰到這種情況，我心想隻能恢複資料檔案的時候指定路徑了，幸好duplicate腳本是可以指定資料檔案的路徑的，通過SETNEWNAME參數，将源端的資料檔案指定一部分到DATA2，另一部分指定到DATA3，再次執行腳本。然後…依然報錯：

set newname手動指定資料檔案路徑

此處提示DATA2空間滿

可以看到，setnewname指令是生效了的，但是通過ASMCMD去檢視具體檔案，發現還是恢複到了DATA2，奇怪。

最終解決辦法

無奈隻能去翻閱一下Oracle的相關文檔了，最終找到了問題所在，參考：OnStandby Datafiles are Going Into Wrong Diskgroup (Db_file_name_convert, Db_create_file_dest ) (Doc ID1408666.1)、DataguardDB/LOG FILE NAME CONVERT has been set but files are created in adifferent directory (Doc ID 1348512.1)

If OMF parameters are set on the standby, then new files on that standby are always created as OMF, regardless of how they were created on the primary. Therefore, if both the DB_FILE_NAME_CONVERT and DB_CREATE_FILE_DEST parameters are set on the standby, the DB_CREATE_FILE_DEST parameter takes precedence.

其實就是ASM環境下啟用OMF時，DB_CREATE_FILE_DEST參數的優先級更高，檢視輔助執行個體的pfile檔案，确實設定了DB_CREATE_FILE_DEST，将此參數删除，再次執行，問題解決：

總結

正常情況下，DG備庫作為容災，環境是與主庫保持一緻的。本次遇到的問題應該是極少出現的情況，萬一有遇到相同情況，僅以此文作為參考。。。