DG 主庫fial over，強制啟用備庫解決案例

2014年1月份的時候，因硬體環境的變更，需要把庫從原來的儲存平台移到新的儲存平台。也就是把資料庫的底層儲存介質更換一下。下面主要記錄一下事故的發生及應對措施。

事情概況

win平台，11R2，64位，單一實例，DG物理備庫。主庫與備庫均只有redo 和業務資料檔案儲存介質為fusion io卡，其它資料檔案、控制檔案等是存放在非fusion io卡介質上的。現需要將儲存介質fusion io 卡更換為virident 卡。2種卡都是直接插在pci插槽上的，且兩卡本身是由同一生產廠家生產過了。最主要是有人反應之前測試用時直接用檔案拷貝方式來進行移庫的。鑒於2種卡的拷貝速度很快，於是採用了直接資料檔案卡對卡拷貝方式來進行換卡操作，然後將盤符改成原來一模一樣的，卡的拷貝速度很快，忘了是幾百M每秒，而且只拷貝存放在fusion io 卡上的資料檔案到virident卡上，其它的資料檔案及控制檔案等 東西不需要移動。

淪入事故

於是乎，先將各服務都關掉，主備庫都shutdown。開始針對主庫採取檔案卡到卡的對拷。很快拷貝完了，盤符也改好了。於是啟動主庫，啟動時報錯如下：
12345678 Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\branch_p\branch\trace\branch_lgwr_2196.trc:
ORA-00313: ??????? 3 (???? 1) ???
ORA-00312: ???? 3 ?? 1: 'J:\REDO\BRANCH\REDO03.LOG'
ORA-01382: ?? 1 ???????? J:\REDO\BRANCH\REDO03.LOG????????? (4096) ???????? (512)
Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\branch_p\branch\trace\branch_lgwr_2196.trc:
ORA-00313: ??????? 3 (???? 1) ???
ORA-00312: ???? 3 ?? 1: 'J:\REDO\BRANCH\REDO03.LOG'
ORA-01382: ?? 1 ???????? J:\REDO\BRANCH\REDO03.LOG????????? (4096) ???????? (512)

雖然有亂碼，但是從報錯錯誤碼可以看出是無法開啟日誌組。經查發當無法開啟的日誌組為current。從ora-01382可知，是因為記錄檔的block size比virident卡的磁碟扇區大小要大。所以日誌組無法開啟。
開始沒注意到ora-01382這個錯誤，心想先想辦法把庫給拉起來，於是使用命令alter database clear unarchived logfile group 3;

可是報錯依舊如上。後來找到解決ORA-01382這個錯誤了，用 alter system set "_disk_sector_size_override"=true;  更改參數解決啟動報錯無法開啟日誌的問題，然後繼續啟動資料庫，結果能正常啟動，但是庫依舊執行前面的clear log操作，這一clear了就會使得資料有丟失，於是就趕緊cancel。然後把拷貝到virident卡上面的資料全部清空，準備重新將fusion io卡上的資料拷貝過來。然後在庫startup mount後設定隱含參數 _disk_sector_size_override值再open庫。

 已經將virident卡上的資料清掉了，再次將原資料檔案拷貝過來了，正拷貝過程中想到，這時的控制檔案已經在之前clear log時SCN發生了變化。fusion io卡上的資料檔案頭scn已經與此時控制檔案的scn不一致了，資料庫是無法開啟了。之前clear log期間發生的日誌切換（也就是產生的archivelog ）也都清了，這樣歸檔記錄檔也不連續了。備庫與主庫之前的日誌出現gap了。

事故解決

現在有2種解決方案。在拷貝檔案之前做了一個rman備份，此備份是在停掉業務時，準備換卡前做的備份，所以用它資料絕不會掛失，我們可以用rman備份檔案來做恢複。另一種方法是換卡前已確保發生了業務的資料全部傳入備庫，所以可以把備庫拉起來當主庫用。此時的DG環境是主庫fail over了，備庫東西都完好。

定下一步的解決方案。

鑒於rman備份檔案恢複起來速度過慢。而我們距離正常業務開展時間少於3個小時。然後決定採取將備庫拉起來當主庫用這種方法。但是備庫一樣要把fusion io卡上的資料移到virident卡上，還是採取檔案對拷方式。省時。

這次在拷貝前（庫已停）靜態備份所有的資料檔案，以防再次發生在主庫上面的錯誤。備份完後，將fusion io卡上的資料物理拷貝到virident卡上，並把盤符互換，接下來庫startup mount ， alter system set "_disk_sector_size_override"=true; 再open read only。可以正常開啟。好了，儲存介質更換成功了。下一步是要把備庫啟用當主庫用，是強制啟用備庫，關庫啟動到mount，使用命令alter database activate standby database; 開啟了備庫，再次重啟一下備庫。連上業務系統，能正常使用。於是再關機，拔下fusion io 止。到了正常業務操作時間，此庫已經可以當生產庫來用了。原來的主庫就廢掉，重建立一個physical standby。

總結：不管做什麼先備份。備份好後再做事。做事前提前演練操作，冷靜處理問題。

相關參考:

Oracle Data Guard 重要配置參數

基於同一主機配置 Oracle 11g Data Guard

探索Oracle之11g DataGuard

Oracle Data Guard （RAC+DG) 歸檔刪除策略及指令碼

Oracle Data Guard 的角色轉換

Oracle Data Guard的日誌FAL gap問題

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 處理方法