ora-00093报错时需确保pga_aggregate_limit值在实例实际允许区间内（如报错提示“between 30000m and 100000g”），最低不低于2gb，且不超过物理内存减sga后的约120%；同时pga_aggregate_target不得超过其50%，rac或多租户需逐容器设置并验证v$pgastat和alert.log。
直接改，不用重启库，但必须注意取值范围和与 pga_aggregate_target 的比例关系。
ORA-00093 报错时怎么设才不越界
执行 ALTER SYSTEM SET pga_aggregate_limit = 8G SCOPE=BOTH 报 ORA-00093，说明你填的值不在允许区间内。Oracle 对该参数有硬性下限（12.1+ 默认最低 2GB）和隐含上限（物理内存减 SGA 后的 120% 左右）。常见错误包括：
- 设成
1G：低于最小值 2048MB，直接报错 - 设成
0：虽语法合法（表示不限），但生产环境严禁使用 - 设得过大（比如
200G）：若物理内存仅 128G 且 SGA 占 64G，系统会拒绝并写警告到 alert log
查当前允许范围最准的方式是看报错信息本身：ORA-00093: pga_aggregate_limit must be between 30000M and 100000G —— 这个“between”后面的两个数字就是你本次实例实际生效的上下限，以它为准。
为什么 pga_aggregate_target 不能随便调高
设完 pga_aggregate_limit 后再调 pga_aggregate_target，容易触发 ORA-00856。因为 Oracle 强制要求：pga_aggregate_target 不得超过 pga_aggregate_limit 的 50%。
通过 `dcc-mcp-cli` 命令行工具控制实时 DCC 主机（Maya、Blender、Houdini、Photoshop、3ds Max 以及自定义的 Studio 工具）。 针对 ClawHub、OpenClaw、Cursor、Claude 和支持 shell 的 Agent 主机：验证网关健康状态、列出已注册的 DCC 实例、搜索工具、检查 Schema、调用工具——全程无需直接编写或发送 MCP 请求。 若系统中未安装 `dcc-mcp-cli`，需先征得用户同意，再从 GitHub
- 如果你刚把
pga_aggregate_limit设为8G，那pga_aggregate_target最大只能设4G - 想设
pga_aggregate_target=6G？先得把pga_aggregate_limit提到至少12G - 这个限制只在动态修改时校验，spfile 里硬编码违规值，启动时才会暴露
RAC 环境下必须同步 CDB 和所有 PDB
在 RAC 或多租户架构中，pga_aggregate_limit 是实例级参数，但 CDB root 和每个 PDB 都有独立副本。只改 CDB 不等于 PDB 生效。
- 查当前值要分别连 CDB 和各 PDB 执行：
SHOW PARAMETER pga_aggregate_limit - 动态修改需显式指定容器：
ALTER SYSTEM SET pga_aggregate_limit = 10G SCOPE=BOTH CONTAINER=CURRENT（进 PDB 后执行） - 更稳妥的做法是用
CONTAINER=ALL（12.2+ 支持），但注意某些版本不识别，先确认文档版本
改完之后怎么验证真生效了
别只信 SHOW PARAMETER，它只反映参数值，不反映实际内存控制效果。关键看三处：
- 查
v$pgastat：重点关注total PGA allocated和over allocation count。后者大于 0 就说明已触发过杀会话 - 查
v$process：排序看pga_used_mem，找长期占用 >1GB 的进程，结合应用日志判断是否异常 - 翻 alert log：搜索
ORA-04036或PGA limit exceeded，确认是否真有会话被终止
真正难的是预估合理值——它取决于你最大并发批量作业的 PGA 峰值，而不是平均负载。监控窗口至少要看 24 小时以上，尤其覆盖批处理时段。
