查DBA_USERS的ACCOUNT_STATUS字段可判断Oracle用户是否被锁定，值为LOCKED或LOCKED(TIMED)即不可登录，需DBA权限；注意EXPIRED & LOCKED状态无lock_date但实际已锁，解锁需ALTER USER ... ACCOUNT UNLOCK。
查DBA_USERS里的ACCOUNT_STATUS字段就能知道哪些用户被锁
oracle中用户是否被锁定，最直接的依据就是dba_users视图中的account_status字段。只要值为locked或locked(timed)，就表示该账户当前不可登录。
注意：DBA_USERS需要DBA权限才能查询，普通用户看不到其他用户的锁定状态。执行前确认你有SELECT_CATALOG_ROLE或DBA角色。
常用查询语句：
SELECT username, account_status, lock_date, expiry_date, created
FROM dba_users
WHERE account_status IN ('LOCKED', 'LOCKED(TIMED)')
ORDER BY lock_date DESC;
-
LOCKED：手动执行ALTER USER ... ACCOUNT LOCK导致，无自动解锁机制 -
LOCKED(TIMED)：因连续登录失败（如密码错误）触发资源限制策略，由FAILED_LOGIN_ATTEMPTS参数控制 -
lock_date为空不等于没锁——某些情况下（如密码过期后首次登录失败），状态已变但lock_date未更新，以account_status为准
为什么ACCOUNT_STATUS显示EXPIRED & LOCKED却查不到lock_date
这是常见误解点：账户可能因密码过期（EXPIRED）+ 随后一次错误登录（触发锁定）变成复合状态EXPIRED & LOCKED，但Oracle不会单独记录这次“逻辑锁定”的时间，所以lock_date仍为NULL。
这种状态下用户无法登录，且不能仅靠重置密码解决——必须先解锁：
ALTER USER scott ACCOUNT UNLOCK;
- 解锁操作本身不重置密码，也不影响
expiry_date - 如果还想改密码，需额外执行
ALTER USER scott IDENTIFIED BY newpass - 检查对应profile的
PASSWORD_LOCK_TIME参数，确认是否设置了自动解锁时长（单位为天）
用DBA_USERS查锁定用户时容易漏掉的三类情况
只查ACCOUNT_STATUS还不够，有些“看似可用”的用户实际已被间接禁用：
-
ACCOUNT_STATUS = 'EXPIRED(GRACE)'：密码已过期但处于宽限期，此时用户仍可登录并修改密码；但如果宽限期内未操作，下次登录就会变成EXPIRED & LOCKED -
PROFILE被设为DEFAULT但该profile中FAILED_LOGIN_ATTEMPTS为0：意味着任何失败登录都会立即锁账号（而不是默认的10次） - 用户被
GRANT了CREATE SESSION权限，但其所在profile中RESOURCE_LIMIT为FALSE：此时即使配置了FAILED_LOGIN_ATTEMPTS，锁定机制也不会生效
建议连带检查profile设置：
SELECT u.username, u.account_status, u.profile, p.failed_login_attempts, p.password_lock_time FROM dba_users u, dba_profiles p WHERE u.profile = p.profile AND p.resource_name = 'FAILED_LOGIN_ATTEMPTS' AND u.account_status LIKE '%LOCKED%';
批量解锁脚本要避开USERNAME大小写和特殊字符陷阱
Oracle默认大写用户名，但若建用户时用了双引号（如"MyUser"），则USERNAME字段会保留大小写和引号，直接拼SQL会报错。
安全做法是用DUMP()函数预检：
SELECT username, DUMP(username) FROM dba_users WHERE account_status LIKE '%LOCKED%';
- 输出类似
Typ=1 Len=6: 77,121,85,115,101,114说明是纯ASCII大写，可放心拼接 - 若含非标准字符码（如34=双引号），就得用动态SQL加转义，或手动处理
- 生产环境慎用
EXECUTE IMMEDIATE批量解锁，建议先导出待解锁列表，人工核对后再执行
真正麻烦的不是锁住多少个用户，而是锁住之后没人知道是谁在什么时候因为什么规则被锁——DBA_USERS不记录原因，得结合DBA_AUDIT_TRAIL或V$SESSION_CONNECT_INFO回溯。
