Oracle宕機案例匯總(一)

Oracle宕機案例匯總(一)

案例一：UNDO壞塊導(dǎo)致 Oracle無法 Open

場景：

周五馬上下班了，研發(fā)反饋數(shù)據(jù)庫連不上了，由于是公司內(nèi)部的數(shù)據(jù)庫，所有數(shù)據(jù)來源于其他庫通過expdp/impdp 導(dǎo)入得到的，主要用于問題重現(xiàn)處理產(chǎn)品 BUG ，數(shù)據(jù)庫的特點是數(shù)據(jù)量大，用戶多，幾乎每時每刻數(shù)據(jù)庫都在進(jìn)行 impdp 和 drop user 操作，數(shù)據(jù)允許有部分丟失 .... ，好吧，說了這么多，我只想說數(shù)據(jù)庫沒有任何備份，當(dāng)然也沒有啟動歸檔模式；

通過告警日志可以馬上定位到UNDO 壞塊導(dǎo)致的數(shù)據(jù)庫宕機；

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

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

最保險的方式， 通過 rman 備份 + 歸檔進(jìn)行恢復(fù)，可以保證數(shù)據(jù)的一致性 。

但是既然沒有rman ，也是有方法啟動數(shù)據(jù)庫的。

數(shù)據(jù)庫在open 狀態(tài)下出現(xiàn) UNDO 損壞比較容易解決，只要創(chuàng)建新的 UNDO ，當(dāng)前 UNDO 切換到新創(chuàng)建的 UNDO ，刪除舊的 UNDO 就可以解決；

但是當(dāng)前情況是數(shù)據(jù)庫無法OPEN ，只能啟動到 mount 狀態(tài)

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 狀態(tài)下是不允許創(chuàng)建和刪除 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

那么在數(shù)據(jù)庫不能 open 情況下，如何跳過 undo 壞塊，啟動數(shù)據(jù)庫呢？

這時可以使用兩個隱含參數(shù) ”_CORRUPTED_ROLLBACK_SEGMENTS” ， ”   _offline_rollback_segments ” , 兩個參數(shù)效果很相似。

(1)_CORRUPTED_ROLLBACK_SEGMENTS 表示數(shù)據(jù)庫啟動時跳過損壞的回滾段，如果無法確認(rèn)具體哪個回滾段損壞，會選擇跳過所有回滾段，具體用法是在參數(shù)文件中增加參數(shù)，

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

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

(2)_offline_rollback_segments 表示在數(shù)據(jù)庫啟動時，可以指定部分回滾段 offline;

現(xiàn)在萬事具備了，只需要查詢出損壞的回滾段名，或查詢出所有回滾段名加入到 _CORRUPTED_ROLLBACK_SEGMENTS 參數(shù)中，即可open 數(shù)據(jù)庫了。

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

那么問題來了，如何在mount 狀態(tài)下，查看 UNDO 回滾段名稱？

顯然mount狀態(tài)下 是無法直接查詢的；

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

那么在數(shù)據(jù)庫mount 或關(guān)閉狀態(tài)下，如何查詢數(shù)據(jù)庫 UNDO 段名呢？

一般情況下有兩種方法：

方法一：使用操作系統(tǒng)命令strings ，本次案例數(shù)據(jù)庫操作系統(tǒng)為 Redhat6.5;

1.Get SMU information as following command:

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

<======= 請?zhí)鎿Q system01.dbf 文件為您的數(shù)據(jù)庫的 system 表空間的數(shù)據(jù)文件。

得到回滾段名后，在執(zhí)行如下操作即可

2.Add the following parameter in init.ora:

UNDO_MANAGEMENT=MANUAL

_ALLOW_RESETLOGS_CORRUPTION = TRUE

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

<========= 請?zhí)鎿Q SYSSMU*$ 為您的數(shù)據(jù)庫中，步驟 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 工具 ，可以在數(shù)據(jù)庫不啟動情況下，直接查詢或修改數(shù)據(jù)塊部分信息，當(dāng)然也可以查詢 UNDO 段名稱；

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

  -----Oracle 11g 版本， undo$ 表信息一般位于 1 號文件第 225 個數(shù)據(jù)塊中

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 段名

參數(shù)文件：

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

總結(jié)：

通過bbed 工具進(jìn)行測試，并不是 UNDO 任何塊損壞都會造成數(shù)據(jù)庫宕機，只有段頭塊損壞會出現(xiàn)這個問題，可以通過下面 SQL 查看段頭塊；

select  header_file ,  header_block

   from  dba_segments

  where  segment_name like   '_SYSSMU%'

  order   by   2 ;

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

一：open 狀態(tài)下?lián)p壞，直接新建，切換，刪除即可，或通過備份進(jìn)行恢復(fù)；

二： 無法 OPEN ，使用隱含參數(shù)跳過損壞的段，啟動數(shù)據(jù)庫，或通過備份進(jìn)行恢復(fù)；

有時UNDO 損壞在告警日志中并不會馬上報錯，之前遇到過數(shù)據(jù)庫服務(wù)器斷電，來電后啟動數(shù)據(jù)庫時 open 階段一直卡住并沒有任何返回結(jié)果，后臺告警日志也沒有輸出日志，在打開另一個 sqlplus 窗口，檢查數(shù)據(jù)庫狀態(tài)時，發(fā)現(xiàn)數(shù)據(jù)庫已經(jīng)是 open 狀態(tài)了，但是所有 dml 語句都會卡住，無法正常執(zhí)行，這種情況可以考慮到數(shù)據(jù)塊在異常斷電啟動恢復(fù)實例時，要經(jīng)過前滾和回滾，前滾結(jié)束后就可以 open 數(shù)據(jù)庫了，然后在進(jìn)行回滾，而這 次情況看上去是前滾已經(jīng)結(jié)束，回滾出現(xiàn)異常，可以猜測是UNDO出現(xiàn)問題，在沒有備份的情況下，嘗試用 _corrupted_rollback_segments 也可以解決問題；

第二種方法更詳細(xì)解釋可以看我另一篇博客

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

Oracle_UNDO壞塊測試和修復(fù)(BBED)

歡迎關(guān)注我的微信公眾號"IT小Chen"，共同學(xué)習(xí)，共同成長！??！