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"，共同学习，共同成长！！！