ALTER USER … PROFILE 只能切换用户到已有Profile，不能直接修改Profile参数；必须用ALTER PROFILE更新Profile定义，再通过ALTER USER切换用户，新策略仅对后续登录或资源检查生效。
ALTER USER … PROFILE 语法是否真能修改用户配置？
直接使用 alter user 命令来修改 profile 的具体参数——比如密码过期天数或者失败登录次数限制——是行不通的。这个命令的核心功能，其实只是把用户从一个 profile「换到」另一个已经存在的 profile 上。至于 profile 本身的定义，无论是创建还是修改，都得交给专门的 create profile 或 alter profile 语句来处理。
一个常见的误解是，试图执行类似 ALTER USER scott PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 3 这样的语句。结果呢？通常会收到一个 ORA-00922: missing or invalid option 错误。原因很简单：ALTER USER 这个语法根本不支持 LIMIT 子句。
- 记住一点：
ALTER USER在 profile 方面，只认PROFILE profile_name这一种写法。 - 真想调整密码策略或资源限制？那必须先用
ALTER PROFILE去更新 profile 的定义本身。 - 用户切换了 profile 之后，新的策略并不会立刻生效。它只会在用户下次登录，或者系统进行资源检查时才会被应用，当前正在进行的会话是不会被实时刷新的。
如何安全地更新用户的 Profile 策略？
安全更新的正确姿势是分两步走：首先，调整目标 profile 的参数；然后，再根据需要决定是否将用户显式地绑定到这个更新后的 profile 上。这里有个细节值得注意：即使是默认的 DEFAULT profile 也是可以被修改的，而且一旦修改，所有没有指定特定 profile 的用户都会受到影响。
举个例子，如果想将密码锁定策略从允许失败10次改为5次，正确的命令应该是：
ALTER PROFILE default LIMIT FAILED_LOGIN_ATTEMPTS 5;
假设用户 app_user 当前使用的是 app_profile，你希望它立刻遵循新的策略。那么，你只需要确保 app_profile 已经被更新过了；如果这个用户本来就用的 DEFAULT profile，那么上面那条修改 DEFAULT 的命令就已经覆盖到了。
- 修改 profile 的定义，不会影响已经登录的会话。新规则只对后续的登录尝试或资源申请起作用。
- 想查看当前 profile 的具体参数值？可以用
SELECT * FROM dba_profiles WHERE profile = 'DEFAULT';来查询。 - 如果尝试修改一个不存在的 profile，
ALTER PROFILE会报错ORA-01974: invalid profile name。
ALTER USER … PROFILE 执行后为什么没生效？
明明执行成功了，为什么新策略感觉没生效？最常见的原因有两个：一是用户的当前会话仍然保留着旧 profile 的上下文；二是数据库还没有触发相关的策略检查点。具体来说，profile 里的密码类限制（比如 PASSWORD_LOCK_TIME）只在登录验证那一刻检查；而资源类限制（比如 CPU_PER_SESSION）则是在会话启动或语句执行过程中动态评估的。
- 已经登录的用户，不会因为 profile 切换而被立刻踢下线，其失败登录计数器也不会被重置。
- 可以通过
SELECT profile FROM dba_users WHERE username = 'SCOTT';来确认数据库的元数据已经更新。 - 如果刚刚修改了
PASSWORD_LIFE_TIME（密码生命周期），需要等到用户下次修改密码，或者原密码到期时，才会触发强制重置。 - 部分参数，例如
IDLE_TIME（空闲时间），其生效依赖于 SQL*Net 的心跳检测机制。如果网络层不支持，可能就无法触发预期的连接断开。
哪些 Profile 参数改了要特别小心？
有些参数组合起来，一不小心就可能“锁死”账户。FAILED_LOGIN_ATTEMPTS（失败登录尝试次数）和 PASSWORD_LOCK_TIME（密码锁定时间）就是一对典型。如果把 PASSWORD_LOCK_TIME 设为 UNLIMITED（无限期），而用户输错密码又达到了上限，那么这个账户就会被永久锁定，必须由管理员手动执行 ALTER USER ... ACCOUNT UNLOCK 才能解封。
PASSWORD_REUSE_TIME（密码可重用时间）和PASSWORD_REUSE_MAX（密码可重用最大次数）这两个参数需要配合使用。只有同时设置为UNLIMITED，才允许重复使用旧密码；只设置其中一个，限制是无效的。CONNECT_TIME（连接时间）和IDLE_TIME（空闲时间）这类参数，对于使用连接池的应用可能不太友好，容易导致“连接突然中断”却又没有明确错误信息的情况。- 在修改
DEFAULTprofile 之前，建议先运行SELECT username, profile FROM dba_users WHERE profile = 'DEFAULT';查询一下，看看有哪些关键账户会受到影响，避免误伤。
最后要提醒的是，profile 的实际效果高度依赖于你的 Oracle 数据库版本以及一些初始化参数（比如 resource_limit 是否设为 TRUE）。千万别只看语句执行成功，就以为策略已经完美落地了。
