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

chenoracle發表於2020-12-06
事件回顧:
某月週五晚上,馬上下班了,突然手機連續收到多條告警簡訊,提示我管理的其中一套資料庫的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備庫,沒有對生產系統造成任何影響,但由於主庫是一套非常核心的資料庫,如果此次事件發生在主庫而不是備庫,後果會非常嚴重。
出現此次事故根本原因是對備庫操作不夠重視,從而導致關鍵性操作粗心大意。
根據墨菲定律,凡事如果有出錯的可能,在將來的某一天一定會出錯。
所以要做出改變,改變心態,改變安全意識,改操作規範等。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29785807/viewspace-2739850/,如需轉載,請註明出處,否則將追究法律責任。

相關文章