一、背景概述
接到客户电话，数据库delete 数据一直卡住。
2021-02-10 10:00
客户提供堡垒机远程方式，登录操作系统，发现数据库异常卡顿，后台有大量等待事件，磁盘io 已经达到峰值
2021-02-11 23:00
数据库重新起停时间需要2 小时以上，且磁盘io 一直处于写满状态，且再最后一次启动数据库后，undo 出现坏块，需要客户进行排查磁盘是否损坏
2021-02-19 09:00
接到客户通知，磁盘修复成功。重新连入数据库，修复坏块，重新打开数据库
二、本次问题的细节
2.1 undo 段坏块处理
在磁盘修复成功后，美创工程师重新启动数据库，但是smon 进程监控到#116 数据文件存在坏块，也就是undo 段仍然存在坏块，无法进行回滚，为了保持数据库的一致性读，smon 进程直接关闭数据库了
需要新建undotbs2 表空间替换掉已经坏掉的undotbs1 表空间。但是数据库只有在open 的状态下才能创建新的undo 表空间。为了防止SMON 进程再次检测到坏块关闭数据库，美创工程师将有坏块的#116 数据文件进行offline drop 处理。
startup mount
alter database datafile 116 offline drop;
也可以通过设置10531event ，禁止smon 进程进行回滚
startup mount
alter system set events '10513 trace name context forever,level 2';
以上两种方法皆可以使数据库处于open 状态，不被smon 进程强制关闭
打开数据库，创建新的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 、确认数据库存储存在故障后，最好不要再对数据库进行读写或者启停操作，避免发生数据文件损坏。