先说一个明确的结论：在 CDB 层面直接限制某个 PDB 的磁盘空间？这个操作在 Oracle 12c 中并不可行。Oracle 12c 没有提供类似 ALTER DATABASE SET MAX_PDB_SIZE 这样的语法。所有所谓的“空间限制”最终都必须落实到表空间层级的配额控制，或者依靠文件系统与 ASM 层面的管理来实现。
在深入具体操作之前，我们先探讨一个更本质的问题：为什么 CDB 层面不提供全局空间限额的参数？
在 Oracle 的多租户架构中，CDB 主要扮演资源容器的角色，但存储空间的分配并非由它统一调度。每个 PDB 拥有自己独立的表空间集合（除了 SYSTEM、SYSAUX 等共享元数据之外），其数据文件在物理层面归属于操作系统。CDB 的 ALTER DATABASE 命令根本无法穿透到 PDB 内部的段分配逻辑中去。
很多人误以为设置 DB_CREATE_FILE_DEST 或 PDB_FILE_NAME_CONVERT 就能控制空间大小，实际上这些参数只影响新建数据文件的路径，对容量毫无限制作用。
那么，真正有效的空间约束手段是什么？答案是 PDB 内部的表空间配额。
这是唯一一个由 Oracle 内核强制执行的软限制，不过前提是你必须在目标 PDB 中为用户显式授予磁盘配额。具体操作如下：
- 连接到 PDB：
ALTER SESSION SET CONTAINER = hrpdb; - 为本地用户设置配额：
ALTER USER app_user QUOTA 500M ON users; - 拒绝无限配额（防止误操作）：
ALTER USER app_user QUOTA 0 ON system; - 查询当前配额：
SELECT username, tablespace_name, bytes/1024/1024 mb FROM dba_ts_quotas WHERE username = 'APP_USER';
这里有一个关键点需要留意：在生产环境中应禁用 QUOTA UNLIMITED。如果用户属于多个表空间，需要逐个进行限制。另外，配额仅对 CREATE TABLE、INSERT /*+ APPEND */ 等触发段扩展的操作生效，不会影响已有数据。
不过，即使设置了配额，仍然存在一些风险行为可能突破预期的空间占用，这也是监控中容易出现的盲区：
- DBA 用户（例如
SYS、SYSTEM）在 PDB 中创建对象不受配额约束。 - 临时表空间没有配额机制，
ORDER BY、HASH JOIN等操作随时可能撑爆temp01.dbf。 - UNDO 表空间的自动扩展不受控制，长事务会导致
undotbs1.dbf持续增长。 - 如果未监控
dba_free_space和v$pdbs中的OPEN_MODE，可能误判 PDB 是否在线，导致空间统计出现滞后。
建议定期运行以下命令来掌握状况：SELECT con_id, name, open_mode FROM v$pdbs; 以及 SELECT tablespace_name, sum(bytes)/1024/1024 mb FROM cdb_free_space GROUP BY tablespace_name;。
说到底，文件系统或 ASM 层面才是真正的硬边界。当 PDB 的数据文件放在独立的目录或 ASM 磁盘组中时，这道防线才能发挥作用：
- Linux 环境下：用
du -sh /u02/oradata/mycdb/hrpdb/定期检查物理目录的大小。 - ASM 环境下：查询
SELECT group_number, name, total_mb, free_mb FROM v$asm_diskgroup;。 - 对关键 PDB，可以单独挂载小容量的 LVM，或者设置
df -h的告警阈值（例如超过 85% 就报警）。
值得警惕的是，PDB$SEED 的数据文件虽然是只读的，但如果它的路径与其他 PDB 共享，扩容操作可能会意外影响到 seed。所以，创建 PDB 时务必使用 FILE_NAME_CONVERT 来隔离路径。
总结一下：配额是数据库层最细粒度的控制手段，但它依赖人工维护，并且不能覆盖所有场景。真正的空间安全来自表空间路径隔离、文件系统监控，以及定期清理归档日志和旧备份。不要指望一个 CDB 参数就能一键封顶，那根本不现实。
