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