DBA_USERS_WITH_DEFPWD 是 Oracle 11g+ 识别默认密码账号的最直接方式，仅用于查询（如 SELECT username FROM dba_users_with_defpwd），不具锁定功能；真正加固需配合 ALTER USER 修改密码或 ACCOUNT LOCK，且 SYS/SYSTEM 等关键账户不可随意锁定。
dba_users_with_defpwd 视图是 oracle 11g 及以后版本中识别默认密码账号的最直接方式，但仅靠它不能“关闭”账号——它只告诉你哪些账号仍在用默认口令，真正要禁用或加固，得结合 alter user ... account lock 和密码重置。
查默认密码账号：只用 DBA_USERS_WITH_DEFPWD 就够了
这个视图专为此设计，不依赖密码哈希比对，也不需要你记住一堆硬编码值：SELECT username FROM dba_users_with_defpwd;
结果里出现的用户名（比如 SCOTT、CTXSYS、OUTLN），说明它们当前仍使用安装时的默认口令。注意：DBA_USERS_WITH_DEFPWD 在 Oracle 11g 才引入，10g 或更早版本必须用密码哈希比对（见下一条）。
Oracle 10g 及更早版本：靠密码哈希值匹配判断
老版本没 DBA_USERS_WITH_DEFPWD，得手动比对 PASSWORD 字段是否等于已知默认哈希值：
- 查询语句需显式列出常见哈希（如 'F894844C3D787341' 对应 scott/tiger）
- 常见坑：Oracle 12c 起默认启用密码大写校验，且部分版本（如 11.2.0.4+）对 SYS 用户的密码哈希做了特殊处理，直接查 PASSWORD 可能为空或无效
- 实操建议：
- 优先升级到 11g+，用
DBA_USERS_WITH_DEFPWD省事又准确 - 若必须在老环境操作，把官方文档里的哈希列表（如
'E066D214D5421CCC'对应dbsnmp/dbsnmp）复制进WHERE password IN (...) - 别漏掉
SYS和SYSTEM：它们的默认哈希是'D4C5016086B2DC6A'（SYS）和'5638228DAF52805F'（SYSTEM），但 12c+ 中这些字段可能为NULL，此时只能靠行为判断（如能否用change_on_install登录）
锁定账号 ≠ 删除账号，优先改密再锁
直接 ALTER USER xxx ACCOUNT LOCK 虽能阻止登录，但很多内置账号（如 DBSNMP、OLAPSYS）被其他组件依赖，锁死可能导致监控或分析服务异常。
更稳妥的做法是两步走：
- 先重置密码：ALTER USER scott IDENTIFIED BY "NewStrongPass123!";
- 再锁定（可选）：ALTER USER scott ACCOUNT LOCK;
特别注意：
-
SYS和SYSTEM必须保留可用，至少留一个能以SYSDBA登录；锁它们前确认有其他 DBA 账号可用 -
SCOTT这类示例账号，若业务不用，建议先改密再锁；若完全不用，可考虑DROP USER scott CASCADE;（但某些 OEM 组件可能隐式依赖） -
CTXSYS、MDSYS等 Oracle Text / Spatial 组件用户，改密即可，不要锁，否则相关功能失效
自动化检查脚本里容易忽略的权限和上下文
写脚本批量处理时，常踩两个坑：
- 脚本必须以 SYSDBA 身份连接，普通 DBA 角色查不到 DBA_USERS_WITH_DEFPWD
- ALTER USER 语句在 PL/SQL 块里执行时，不能直接拼接变量名，要用 EXECUTE IMMEDIATE：BEGIN FOR r IN (SELECT username FROM dba_users_with_defpwd) LOOP EXECUTE IMMEDIATE 'ALTER USER ' || r.username || ' IDENTIFIED BY "TempP@ss2026"'; END LOOP; END;
- 更关键的是：脚本运行期间，如果某个用户正在被应用连接（比如 DBSNMP 正上报指标），ALTER USER 会成功，但下次连接仍可能因旧密码缓存失败——得配合应用侧重启或刷新连接池
真正麻烦的不是找出默认密码账号，而是判断哪个该锁、哪个该留、哪个改密后还得通知下游系统。尤其在生产库上，CTXSYS 或 ORDSYS 被锁住，可能让全文检索或多媒体功能静默失效，日志里还不报错。
