Oracle 12c CDB级设置存储参数限制容器数据库空间增长

先说一个明确的结论：在 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 参数就能一键封顶，那根本不现实。