您好,登錄后才能下訂單哦!
本篇內容介紹了“怎么處理Oracle ORA-03113 ORA-600故障”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
SQL> startup; ORA-03113 end-of-file on communication channel SQL> startup nomount; # 可以nomount成功 SQL> alter database mount; ORA-03113 end-of-file on communication channel
# 從上面現象根據數據庫啟動過程知道,基本定位在控制文件有問題。
Wed Jul 29 10:17:07 2020 ALTER DATABASE MOUNT USER (ospid: 3784): terminating the instance System state dump requested by (instance=1, osid=3784), summary=[abnormal instance termination]. System State dumped to trace file E:\APP\ADMINISTRATOR\diag\rdbms\dzwl\dzwl\trace\dzwl_diag_2708.trc Dumping diagnostic data in directory=[cdmp_20200729101712], requested by (instance=1, osid=3784), summary=[abnormal instance termination]. Instance terminated by USER, pid = 3784
# 出了問題,通過詢問現場人員,服務器有掉電、重啟等操作,trace文件大多沒有明確信息,
# alert日志中前一天有mmon進程的trm追蹤文件的metadata元數據由于掉電損壞的記錄,
# 但是跟此次故障無關,但是也可以看出確實由于掉電有文件損壞,緊接著使用10046 trace啟動過程,
# 果然發現控制文件內容file header記錄的seq號與推測為控制文件block header記錄的bhcsq不一致。
# 排查步驟:
PARSING IN CURSOR #79065416 len=20 dep=0 uid=0 oct=35 lid=0 tim=8397179226 hv=1913505115 ad='7ff8f1ab3f40' sqlid='fr02x8dt0vjav' alter database mount END OF STMT ... WAIT #79065416: nam='control file sequential read' ela= 147 file#=0 block#=16 blocks=1 obj#=-1 tim=8401282794 Error: kccpb_sanity_check_2 Control file sequence number mismatch! fhcsq: 3714 bhcsq: 3717 cfn 0 ...
由于配制了閃回去,使用閃回區控制文件與數據文件目錄控制文件依次嘗試是否有完好的控制文件,發現控制文件均有問題。
編輯創建控制文件語句:
CREATE CONTROLFILE REUSE DATABASE "DZWL" NORESETLOGS NOARCHIVELOG MAXLOGFILES 16 MAXDATAFILES 100 MAXINSTANCES 2 MAXLOGHISTORY 453 LOGFILE GROUP 1'E:\app\Administrator\oradata\DZWL\REDO01.LOG' SIZE 50M, GROUP 2'E:\app\Administrator\oradata\DZWL\REDO02.LOG' SIZE 50M, GROUP 3'E:\app\Administrator\oradata\DZWL\REDO03.LOG' SIZE 50M DATAFILE 'E:\app\Administrator\oradata\DZWL\DATASYN01.DBF', 'E:\app\Administrator\oradata\DZWL\DZWL.DBF', 'E:\app\Administrator\oradata\DZWL\DZWL2019A.DBF', 'E:\app\Administrator\oradata\DZWL\DZWL2019B.DBF', 'E:\app\Administrator\oradata\DZWL\DZWL2020A.DBF', 'E:\app\Administrator\oradata\DZWL\DZWL2020B.DBF', 'E:\app\Administrator\oradata\DZWL\DZWL2021A_01.DBF', 'E:\app\Administrator\oradata\DZWL\DZWL2021B_01.DBF', 'E:\app\Administrator\oradata\DZWL\EXAMPLE01.DBF', 'E:\app\Administrator\oradata\DZWL\MT01.DBF', 'E:\app\Administrator\oradata\DZWL\SYSAUX01.DBF', 'E:\app\Administrator\oradata\DZWL\SYSTEM01.DBF', 'E:\app\Administrator\oradata\DZWL\UNDOTBS01.DBF', 'E:\app\Administrator\oradata\DZWL\USERS01.DBF' CHARACTER SET ZHS16GBK;
數據庫可以正常mount,open階段,報錯ORA-600 [4193],undo表空間有問題。
通過如下Mos文檔解決:
ORA-600 [4193]錯誤解決方案
此解決方法適用于Version 9.2.0.1 to 11.2.0.3 [Release 9.2 to 11.2],沒有平臺限制。
原因:
1, 可能是同一個UNDO塊用于2個不同事務所引起的內部錯誤。
2, ORA-600 [4193] / ORA-600 [4194] for new transactions
3, ORA-600 [4137] for a transaction rollback
解決方案:
創建一個新的UNDO表空間,并且檢查段是否有未回滾。
1.創建一個pfile文件
create pfile='E:\pfile.txt' from spfile;
windows平臺默認是在database下,linux是在dbs下
2.關閉實例
shutdown immediate;
3.編輯pfile文件加入參數
undo_management = manual event = '10513 trace name context forever, level 2' # 將禁止smon進程執行事務回滾操作,以便順利打開數據庫,跳過回滾步驟
4.用pfile啟動數據庫
startup restrict pfile=<initsid.ora>;
5.檢查是否所有的UNDO段都是offline狀態,system段必須在線
select tablespace_name,status, segment_name from dba_rollback_segs where status != 'OFFLINE';
6.創建一個新的UNDO表空間
create undo tablespace UNDOTBS2 datafile ‘D:\oradata\undo02’ size 2000M;
7.刪除舊的UNDO表空間
drop tablespace UNDOTBS1 including contents and datafiles;
8.關閉實例
shutdown immediate
9.啟動到mount狀態
startup mount
10.修改參數
alter system set undo_tablespace =’UNDOTBS2’ scope=spfile;
11.關閉實例
shutdown immediate
12.正常啟動數據庫
startup
“怎么處理Oracle ORA-03113 ORA-600故障”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。