一、背景概述

2021-02-10 9:00 

工程师接到客户电话，数据库delete数据一直卡住。

2021-02-10 10:00 

客户提供堡垒机远程方式，美创工程师登录操作系统，发现数据库异常卡顿，后台有大量等待事件，磁盘io已经达到峰值

2021-02-11 23:00

数据库重新起停时间需要2小时以上，且磁盘io一直处于写满状态，且再最后一次启动数据库后，undo出现坏块，需要客户进行排查磁盘是否损坏

2021-02-19 09:00

接到客户通知，磁盘修复成功。美创工程师重新连入数据库，修复坏块，重新打开数据库

二、本次问题的细节

undo段坏块处理

在磁盘修复成功后，美创工程师重新启动数据库，但是smon进程监控到#116数据文件存在坏块，也就是undo段仍然存在坏块，无法进行回滚，为了保持数据库的一致性，smon进程直接关闭数据库了

需要新建undotbs2表空间替换掉已经坏掉的undotbs1表空间。但是数据库只有在open的状态下才能创建新的undo表空间。

为了防止SMON进程再次检测到坏块关闭数据库，美创工程师将有坏块的#116数据文件进行offline drop处理。

startup mount

alter database datafile 116 offline drop;

打开数据库，创建新的undo表空间，并设置为默认表空间

create undo tablespace undotbs2 datafile '/oradata/ETL/UNDOTBS2.dbf' size 1G autoextend on;

alter system set undo_tablespace=undotbs2 scope=both;

删除旧的表空间，但是原undo表空间仍然存在活跃的undo段

drop tablespace undotbs1 including contents and datafiles;

  查询相关视图，获取所有原undo表空间仍活跃的undo段 

select status,segment_name from dba_rollback_segs where status not in ('OFFLINE') and tablespace_name='UNDOTBS1';

添加隐含参数至pfile参数文件中，跳过以上查出的所有undo段

*._allow_resetlogs_corruption=true

#._allow_terminal_recovery_corruption=true

*._corrupted_rollback_segments=(_SYSSMU10_1197734989$,_SYSSMU20_1050586925$,_SYSSMU26_3131552754$

,_SYSSMU28_1349284785$,_SYSSMU32_980979620$,_SYSSMU34_3070439537$,_SYSSMU47_2705532003$,

_SYSSMU50_602588002$,_SYSSMU51_201410034$,_SYSSMU58_3524391680$,_SYSSMU59_773718799$,

_SYSSMU60_1941620517$,_SYSSMU61_1757677461$,_SYSSMU64_3091325918$,_SYSSMU65_2877150887$,

_SYSSMU66_2848890605$)

关闭数据库，以修改后的pfile文件进行启动数据库

startup  pfile=/oracle/product/11.2.0/db_1/dbs/initETL.ora;

删除旧的表空间及其的所有数据，成功！

drop tablespace undotbs1 including contents and datafiles;

至此，新的undo表空间替换成功！数据库正常运行！

注意:将参数文件中添加的隐含参数注释掉，重新启动数据库

三、总结和建议

1 、确认数据库存储存在故障后，最好不要再对数据库进行读写或者启停操作，避免发生数据文件损坏。