能恢复，但需数据库处于archivelog模式、有损坏前完整备份及覆盖至故障点的所有归档日志；否则rman还原与前滚失败，报ora-01157等错误。
无法回滚的事务不是“卡住”，而是undo数据块损坏或缺失，导致smon无法读取回滚段头块或事务槽——此时不能靠等待或重试解决，必须干预回滚段生命周期。
ORA-01595 / ORA-00604 出现时，先确认哪些回滚段实际失效
不要直接执行 DROP ROLLBACK SEGMENT。先查状态：
SELECT SEGMENT_NAME, STATUS, TABLESPACE_NAME FROM DBA_ROLLBACK_SEGS WHERE TABLESPACE_NAME LIKE '%UNDOTBS%';- 重点关注状态为
NEEDS RECOVERY、INVALID或PENDING OFFLINE的非SYSTEM段 - 如果查询报
ORA-00942: table or view does not exist，说明数据库未OPEN或字典不可用，需先用MANUAL模式启动
数据库无法OPEN时，用MANUAL模式绕过Undo自动加载
目标是拿到控制权，不是强行启动服务：
- 从SPFILE生成PFILE：
CREATE PFILE='/tmp/pfile.ora' FROM SPFILE; - 编辑PFILE，注释掉
undo_tablespace，改为：undo_management='MANUAL'和rollback_segments='SYSTEM' - 启动到MOUNT：
STARTUP MOUNT PFILE='/tmp/pfile.ora'; - 离线损坏文件：
ALTER DATABASE DATAFILE '/path/undotbs01.dbf' OFFLINE DROP; - 再OPEN：
ALTER DATABASE OPEN;—— 此时只依赖SYSTEM回滚段，能支撑基础DML
_corrupted_rollback_segments 隐含参数怎么填才有效
这个参数不是“开关”，而是白名单式忽略：Oracle只跳过列表里的段，其余仍校验
- 格式必须严格：
'_SYSSMU1_1234567890$','_SYSSMU2_0987654321$'，单引号包裹、逗号分隔、结尾无逗号 - 段名必须完整匹配（含尾部数字和美元符），可通过
strings system01.dbf | grep _SYSSMU提取，或用BBED查undo$表 - 不能写成
_SYSSMU1或_SYSSMU1$，否则参数不生效，SMON仍尝试加载 - 设完后必须重启：
SHUTDOWN IMMEDIATE→ 修改PFILE →STARTUP PFILE=...
重建Undo表空间时，物理路径和文件名最容易踩的坑
控制文件残留元数据比文件系统残留更致命：
-
CREATE UNDO TABLESPACE UNDOTBS1 DATAFILE '/u01/oradata/undotbs01.dbf' SIZE 100M;很可能报ORA-01119，即使该文件已被OS删除 - 原因：控制文件里还存着旧记录，Oracle认为“同名文件冲突”，而非“文件不存在”
- 解法只有两个：
REUSE（覆盖写）或换全新路径（推荐） - 绝对不要复用原UNDOTBS1名称立即重建——先用
ALTER SYSTEM SET undo_tablespace='UNDOTBS2';切换，再删旧表空间
真正麻烦的从来不是命令敲错，而是误判“已修复”：哪怕OPEN成功、新建Undo可用，只要alert.log里还有 ORA-00604 连带 ORA-01595，就说明SMON仍在后台反复尝试清理损坏段——得回到 DBA_ROLLBACK_SEGS 再扫一遍状态。
