Oracle當機案例彙總(一)

案例一：UNDO壞塊導致 Oracle無法 Open

場景：

週五馬上下班了，研發反饋資料庫連不上了，由於是公司內部的資料庫，所有資料來源於其他庫透過expdp/impdp 匯入得到的，主要用於問題重現處理產品 BUG ，資料庫的特點是資料量大，使用者多，幾乎每時每刻資料庫都在進行 impdp 和 drop user 操作，資料允許有部分丟失 .... ，好吧，說了這麼多，我只想說資料庫沒有任何備份，當然也沒有啟動歸檔模式；

透過告警日誌可以馬上定位到UNDO 壞塊導致的資料庫當機；

ORA-01578 : ORACLE data block corrupted (file # 3 , block # 280 )

ORA-01110: data file 3: '/u02/app/oracle/oradata/orcl11/ undotbs01.dbf '

最保險的方式， 透過 rman 備份 + 歸檔進行恢復，可以保證資料的一致性 。

但是既然沒有rman ，也是有方法啟動資料庫的。

資料庫在open 狀態下出現 UNDO 損壞比較容易解決，只要建立新的 UNDO ，當前 UNDO 切換到新建立的 UNDO ，刪除舊的 UNDO 就可以解決；

但是當前情況是資料庫無法OPEN ，只能啟動到 mount 狀態

SQL>  startup

ORACLE instance started.

Total System Global Area  784998400 bytes

Fixed Size                  2257352 bytes

Variable Size             515903032 bytes

Database Buffers          264241152 bytes

Redo Buffers                2596864 bytes

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-01578 : ORACLE data block corrupted (file # 3 , block # 280 )

ORA-01110: data file 3: '/u02/app/oracle/oradata/orcl11/ undotbs01.dbf '

Process ID: 8265

Session ID: 1 Serial number: 5

 

顯然在mount 狀態下是不允許建立和刪除 undo 表空間操作

SQL> create undo tablespace UNDOTBS2 datafile '/u02/app/oracle/oradata/orcl11/undotbs02.dbf' size 1M autoextend on;

create undo tablespace UNDOTBS2 datafile '/u02/app/oracle/oradata/orcl11/undotbs02.dbf' size 1M autoextend on

*

ERROR at line 1:

ORA-01109:  database not open

SQL> drop tablespace UNDOTBS1 including contents and datafiles;

drop tablespace UNDOTBS1 including contents and datafiles

*

ERROR at line 1:

ORA-01109: database not open

 

那麼在資料庫不能 open 情況下，如何跳過 undo 壞塊，啟動資料庫呢？

這時可以使用兩個隱含引數 ”_CORRUPTED_ROLLBACK_SEGMENTS” ， ”   _offline_rollback_segments ” , 兩個引數效果很相似。

(1)_CORRUPTED_ROLLBACK_SEGMENTS 表示資料庫啟動時跳過損壞的回滾段，如果無法確認具體哪個回滾段損壞，會選擇跳過所有回滾段，具體用法是在引數檔案中增加引數，

_CORRUPTED_ROLLBACK_SEGMENTS=(SYSSMU1$, _SYSSMU2$, _SYSSMU3$, ...etc)

  具體回滾段名稱需要查詢得到，

(2)_offline_rollback_segments 表示在資料庫啟動時，可以指定部分回滾段 offline;

 

現在萬事具備了，只需要查詢出損壞的回滾段名，或查詢出所有回滾段名加入到 _CORRUPTED_ROLLBACK_SEGMENTS 引數中，即可open 資料庫了。

某些情況下，在undo 損壞時，會在告警日誌中顯示幾號回滾段損壞，但是本次沒有顯示具體回滾段名稱；

那麼問題來了，如何在mount 狀態下，檢視 UNDO 回滾段名稱？

顯然mount狀態下 是無法直接查詢的；

SQL> select * from v$rollname;

select * from v$rollname

              *

ERROR at line 1:

ORA-01219: database not open: queries allowed on fixed tables/views only

 

那麼在資料庫mount 或關閉狀態下，如何查詢資料庫 UNDO 段名呢？

一般情況下有兩種方法：

方法一：使用作業系統命令strings ，本次案例資料庫作業系統為 Redhat6.5;

1.Get SMU information as following command:

[root@chenjch ~]# $strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u > listSMU

<======= 請替換 system01.dbf 檔案為您的資料庫的 system 表空間的資料檔案。

得到回滾段名後，在執行如下操作即可

2.Add the following parameter in init.ora:

UNDO_MANAGEMENT=MANUAL

_ALLOW_RESETLOGS_CORRUPTION = TRUE

_CORRUPTED_ROLLBACK_SEGMENTS=(SYSSMU1$, _SYSSMU2$, _SYSSMU3$, ...etc)

<========= 請替換 SYSSMU*$ 為您的資料庫中，步驟 1 查詢出來的具體 SYSSMU*$ 名稱。

3. Startup the database using pfile:

SQL>startup pfile='init.ora'

SQL>show parameter corrupt;

4. Recover and open the database:

SQL>RECOVER DATABASE UNTIL CANCEL;

Cancel

SQL>ALTER DATABASE OPEN RESETLOGS;

 

方法二：bbed 工具 ，可以在資料庫不啟動情況下，直接查詢或修改資料塊部分資訊，當然也可以查詢 UNDO 段名稱；

11g 開始已經沒有這個工具了，需要單獨下載；

  -----Oracle 11g 版本， undo$ 表資訊一般位於 1 號檔案第 225 個資料塊中

BBED> set file 1 block 225          

        FILE#           1

        BLOCK#         225

BBED> map

 File: /u02/app/oracle/oradata/orcl11/system01.dbf (1)

 Block: 225                                   Dba:0x004000e1

------------------------------------------------------------

 KTB Data Block (Table/Cluster)

......      

  sb2 kdbr[25]                               @86        ------- 含有 25 個 UNDO 段

......

BBED> p kdbr

sb2 kdbr[0]                                 @86       8078

sb2 kdbr[1]                                 @88       8011

......

sb2 kdbr[23]                                @132      6537

sb2 kdbr[24]                                @134      6470

 

BBED>  x /rnc *kdbr[0]          ---- 檢視 號 UNDO 段名稱

col    1[6] @8151:  SYSTEM

 

BBED>  x /rnc *kdbr[1]          ---- 檢視 1 號 UNDO 段名稱

col   1[20] @8085: _SYSSMU1_4115952380$

......

依次可以查詢出所有UNDO 段名

 

引數檔案：

#*.undo_tablespace='UNDOTBS1'

#*.undo_management=AUTO

*.undo_tablespace='SYSTEM'

*.undo_management='MANUAL'

*._corrupted_rollback_segments='_SYSSMU1_4115952380$','_SYSSMU2_3882698531$','_SYSSMU3_1780844141$' ...... '   

SQL> shutdown immediate

 

SQL> startup

ORACLE instance started.

Total System Global Area  784998400 bytes

Fixed Size                  2257352 bytes

Variable Size             515903032 bytes

Database Buffers          264241152 bytes

Redo Buffers                2596864 bytes

Database mounted.

Database opened .

 

總結：

透過bbed 工具進行測試，並不是 UNDO 任何塊損壞都會造成資料庫當機，只有段頭塊損壞會出現這個問題，可以透過下面 SQL 檢視段頭塊；

select  header_file ,  header_block

   from  dba_segments

  where  segment_name like   '_SYSSMU%'

  order   by   2 ;

UNDO 損壞可以分為幾種情況：

一：open 狀態下損壞，直接新建，切換，刪除即可，或透過備份進行恢復；

二： 無法 OPEN ，使用隱含引數跳過損壞的段，啟動資料庫，或透過備份進行恢復；

 

有時UNDO 損壞在告警日誌中並不會馬上報錯，之前遇到過資料庫伺服器斷電，來電後啟動資料庫時 open 階段一直卡住並沒有任何返回結果，後臺告警日誌也沒有輸出日誌，在開啟另一個 sqlplus 視窗，檢查資料庫狀態時，發現資料庫已經是 open 狀態了，但是所有 dml 語句都會卡住，無法正常執行，這種情況可以考慮到資料塊在異常斷電啟動恢復例項時，要經過前滾和回滾，前滾結束後就可以 open 資料庫了，然後在進行回滾，而這 次情況看上去是前滾已經結束，回滾出現異常，可以猜測是UNDO出現問題，在沒有備份的情況下，嘗試用 _corrupted_rollback_segments 也可以解決問題；

第二種方法更詳細解釋可以看我另一篇部落格

http://blog.itpub.net/29785807/viewspace-2128326/

Oracle_UNDO壞塊測試和修復(BBED)

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