备库TEMP表空间不能直接SHRINK SPACE，因物理备库只读架构限制，执行会报ORA-16000或ORA-10635；唯一安全方式是停库后删除tempfile并重启，由Oracle自动重建。
备库 TEMP 表空间不能直接 SHRINK SPACE？先确认是否真能执行
Oracle Data Guard 备库（standby）默认是只读或应用日志状态，ALTER TABLESPACE ... SHRINK SPACE 在物理备库上**不被允许**——它会直接报 ORA-16000: database open for read-only access 或 ORA-10635: Invalid segment or tablespace type。这不是权限或版本问题，而是架构限制：物理备库不允许修改表空间结构。只有主库才能执行该命令；逻辑备库虽可写，但 TEMP 表空间行为与主库同步，一般也不建议在逻辑备库上单独收缩。
备库 TEMP 膨胀的真正原因不是“用了多少”，而是“没清理”
物理备库的 TEMP 表空间膨胀，几乎总是因为主库上发生过大量排序（如大报表、索引重建、GROUP BY），这些操作产生的临时段在传输到备库后，**不会随主库释放而自动清理**。备库的 SMON 不主动回收 TEMP 段，尤其当备库处于 MOUNT 状态（常见于最大保护/最高可用模式）时，v$sort_usage 可能为空，但 v$temp_extent_pool.bytes_cached 仍显示高位——说明缓存区未刷新。
- 查真实占用：
SELECT * FROM v$temp_extent_pool;—— 关键看bytes_cached，不是bytes_used - 查是否有残留排序会话（极少见，但可能）：
SELECT * FROM v$sort_usage@standby;（需配置 DB Link 或在备库本地查，若 OPEN READ ONLY 则可能无结果） - 确认主库是否已收缩：如果主库已执行
ALTER TABLESPACE temp SHRINK SPACE，下次归档应用后，备库 TEMP 文件大小**不会自动变小**——文件物理尺寸不变，只是内部空闲区增多
唯一安全有效的收缩方式：重启备库并强制重建 TEMP
物理备库上无法在线 shrink，又不能 kill 会话（无活跃会话），最可靠的做法是：停库 → 删除 TEMP 文件 → 启动时由 Oracle 自动重建。这个过程不丢失数据，不影响 DG 同步。
- 步骤顺序必须严格：
SHUTDOWN IMMEDIATE→ 手动删除或重命名原temp01.dbf文件 →STARTUP MOUNT→RECOVER MANAGED STANDBY DATABASE DISCONNECT - 启动后 Oracle 会自动创建新 TEMP 文件，默认大小为
DEFAULT_TEMP_TABLESPACE定义的初始值（通常是 100M 或由db_create_file_dest决定），不是继承旧文件大小 - 注意：不要在
OPEN READ ONLY状态下删文件，否则实例会报错；必须在 MOUNT 状态操作 - 若使用 ASM，用
ASMCMD rm替代 OS 命令，避免权限问题
为什么 ALTER DATABASE TEMPFILE RESIZE 在备库也失败？
即使你尝试绕过 SHRINK，改用 ALTER DATABASE TEMPFILE ... RESIZE，也会遇到 ORA-03297 或直接报 ORA-16000。前者是因为备库的 TEMP 文件末尾存在未释放的已分配 extent（主库未触发清理）；后者是权限模型阻止任何 DDL 修改物理结构。二者叠加，导致 resize 本质上不可行。
别试 KEEP 子句、别试 coalesce、别依赖 ALTER TABLESPACE temp COALESCE —— 这些对 TEMP 表空间无效，且在备库上多数会报错。真正的瓶颈不在命令语法，而在 DG 架构对临时段生命周期的“只复制、不管理”设计。
