背景

有臺伺服器由於掉電導致資料庫無法開啟，處理過程如下。

1.故障現象

(1)啟動現象

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

# 從上面現象根據資料庫啟動過程知道，基本定位在控制檔案有問題。

(2)alert日誌現象

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

2.故障分析

# 出了問題，透過詢問現場人員，伺服器有掉電、重啟等操作，trace檔案大多沒有明確資訊，

# alert日誌中前一天有mmon程式的trm追蹤檔案的metadata後設資料由於掉電損壞的記錄，

# 但是跟此次故障無關，但是也可以看出確實由於掉電有檔案損壞，緊接著使用10046 trace啟動過程，

# 果然發現控制檔案內容file header記錄的seq號與推測為控制檔案block header記錄的bhcsq不一致。

# 排查步驟：

10046追蹤

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
...

3.故障解決

(1)嘗試有沒有好的控制檔案

由於配製了閃回去，使用閃回區控制檔案與資料檔案目錄控制檔案依次嘗試是否有完好的控制檔案，發現控制檔案均有問題。

(2)沒有備份，只能重建控制檔案

編輯建立控制檔案語句:

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;

4.正常mount，open再次報錯ORA-600 [4193]

資料庫可以正常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

此文件還適用  ORA-600 4194 4197

(6)總結   

    比較幸運，undo中沒有事務，重新建立undo之後，並沒有報錯內部不一致，如果undo中有未提交事務，需要回滾，則還需要

繼續特殊處理，才可以正常。