数据库版本9204   操作系统版本redhat
l FFc}(\0IXPUB技术博客2nBo2@&w
1) 现象：IXPUB技术博客3`;l]:poW
系统实在太缓慢了，数据库在13点15分左右shutdown abort，但启动后依然很慢(WAIT IO很高)IXPUB技术博客;_g1w/IK6d\J6Q
整个操作系统的WAIT IO很高，达到70%-80%
R(N)lu&v(wK0数据库都是db file sequential read 55个, buffer busy wait 37个，log sync 12个IXPUB技术博客+J\.u%R^4? N d
系统操作非常缓慢，使用iostat 初步可以定位到是HOME目录读写很频繁，数据库文件都在HOME目录下，没有其他应用。IXPUB技术博客1PyW(RH{

o7Hp6D\aZm02) 检查过程：
dq6UE&y0查看数据库ALERTLOG，日志非常大，查询很缓慢IXPUB技术博客"WTd \HR7F1Y
不停地报错IXPUB技术博客%mQ7l*Rk B f"Z
SMON: mark undo segment 32 as available
h*oW/Z5Q L9N0SMON: about to recover undo segment 32IXPUB技术博客5YG3J/jP'bYG
IXPUB技术博客q*P%P7} G!no
数据库造成buffer busy wait等SQL语句根据维护人员说，都没有变化，所以应该不是原因。语句都用到索引。
U0j/z$sS T"^0
L`3bcIYj03) 处理过程：
GNDn!|0从目前情况来看，只能先处理掉ALERTLOG的报错。根据错误信息，查到一个场景非常类似IXPUB技术博客,`(u~#d3xZd*o
http://www.oracleblog.org/working-case/not-use-shutdownabort/
n~+z Q.@0这个场景也是由于shutdown abort导致一个undo segment出现异常，SMON不断去处理这个undo segmentIXPUB技术博客fgcUkW
IXPUB技术博客rVZ6HHx#Q5{Z
处理方法是把这个undo segment手工ONLINE
eAB F#O }0自动管理的undo下,可以对回滚段做一些手工操作IXPUB技术博客+{yff&ID0v
0x00000004    Allow RBU operations to be executed in SMU mode
\K"w.d5ltYu%fk5I0
_E5P+qcH6Jl(^(a0SQL> alter session set "_smu_debug_mode"=4;     
xu$[aJ;G0vr0Session altered.                                
F
^)` ZGZ)p0                                                IXPUB技术博客lPBD)s)`4BN
SQL> alter rollback segment "_SYSSMU32$" online;                                               
9i8E0ZD%G^0Rollback segment altered. IXPUB技术博客JGrM&xW"q
IXPUB技术博客J]0v{7A!w
处理后系统逐步恢复正常，wait io恢复到10%-30%左右，异常数据库事件(buffer busy wait)消失。IXPUB技术博客U6T2n#@O h7sLQF
IXPUB技术博客:T$m2HD _:wiT
4) 深入了解情况IXPUB技术博客wSb4J%I~v
IXPUB技术博客"KC _ aG@d-l"ZJ
早上有同事对一个大表进行清理，可能是清理方法有问题，造成UNDO表空间爆掉(回滚段不能扩展)，redolog频繁切换，然后他加大了UNDOTBS的空间(resize filename)，系统自行建立了很多新的UNDO SEGMENT，清理数据可能是上午10点后造成系统缓慢的原因
c8`E*DaS C0IXPUB技术博客;\nII$Db
13点15分 进行了shutdown abort，造成了undo segment 32异常，数据库处于异常状态，SMON进程不停地恢复undo segment 32，造成系统的I/O很繁忙