存储过程不能动态修改PDB的STORAGE(MAXSIZE)、PGA_AGGREGATE_TARGET等运行时参数，仅可封装资源检查逻辑；真正修改需ALTER SYSTEM切换容器执行，或通过DBMS_SCHEDULER作业/外部脚本实现。
存储过程不能直接管理CDB/PDB资源配额
oracle 19c 中的存储过程（如 dbms_resource_manager 相关包）可以配置资源计划，但**不能动态修改 pdb 的 storage(maxsize)、pga_aggregate_target 或 sga_target 等运行时参数**。这些参数必须通过 alter system 或 ddl 在特定容器上下文中执行，而存储过程无法跨容器切换 container 上下文并生效。
用存储过程封装资源检查逻辑是可行的
你可以写一个存储过程，在当前容器内查询资源使用情况，并按阈值触发告警或记录日志。这类操作安全、常用，且不违反 Oracle 容器隔离机制：
-
SELECT类视图（如V$RSRC_PDB_METRIC、CDB_TABLESPACES、CDB_DATA_FILES）可在 CDB$ROOT 中跨 PDB 查询，但需注意权限和容器可见性 - 存储过程里调用
DBMS_OUTPUT.PUT_LINE或写入自定义日志表，适合做巡检脚本 - 若需判断某个 PDB 是否接近
STORAGE(MAXSIZE)上限，得先查CDB_PDBS.STORAGE_MAX_SIZE和该 PDB 内DBA_SEGMENTS总大小，再比对——这个逻辑可封装进存储过程
真正要改资源配额，必须手动切容器再执行 ALTER
比如想把 salespdb 的 PGA 上限设为 800MB，以下操作不可被封装进普通存储过程自动完成：
ALTER SESSION SET CONTAINER = salespdb; ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 800M SCOPE=BOTH;
原因很实在：
-
ALTER SESSION SET CONTAINER是会话级命令，存储过程中执行后只在该 PL/SQL 单元内临时生效，退出即失效 -
ALTER SYSTEM在存储过程中执行时，作用范围仍是调用者的当前容器（通常是 CDB$ROOT），不会自动跳到目标 PDB - 没有系统内置函数能“远程”向指定 PDB 发送资源配置指令
替代方案：用调度作业 + 动态 SQL 绕过限制
如果真需要自动化调整，可行但需谨慎的做法是：
- 在 CDB$ROOT 创建一个存储过程，拼接并执行动态 SQL，例如：
EXECUTE IMMEDIATE 'ALTER SESSION SET CONTAINER = salespdb'——但这行不通，因为会话上下文无法穿透 PL/SQL 执行边界 - 更可靠的方式是：用
DBMS_SCHEDULER创建一个作业，其job_action是一条完整 shell 命令或 SQL*Plus 脚本，显式连接到目标 PDB 后执行ALTER SYSTEM - 或者用外部脚本（如 Python + cx_Oracle）连 CDB，逐个切换容器并提交变更——这比硬塞进存储过程更可控、更易调试
真正容易被忽略的是：资源参数修改是否生效，不仅取决于语句执行成功，还依赖 PDB 当前 OPEN MODE（必须是 READ WRITE）、是否启用 Resource Manager plan，以及 SCOPE 设置（BOTH 才写 SPFILE）。这些状态不检查，光跑存储过程毫无意义。
