oracle云自治数据库（adb）不支持表空间管理，因其采用全托管共享存储池，逻辑与物理层解耦；自动扩展体现在cpu/内存、存储容量和i/o吞吐三个维度，受服务等级硬上限约束。
Oracle云自治数据库（ADB）不提供传统意义上的“表空间自动扩展”功能——它根本就没有用户可管理的表空间概念。 你不能执行 ALTER DATABASE DATAFILE、ADD DATAFILE 或查询 dba_data_files，因为底层存储由 Oracle 完全托管，逻辑层与物理层彻底解耦。
为什么在ADB里找不到表空间相关操作
自治数据库屏蔽了所有与文件、数据文件、表空间、控制文件相关的 DDL 和视图。比如：
-
SELECT * FROM dba_data_files→ 报错 ORA-00942: table or view does not exist -
ALTER TABLESPACE users ADD DATAFILE ...→ 报错 ORA-01031: insufficient privileges（实际是语法不被支持） -
V$CONTROLFILE、V$DATAFILE等动态性能视图均不可见
这不是权限问题，而是架构设计：ADB 使用统一的、按需分配的共享存储池（基于 Oracle Exadata Cloud@Customer 或 OCI Block Volume），容量随服务级别（TP/SP）和使用量弹性伸缩，无需人工干预存储结构。
ADB真正的“自动扩展”体现在哪几个地方
它的自动扩展不是针对“表空间”，而是围绕三个可度量维度实时触发：
- 计算资源（CPU/内存）：当 SQL 并发或执行时间持续超过阈值，ADB 自动增加 OCPU 数（上限由你选的服务等级决定）
-
存储容量：当数据库总用量（包括表、索引、UNDO、临时段、备份保留）接近当前配额时，系统自动扩容，上限默认为所购服务的
MAX_STORAGE_IN_GB值（如 TP 版默认 20 TB） -
I/O 吞吐：基于请求模式自动调整 IOPS，无需设置
NEXT或MAXSIZE
这些动作完全后台完成，无停机、无 DDL、无日志输出给用户。你唯一能观察到的是监控图表中 “Storage Used” 曲线缓慢上升，以及偶尔出现的 “Scale Up” 事件标记。
你需要主动关注的替代监控点
既然不能管表空间，就得盯住真正影响业务的指标：
- 在 OCI 控制台 ADB 详情页 → Metrics 标签页，重点关注：
StorageUsedInGB、CpuUtilizationPercent、ActiveSessions - 当
StorageUsedInGB持续 > 90% 当前配额，且增长趋势未收敛 → 不是“该加数据文件”，而是该考虑升级服务等级（如从 1 TB 升到 5 TB 配额） - 用
SELECT * FROM v$database可查DB_NAME和CREATED，但v$tablespace和v$datafile不存在 - 误以为“ORA-01653 无法扩展表”会在 ADB 出现？不会。它会提前扩容或直接拒绝写入（返回 ORA-12953，提示超出存储配额）
真正容易被忽略的一点：ADB 的“自动”不等于“无限”。它严格受你创建实例时选定的 MAX_STORAGE_IN_GB 和 OCPU_COUNT 约束。一旦达到硬上限，后续 INSERT/CREATE 就会失败——这时候不是调优 SQL，而是必须进 OCI 控制台手动升级配置。
