記錄一次驚心動魄的誤操作(Oracle)

事件回顧：

某月週五晚上，馬上下班了，突然手機連續收到多條告警簡訊，提示我管理的其中一套資料庫的DG備庫無法連線。
突然想到昨天晚上對DG備庫擴容了+DATA磁碟組，本來預計新增30塊100G大小的新盤，擴容3000G空間，但是由於粗心大意，錯誤的多新增了5塊舊盤，一共新增了35塊盤。
新增完成後檢查磁碟容量發現多了5塊盤，資料已經在動態平衡了，第一時間想到這5塊舊盤有沒有問題，檢視ASM日誌，DB日誌沒有發現錯誤，第二天早上檢查資料已經動態平衡結束了，DB日誌沒發現問題。
第一時間連線DG備庫，檢視資料庫例項狀態為mount狀態，檢視DB日誌，顯示ASM磁碟頭損壞，多個資料檔案出現大量壞塊，+DATA磁碟組自動umount，無法掛載。

環境說明：

OS:AIX 7.1
DB:Oracle 11204 RAC + DG(RAC)

事件原因：

發現昨晚多擴容的5塊磁碟，居然是歸檔所使用的/arch 檔案系統盤，DG備庫的歸檔並沒有儲存在ASM儲存中，而是使用的本地檔案系統，最終導致歸檔資料和+DATA磁碟組資料重複寫入，資料大面積損壞，資料庫當機。
之前錯誤的認為已經在使用的磁碟，不會在v$asm_disk中header_status欄位顯示CANDIDATE，所以之前即使發現了擴容+DATA多加了5塊舊盤，也沒有想到會是檔案系統已經在使用的磁碟，單純的認為是5塊舊的新盤。
由於主庫生成歸檔的頻率較低，同時+DATA磁碟組有很多磁碟，所以DG備庫堅持了20多小時才當機。

解決方案：

由於多個資料檔案出現大量壞塊，ASM磁碟頭損壞，針對單個檔案進行恢復難度較大，時間較長，所以採取的辦法是重建DG備庫。

重建DG備庫的過程如下：

一：調整主庫log_archive_dest_state_2引數，由enable改成defer 。

alter system set log_archive_dest_state_2=defer;

二：將備庫/arch 檔案系統對應的5塊歸檔盤改成+ASM磁碟組

2.1 清空/arch對應的vg,lv,檔案系統資訊

2.2 建立新的+ARCH磁碟組，新增這5塊磁碟

三：重建備庫+DATA磁碟組資料

刪除+DATA磁碟組，新建+DATA磁碟組，新增磁碟。 

注意：刪除磁碟組之前，先將引數檔案拷貝出來，便於DG備庫的搭建。

create pfile='/tmp/xxxpfile.ora' from spfile;

四：修改備庫pfile引數檔案，修改備庫歸檔位置

將歸檔位置由/arch改成+ARCH 

五：啟動備庫為mount狀態，恢復DG同步關係

此時備庫+ARCH磁碟組可以正常接收主庫傳來的歸檔檔案。

六：禁用備庫刪除歸檔計劃

為了避免在備庫恢復期間歸檔完整，先禁用備庫刪除歸檔計劃

七：恢復主庫最新的控制檔案，傳到備庫端，備庫重新啟動到mount狀態

八：主庫進行全備

主庫全備大小2T，備份時間約2小時。

九：恢復DG備庫

備庫通過備份軟體進行rman全庫恢復。

restore和recover指定到全備份完成前最後一個SCN號。

主備庫物理位置距離約50KM，恢復了2T多資料，耗時6個多小時。

十：全庫恢復完成後，恢復主庫最新的控制檔案，傳到備庫端，備庫重新啟動到mount狀態

十一：備庫啟動mrp程式，應用最新的日誌

十二：備庫取消mrp，啟動open狀態，再次啟動mrp程式

十三：檢查redo log file和standby log file大小和狀態

十四：修改備庫spfile位置

之前spfile在另一個小磁碟組裡，為了方便管理，將spfile遷移到了另一個磁碟組內

14.1 修改pfile中記錄的spfile位置

14.2 修改OCR中記錄的spfile位置

srvctl config database -d cjcdb
srvctl modify database -d cjcdb -p '+DATA/cjcdb/spfile/spfilecjcdb.ora'

十五：註冊新磁碟組位置+ARCH

srvctl註冊新歸檔磁碟組位置

srvctl config database -d cjcdb
srvctl modify database -db cjcdb -diskgroup "DATA,ARCH,OTHER"

十六：清理舊磁碟組資訊

舊的磁碟組已經刪除了，清空資訊

$ srvctl disable diskgroup -diskgroup dgroup1 -node "mynode1,mynode2"
$ srvctl remove diskgroup -diskgroup diskgroup_name -force

十七：crsctl檢視例項狀態不對，手動重新整理例項狀態

shutdown immediate
startup
srvctl stop database -d dbname -o immediate
srvctl start instance -d dbname -i instance_name1 -o open
srvctl start database -d dbname -o open

十八：啟用修改並測試自動刪除歸檔計劃

18.1 自動刪除指令碼里歸檔目錄由/arch改成了+ARCH 

十九：resize tempfile (20M 到 30G)

備庫建立完成後,tempfile檔案大小隻有20M，修改為和主庫保持一致

select * from dba_temp_files;
alter database tempfile '' resize 30G;

二十:啟動備庫監控

備庫出問題後，定位到原因後，解決問題的同時，臨時將備庫監控取消了，待備庫完成恢復後，在啟動對備庫的監控。

反思：

雖然此次誤操作發生在DG備庫，沒有對生產系統造成任何影響，但由於主庫是一套非常核心的資料庫，如果此次事件發生在主庫而不是備庫，後果會非常嚴重。
出現此次事故根本原因是對備庫操作不夠重視，從而導致關鍵性操作粗心大意。
根據墨菲定律，凡事如果有出錯的可能，在將來的某一天一定會出錯。
所以要做出改變，改變心態，改變安全意識，改變操作規範等。
記錄於此，引以為戒。

歡迎關注我的微信公眾號"IT小Chen"，共同學習，共同成長！！ ！