必须先启用resource_limit才能让资源限制生效；该参数默认为FALSE，需执行ALTER SYSTEM SET resource_limit=TRUE启用，否则SESSIONS_PER_USER等资源限制均被忽略，而密码类参数始终生效。
必须先启用 resource_limit 才能让资源限制生效
Oracle 的 Profile 对资源（CPU、会话数、空闲时间等）的限制不是开箱即用的。即使你创建了 Profile 并分配给了用户，resource_limit 参数默认是 FALSE，所有资源类限制（如 CPU_PER_SESSION、IDLE_TIME）都会被忽略。
执行以下命令才能真正激活限制：
ALTER SYSTEM SET resource_limit = TRUE;
这个操作需要 ALTER SYSTEM 权限，且影响整个实例。注意：PASSWORD_LIFE_TIME、FAILED_LOGIN_ATTEMPTS 等密码类参数不受该开关控制——它们始终生效。
常见错误现象：用户明明设置了 IDLE_TIME 10，却一直不被断开；查 dba_profiles 也显示配置正确，问题就出在没开 resource_limit。
CREATE PROFILE 时参数写法和 DEFAULT/UNLIMITED 的区别
Profile 创建语句中，每个参数值只能是数字、UNLIMITED 或 DEFAULT，三者含义完全不同：
-
UNLIMITED：对该参数彻底放开，不设上限 -
DEFAULT：不在此 Profile 中定义该参数，运行时回退到DEFAULTProfile 的对应值（不是“不限制”，而是“继承默认配置”） - 数字：明确设定阈值，单位需按文档约定（如
IDLE_TIME是分钟，CPU_PER_CALL是百分之一秒）
例如：
CREATE PROFILE app_user LIMIT SESSIONS_PER_USER 3 CPU_PER_CALL 500 IDLE_TIME 15 FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 1;
这里没写 CONNECT_TIME，它就按 DEFAULT 处理 → 实际取值来自 DEFAULT Profile 中该参数的定义（通常是 UNLIMITED）。如果想显式不限制，得写 CONNECT_TIME UNLIMITED。
分配 Profile 给用户必须用 ALTER USER，不能 CREATE USER 时遗漏
Profile 不是用户创建时的可选“附加项”，而是必须显式绑定的策略容器。两种方式都可行，但容易漏掉关键点：
- 新建用户时直接指定：
CREATE USER app01 IDENTIFIED BY pwd123 PROFILE app_user; - 已有用户补绑：
ALTER USER app01 PROFILE app_user;
注意：DEFAULT Profile 不需要显式分配，所有未指定 Profile 的用户自动归属它。但一旦你执行了 ALTER USER ... PROFILE ...，旧 Profile 就被完全替换——Oracle 不支持一个用户挂多个 Profile。
验证是否生效？查 dba_users：
SELECT username, profile FROM dba_users WHERE username = 'APP01';
修改或删除 Profile 的 cascade 和权限陷阱
Profile 修改用 ALTER PROFILE，语法和创建几乎一致，但要注意：
- 修改后，已分配该 Profile 的用户**立即生效**（无需重连），但当前活跃会话可能仍按旧限制运行，直到下次调用或会话重建
- 删除 Profile 必须加
CASCADE，否则报错ORA-02381: cannot drop profile with users assigned -
DEFAULTProfile 永远不能删，也不建议改——它是所有用户的兜底策略
删除前务必确认：没有用户正在使用它，或已用 ALTER USER ... PROFILE DEFAULT 迁移完毕。否则 DROP PROFILE app_user CASCADE 会强制解除绑定，用户瞬间回到 DEFAULT 行为，可能引发连接数暴增或空闲会话滞留等问题。
Profile 真正的复杂点不在语法，而在资源限制与业务行为的耦合——比如 IDLE_TIME 对长事务、ETL 脚本的影响，CPU_PER_CALL 对报表 SQL 的误杀。上线前必须在测试环境用真实负载验证。
