oracle 11g 中创建用户必须显式指定自定义 profile，避免继承无限制的 default；create user 需包含 profile 子句且 profile 必须预先存在；密码含特殊字符须用双引号；profile 参数分 password 和 resource 两类，单位与生效时机各异，alter profile 不影响已有会话。
CREATE USER 和 ALTER USER ... PROFILE 是 Oracle 11g 中创建用户并绑定策略模板的核心操作。默认情况下，新用户会自动关联 DEFAULT Profile，但该 Profile 几乎不限制资源、密码策略也极宽松——生产环境必须显式创建并分配自定义 Profile。
用 CREATE USER 指定初始 Profile（避免默认陷阱）
很多人在 CREATE USER 时漏掉 PROFILE 子句，结果用户一建好就继承了无限制的 DEFAULT，后续再改 Profile 不影响已存在的会话行为，容易误判策略生效状态。
正确做法是创建时直接指定：
CREATE USER app_user IDENTIFIED BY "MyP@ssw0rd123" DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp PROFILE app_profile;
-
app_profile必须已存在；若不存在，语句会报错ORA-01917: user or role 'APP_PROFILE' does not exist - 不写
PROFILE子句 = 自动使用DEFAULT，哪怕你后面ALTER USER改了，当前连接仍按旧 Profile 运行，直到重新登录 - 密码中含特殊字符必须用双引号包裹，否则可能解析失败
CREATE PROFILE 时必须区分 PASSWORD vs RESOURCE 参数
Oracle 11g 的 Profile 分两类参数：密码策略（PASSWORD_*）和资源限制（SESSIONS_PER_USER 等），混用或设为 UNLIMITED 可能引发意外行为。
例如，以下配置看似“宽松”，实则危险：
CREATE PROFILE app_profile LIMIT SESSIONS_PER_USER 5 CPU_PER_CALL 1000 IDLE_TIME 30 PASSWORD_LIFE_TIME 90 PASSWORD_REUSE_TIME UNLIMITED;
-
PASSWORD_REUSE_TIME UNLIMITED允许无限次重用旧密码，违背安全基线；应设为具体天数（如365）或DEFAULT -
IDLE_TIME 30单位是分钟，不是秒；空闲超时后会话被强制断开，应用若没做重连逻辑就会报ORA-03113: end-of-file on communication channel -
CPU_PER_CALL 1000单位是“百分之一秒”（即 10 秒），不是毫秒；设太小会导致正常 SQL 被中断，报ORA-02393: exceeded call limit on CPU usage
ALTER PROFILE 后需注意会话不立即生效
修改 Profile 参数后，已有连接不会实时响应变更。比如把 IDLE_TIME 从 30 改成 15，已登录的会话仍按原值计时，直到下次新建连接才生效。
验证是否生效，不能只查 DBA_PROFILES，还要确认用户当前会话实际加载的 Profile：
SELECT profile FROM dba_users WHERE username = 'APP_USER';
再查该 Profile 当前生效的参数值：
SELECT resource_name, limit FROM dba_profiles WHERE profile = 'APP_PROFILE' AND resource_type = 'PASSWORD';
-
resource_type = 'PASSWORD'和'RESOURCE'必须分开查，因为同一 Profile 下两类参数存储方式不同 - 如果用户是通过
GRANT CONNECT获得权限，而CONNECT角色本身绑定了另一个 Profile，则以角色 Profile 为准（11g 中角色 Profile 优先级高于用户 Profile） - 修改
PASSWORD_VERIFY_FUNCTION后，仅对后续密码修改生效，不影响当前密码强度
DEFAULT Profile 不建议直接修改
直接 ALTER PROFILE DEFAULT ... 看似省事，但风险极高：所有未显式指定 Profile 的用户（包括未来新建的、甚至某些 Oracle 内部维护账户）都会受影响。一次误操作可能导致大量连接被限、密码策略突变、甚至监听进程异常。
稳妥做法是：
- 新建专用 Profile（如
prod_app_profile），严格测试后再分配给业务用户 - 保留
DEFAULT不动，仅用于临时调试或开发环境 - 定期检查哪些用户还在用
DEFAULT：SELECT username FROM dba_users WHERE profile = 'DEFAULT';，逐个迁移
Profile 的真正难点不在语法，而在参数单位、生效时机、作用域优先级这三者的交叉影响——漏看任意一点，都可能让策略形同虚设。
