不能硬重启，必须先绕过损坏的UNDO表空间让实例打开再重建；否则反复报ORA-01157、ORA-00600[4194]或[4193]，实例被SMON/PMON中止。
直接结论：不能硬重启，必须先绕过损坏的UNDO表空间，让实例能打开，再重建它。否则反复报 ORA-01157、ORA-00600[4194] 或 ORA-00600[4193]，实例会立刻被SMON或PMON中止。
启动时报 ORA-01157 / ORA-01110，数据文件找不到或锁定失败
这是最常见现象，说明UNDO数据文件物理丢失（如误删）、权限异常或磁盘离线。Oracle在MOUNT阶段就尝试加载所有数据文件，UNDO文件一不可用就卡住。
- 不要执行
startup force或反复shutdown abort—— 这会让事务状态更混乱，加剧ORA-00600[4193]出现概率 - 立刻检查
alert.log末尾，确认最后 shutdown 是否 clean（含Shutting down instance (immediate)）；若上次是abort或崩溃，不能走“offline drop”捷径 - 如果确认是 clean shutdown，可用
alter database datafile <n> offline drop;</n>跳过该文件（<n></n>是v$datafile中对应 UNDO 文件的file#），但仅限 MOUNT 状态下执行 - 注意：
offline drop后必须立刻切换到 MANUAL 模式，否则 OPEN 时仍会校验 UNDO 表空间结构
ORA-00600[4194] 或 [4193]：UNDO 与 REDO 序列不一致
这类错误本质是事务回滚信息损坏，常见于断电、强制关机后重启，或 UNDO 文件被部分覆盖。报错参数中第二、三值（如 [19], [23]）指向具体损坏的 undo segment 编号。
- 若数据库能短暂打开（比如几秒后被 SMON 终止），立即查
v$rollname和v$rollstat，定位异常 segment 名称（如_SYSSMU10_2490256178$） - 无法打开时，需在 PFILE/SPFILE 中加入隐含参数屏蔽损坏段：
._CORRUPTED_ROLLBACK_SEGMENTS=(...)，括号内填日志里报出的 segment 全名（多个用逗号分隔） - 该参数只在启动初期生效，用于跳过恢复阶段对损坏段的扫描；不是长期方案，必须后续重建 UNDO
- 别漏掉
undo_management=MANUAL配合使用——否则 Oracle 仍试图加载 AUTO 模式下的 UNDO 表空间，导致参数无效
重建 UNDO 表空间前必须设为 MANUAL 模式
很多人卡在这步：直接 create undo tablespace 报 ORA-32001（要求 SPFILE）或 ORA-01219（数据库未 open），其实是因为没切断 AUTO 模式对原 UNDO 的依赖。
- 必须先用 PFILE 启动（
startup pfile='/path/to/init.ora'），并在其中明确设置：undo_management='MANUAL'和undo_tablespace='SYSTEM' - 此时 Oracle 会退回到 SYSTEM 表空间里的系统回滚段工作（性能差但能撑住基本 DML），为重建争取窗口
- OPEN 后执行：
create undo tablespace undotbs2 datafile '/path/undotbs2.dbf' size 500M autoextend on next 100M maxsize 4G; - 再改回 AUTO 模式：编辑 PFILE，把
undo_management改成AUTO，undo_tablespace指向新建的UNDOTBS2，然后shutdown immediate+startup pfile=...
重建后仍报 ORA-30036：UNDO 表空间物理空间未释放
新建的 UNDO 表空间看似空闲，但查询 DBA_TABLESPACE_USAGE_METRICS 发现 used_pct 仍为 100%，DML 持续报 ORA-30036。
- 这不是空间不足，而是有长事务未提交，占着旧 UNDO 段不放——即使换了新表空间，老事务的回滚信息仍绑定在原结构上
- 查
v$transaction+v$session，重点看used_ublk > 5000且start_time超 15 分钟的会话，alter system kill session '<sid>,<serial>' immediate;</serial></sid>强制清理 - 若 kill 不掉（如会话处于 “KILLED” 状态但未退出），需等其自然结束或重启实例（此时确保已用新 UNDO 表空间启动）
- 扩容不能解决根本问题：
autoextend on只防物理耗尽，不释放被长事务锁死的逻辑空间
真正棘手的点不在重建命令本身，而在于判断“上次 shutdown 是否 clean”和“哪些 undo segment 已损坏”。这两个信息全靠 alert.log 和 trace 文件（如 SMON.trc）里零散的线索拼凑，漏看一行红色报错，后续步骤就全错。
