ORA-25153错误本质是临时表空间有逻辑定义但无物理文件，ADG备库中TEMP文件不会自动同步，需在switchover前手动为每个PDB执行ALTER TABLESPACE temp ADD TEMPFILE。
升级后表空间管理最常踩的坑，不是数据丢了，而是备库临时表空间直接不可用——ORA-25153报错一出，只读查询全挂。
ADG环境下临时表空间不会自动同步
物理备库（physical standby）的临时表空间（TEMP）文件不会随主库变更自动创建或删除。即使你在主库执行了ALTER TABLESPACE temp ADD TEMPFILE，备库的dba_temp_files视图里依然为空。
- 这是Oracle官方明确行为，见MOS Doc ID
1514588.1 -
switchover或failover后，新主库若没提前加好临时文件，首次执行ORDER BY、GROUP BY、哈希连接等操作就会触发ORA-25153 - 必须在ADG搭建完成、且每个PDB创建完毕（含
standbys子句）后，手动为每个PDB的temp表空间添加临时文件
示例操作（在备库上以SYS身份执行）：
ALTER TABLESPACE temp ADD TEMPFILE '/u01/oradata/CDB1/PDB1/temp01.dbf' SIZE 100M AUTOEXTEND ON;
SYSTEM和SYSAUX表空间扩容策略失效
19c默认启用AUTOEXTEND，但升级后部分11g遗留表空间可能仍保留MAXSIZE UNLIMITED却未开启AUTOEXTEND，导致空间耗尽时无法自动伸展。
- 检查命令：
SELECT tablespace_name, autoextensible, maxbytes FROM dba_data_files WHERE tablespace_name IN ('SYSTEM','SYSAUX'); - 常见陷阱：11g导出的表空间定义中
AUTOEXTEND被忽略，impdp导入后状态为NO - 升级后务必逐个确认并补开：
ALTER DATABASE DATAFILE '/path/to/system01.dbf' AUTOEXTEND ON MAXSIZE 32G; - 注意：
SYSTEM表空间不支持SHRINK，扩容是唯一安全路径
大文件表空间（BIGFILE）在19c中隐式限制变化
11g中BIGFILE表空间单文件上限为128TB，19c虽仍支持，但ASM磁盘组兼容性版本低于12.1时，实际可创建的最大文件大小会受限于ASM块大小（如4MB块 → 单文件上限≈2PB，但需预留元数据空间）。
- 升级后若需新建
BIGFILE表空间，先查ASM兼容性：SELECT name, compatibility, database_compatibility FROM v$asm_diskgroup; - 若
compatibility < '12.1'，避免直接指定MAXSIZE UNLIMITED，改用显式MAXSIZE 16T等可控值 -
DBA_TABLESPACES中SEGMENT_SPACE_MANAGEMENT字段在19c对BIGFILE仍强制为AUTO，无法改为MANUAL，硬改会报ORA-12917
UNDO表空间切换后残留11g参数风险
19c默认使用AUTO管理模式的UNDO表空间，但升级后若沿用11g的UNDO_MANAGEMENT=MANUAL配置或未清理旧ROLLBACK段，会导致ORA-01552非系统表空间无法使用回滚段。
- 升级后必须确认：
SHOW PARAMETER undo_management返回AUTO，且SELECT segment_name, status FROM dba_rollback_segs;仅剩SYSTEM段 - 若存在非
SYSTEM的OFFLINE回滚段，用DROP ROLLBACK SEGMENT清理（仅限MANUAL模式下） - 19c中
UNDO_RETENTION建议设为至少15分钟，否则闪回查询或ORA-01555快照过旧错误概率陡增
真正容易被忽略的是：临时表空间问题只在备库暴露，而你往往等到割接演练才第一次执行SELECT /*+ PARALLEL */ COUNT(*) FROM big_table GROUP BY id;——那一刻ORA-25153弹出来，已经没有时间再连备库补文件了。
