主库表空间扩容是否同步至备库取决于表空间类型和数据库版本；仅DATAFILE类永久表空间在standby_file_management=auto时自动同步，TEMP和UNDO表空间需手动操作，23ai起TEMP支持自动同步。
哪些表空间扩容会自动同步到备库
只有 DATAFILE 类型的扩容（即永久表空间）在 standby_file_management=auto 时才会被 Redo Apply 自动传播到物理备库。这包括：
ALTER DATABASE DATAFILE '/path/to/file.dbf' RESIZE 2GALTER TABLESPACE users ADD DATAFILE '/path/to/new.dbf' SIZE 1G
但以下操作不会同步，必须手动在备库执行：
-
ALTER TABLESPACE temp ADD TEMPFILE '/path/to/temp02.dbf' SIZE 1G（临时表空间，11g–19c 均不传播） -
ALTER TABLESPACE undotbs1 ADD DATAFILE ...（UNDO 表空间新增文件，虽属永久类型，但 Oracle 明确禁止在备库上自动创建 UNDO 文件）
关键判断依据：查 v$database.standby_file_management，值为 AUTO 才可能触发自动同步；若为 MANUAL，所有文件变更都需人工干预。
为什么 temp 表空间扩容在 19c 及以前不传到备库
因为 ALTER TABLESPACE TEMP ADD TEMPFILE 不生成重做记录（Redo），它只更新控制文件和数据字典。而物理备库依赖 Redo Apply 机制，没有 Redo 就等于没发生过这个操作。
典型现象是：
- 主库查
dba_temp_files有 2 个文件，备库只有 1 个 - 报表业务在备库执行大排序时报
ORA-01652: unable to extend temp segment - 备库
v$tempfile中对应新 tempfile 的status是OFFLINE或根本不存在该行
解决方式不是“等同步”，而是登录备库，用 ALTER TABLESPACE temp ADD TEMPFILE 手动加——路径、大小、REUSE 选项都要与主库一致，否则后续切换角色时可能报错。
23ai/26ai 开始，temp 表空间扩容终于能自动同步了
Oracle 在 23ai 引入了 AUTOMATIC TEMP FILE CREATION ON THE STANDBY 特性，26ai 继承并默认启用。只要满足：
- 主库执行了
ALTER TABLESPACE temp ADD TEMPFILE - 备库
standby_file_management = AUTO - 备库处于
READ ONLY WITH APPLY状态（非 MOUNT）
那么新 tempfile 会随 Redo 流被解析，并在备库自动创建物理文件。你可以在备库查 v$managed_standby，看到类型为 TEMPFILE 的条目；几秒内 v$tempfile 就会出现对应记录，状态为 ONLINE。
注意：这个特性仅适用于物理备库，逻辑备库仍不支持 temp file 同步；且不回溯旧版本——19c 主库发来的 Redo，在 26ai 备库上也不会补同步历史缺失的 tempfile。
执行前必须验证的三件事
别急着敲 ALTER，先确认：
- 主库
SELECT value FROM v$parameter WHERE name = 'standby_file_management'返回AUTO（否则扩容不传播） - 备库当前
open_mode是READ ONLY WITH APPLY，不是MOUNT（MOUNT 状态下即使参数正确，tempfile 也不会自动创建） - 备库对应路径有足够磁盘空间，且 Oracle 用户对该路径有读写权限（自动同步失败时不会报错，只会卡在
OFFLINE状态，需查alert.log）
最容易被忽略的是第三点：很多 DBA 扩容成功后以为万事大吉，结果某天主库切备库，新备库因 tempfile 路径不可写直接无法 OPEN —— 因为那个路径在原主库存在，但在新角色下成了“备库路径”，权限或挂载点早已不同。
