背景介紹
給某職能單位檢查Oracle數據庫的時候,發現dataguard備庫并沒有啟動(PS:該單位沒有DBA的角色,平日里并沒有巡檢),備庫運行在超融合平臺之上,使用的windows操作系統,我試著啟動該備庫,得到如下提示:
alter database open
*
第 1 行出現錯誤:
ORA-10458: standby database requires recovery
ORA-01196: 文件 1 由于介質恢復會話失敗而不一致
ORA-01110: 數據文件 1: 'D:\APP\ADMINISTRATOR\ORADATA\SPECTRA\SYSTEM01.DBF'
分析步驟
和用戶做了一些簡單的溝通,得知一個月前該備庫從物理機遷移到超融合平臺之后,就沒再管它,于是乎我打開了備庫的Alert日志,提示缺少sequence#為22598的歸檔文件及以后。那么問題基本可以定位為:備庫遷移過來之后就沒打開過,有大量的歸檔文件沒有傳輸過來!
處理過程
此時只能祈禱主庫的自動清理歸檔日志腳本沒有工作,登錄到主庫一看,還真就沒刪除,用戶和實施人員的不專業幫了大忙!
1、從主庫復制sequence#=22598及之后的歸檔文件到備庫(漫長的等待…)
ctrl+c
ctrl+v
2、備庫rman注冊歸檔恢復目錄
rman target /
catalog start with D:\app\log';
YES
select count(*) from v$archived_log; #檢查歸檔文件是否注冊成功
3、備庫啟動到mount狀態,啟動恢復
startup mount
alter database recover managed standby database disconnect from session;
4、此時觀察備庫的Alert日志(肉眼可見的速度在追進度)
tail -100f Alert.log
Media Recovery Log D:\APP\INTERLIB\LOG\1_234891_1023798854.DBF
Media Recovery Log D:\APP\INTERLIB\LOG\1_234892_1023798854.DBF
Media Recovery Log D:\APP\INTERLIB\LOG\1_234893_1023798854.DBF
Media Recovery Log D:\APP\INTERLIB\LOG\1_234894_1023798854.DBF
Media Recovery Log D:\APP\INTERLIB\LOG\1_234895_1023798854.DBF
5、日志出現如下提示,則代表恢復完成
Media Recovery Waiting for thread 1 sequence 247384 (in transit)
6、取消恢復狀態
alter database recover managed standby database cancel;
7、開啟數據庫,并啟動實時應用功能
alter database open
alter database recover managed standby database using current logfile disconnect from session;
8、測試主備庫,確保數據能夠實時應用(主庫建表插數據,備庫查看)
后話
這次多虧了實施人員沒有部署主庫歸檔日志自動清理腳本,不然可能就要重搭備庫了。那么對我們DBA來說,遇到dataguard的環境時,用戶如果要求清理歸檔文件的時候,格外的需要注意,要先驗證主備庫是否同步正常。我的做法,是在主庫建張測試表,看看備庫是否能夠同步創建。確定dg備庫功能正常之后,再對歸檔文件進行刪除
最后修改時間:2024-08-16 09:29:36
「喜歡這篇文章,您的關注和贊賞是給作者最好的鼓勵」
關注作者
【版權聲明】本文為墨天輪用戶原創內容,轉載時必須標注文章的來源(墨天輪),文章鏈接,文章作者等基本信息,否則作者和墨天輪有權追究責任。如果您發現墨天輪中有涉嫌抄襲或者侵權的內容,歡迎發送郵件至:contact@modb.pro進行舉報,并提供相關證據,一經查實,墨天輪將立刻刪除相關內容。




