CDB层无法直接限制单个PDB磁盘空间用量，因Oracle多租户中存储空间不由CDB统一调度，必须通过PDB内表空间配额、文件系统或ASM层控制。
不能在 cdb 级直接限制单个 pdb 的磁盘空间用量——oracle 12c 没有 alter database set max_pdb_size 这类语法，所有“空间限制”必须通过表空间级配额（quota）或文件系统/asm 层控制实现。
为什么 CDB 层没有全局空间限额参数
Oracle 的多租户设计中，CDB 是资源容器，但**存储空间不归 CDB 统一调度**。每个 PDB 拥有独立的表空间集合（除 SYSTEM、SYSAUX 等共享元数据外），而数据文件物理归属操作系统层。CDB 的 ALTER DATABASE 命令无法穿透到 PDB 内部的段分配逻辑。
常见误解是以为设置 DB_CREATE_FILE_DEST 或 PDB_FILE_NAME_CONVERT 就能限大小，其实它们只影响新建数据文件路径，不限制容量。
真正有效的空间约束方式：PDB 内部表空间配额
必须在目标 PDB 中为用户显式授予磁盘配额，这是唯一由 Oracle 内核强制执行的软限制：
- 连接到 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 中建对象不受配额约束 - 临时表空间（
TEMP）无配额机制，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 diskgroup 时，这才是最终防线：
- 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 参数一键封顶。
