ADOP补丁升级不操作表空间，仅影响应用层；真正需维护的只有PDB内APPS用户的默认永久表空间和TEMP临时表空间。
ADOP补丁升级本身不操作表空间
adop（application database online patching）是oracle e-business suite专用的在线补丁工具，它只负责应用层补丁（如pl/sql、java、xml、配置文件等），**不会创建、修改或删除任何数据库表空间**。它的补丁信息写入位置是appl_top下的临时日志文件（如adpsv<yyyymmddhhmiss>.txt</yyyymmddhhmiss>），成功后才上传到数据库的ad_applied_patches等元数据表中——这些表本身早已存在于system或apps表空间里，无需额外表空间介入。
但补丁执行过程可能间接触发表空间压力
某些补丁包含大量DDL（如重建索引、物化视图刷新、分区扩展）或大量DML（如数据迁移脚本），会生成大量临时段、UNDO、重做日志，进而消耗：
- TEMP表空间（排序、哈希连接、全局临时表）
- UNDOTBS1（或自定义UNDO表空间）
- SYSAUX（AWR快照、Optimizer统计信息历史）
- 应用用户默认表空间（如APPS_DATA）
常见现象包括：ORA-01652: unable to extend temp segment、ORA-30036: unable to extend segment in undo tablespace。这时不是ADOP的问题，而是底层数据库资源不足。
应对建议：
- 补丁前检查TEMP和UNDOTBS剩余空间，必要时扩容：ALTER TEMPORARY TABLESPACE temp ADD TEMPFILE '/path/to/temp02.dbf' SIZE 512M AUTOEXTEND ON;
- 确保APPS用户的默认表空间有足够配额且AUTOEXTEND开启
- 避免在业务高峰时段运行大型driver（尤其是u型补丁）
CDB/PDB环境下需注意容器级隔离
若EBS部署在Oracle 12c多租户架构中（CDB+PDB），ADOP始终在PDB内运行，所有补丁操作仅影响当前PDB。但以下两点容易被忽略：
- TEMP和UNDOTBS表空间必须在该PDB内单独创建并分配，不能复用CDB$ROOT的；否则ADOP会报错或静默失败
- PDB的默认表空间（如USERS）若未显式设置，会继承CDB$ROOT的默认值，而CDB$ROOT的USERS通常不允许应用对象写入——这会导致补丁中新建对象失败，错误类似：ORA-01950: no privileges on tablespace 'USERS'
验证方式：
- 进入目标PDB执行：SELECT property_name, property_value FROM database_properties WHERE property_name = 'DEFAULT_PERMANENT_TABLESPACE';
- 若返回USERS，应立即切换：ALTER DATABASE DEFAULT TABLESPACE apps_data;
真正需要你动手管理的表空间只有两个
ADOP补丁流程中，你只需提前确认并维护好：
- 当前PDB的应用用户（如APPS）的默认永久表空间（比如APPS_DATA）是否在线、可写、有足够空间和AUTOEXTEND
- 当前PDB的临时表空间（如TEMP）是否已分配且容量充足（建议≥2GB，尤其对含大数据量迁移的补丁）
其他表空间（SYSTEM、SYSAUX、UNDOTBS）由数据库实例自身保障，ADOP不触碰它们的结构，也不依赖其扩容逻辑。补丁失败时先查adop日志里的SQL错误，再顺着错误码反查对应表空间状态——而不是盲目给所有表空间加文件。
