Oracle宕機案例匯總(一)

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"，共同學習，共同成長！！！