最稳妥方案是用pl/sql循环+execute immediate，需显式排除系统用户、跳过当前会话用户、用户名加双引号，并添加容错逻辑；纯sql拼语句仅适用于一次性低风险场景。
直接结论：用 pl/sql 循环 + execute immediate 最稳妥，但必须显式排除系统用户、跳过当前会话用户、处理双引号包裹的用户名，并配合容错逻辑；纯 sql 拼字符串生成语句再人工执行，只适合一次性、低风险场景。
为什么不能直接用 SELECT 拼 ALTER USER 语句批量执行
生成一堆 ALTER USER xxx ACCOUNT LOCK; 看似省事，但实际执行时容易出错：
• 复制粘贴漏掉空格或换行，导致语法错误（比如 ACCOUNTUNLOCK 连在一起）
• 用户名含连字符（如 APP-USER）或数字开头（如 2024_REPORT），不加双引号会报 ORA-00911: invalid character
• 某些用户已锁/已解锁，执行会中断整个脚本（除非加异常捕获）
• 无法动态过滤——比如“只锁 30 天未登录的普通用户”，纯 SQL 生成后就固化了，没法复用
PL/SQL 批量锁定：必须处理的三个关键点
写一个安全的锁定过程，这三点不处理就会失败或误操作：
• username NOT IN ('SYS','SYSTEM','SYSMAN','DBSNMP','OUTLN','DIP','WMSYS','ORDSYS','MDSYS','CTXSYS','ANONYMOUS','XDB','EXFSYS','SI_INFORMTN_SCHEMA','OLAPSYS','SCOTT','HR','OE','PM','IX','SH','BI') ——硬编码排除比依赖 oracle_maintained = 'Y' 更可靠，尤其在 Oracle 11g 或更早版本中该字段不存在
• 加上 AND username NOT LIKE 'APEX%'、NOT LIKE 'FLOWS%'、NOT LIKE 'MDDATA%'、NOT LIKE 'SP%'，避免组件用户被误锁
• 构造 DDL 时强制用双引号：'ALTER USER "' || u.username || '" ACCOUNT LOCK;'，否则遇到大小写混合或特殊字符用户名必报错
解锁时最容易踩的坑：当前会话用户和 LOCKED(TIMED) 状态
执行 EXECUTE IMMEDIATE 解锁时：
• 绝对不要在循环里解锁当前连接用户（如用 SYS 连接却去执行 ALTER USER SYS ACCOUNT UNLOCK），会触发 ORA-01031: insufficient privileges 或直接断开会话
• account_status 返回 LOCKED(TIMED) 的用户，是因 profile 中 FAILED_LOGIN_ATTEMPTS 触发的自动锁定，不是手动锁的，ALTER USER ... ACCOUNT UNLOCK 虽然能解，但下次输错密码还会锁；这类用户建议先查 dba_profiles 调整策略，而不是只做一次解锁
• 不要依赖 DBMS_OUTPUT.PUT_LINE 判断是否成功——它只打印语句，不反映执行结果；真要确认，得在循环里加 SELECT account_status INTO v_status FROM dba_users WHERE username = u.username; 再判断
真正安全的操作节奏是分三步走
别想着一步到位：
• 第一步：运行查询语句，确认待操作用户列表，例如：SELECT username, account_status, created FROM dba_users WHERE account_status = 'OPEN' AND username NOT IN (...)
• 第二步：用 PL/SQL 封装逻辑，加 BEGIN ... EXCEPTION WHEN OTHERS THEN NULL; END; 容错，但日志里记下哪些用户跳过了
• 第三步：操作完立刻验证，别只信“已更改”提示——执行 SELECT username, account_status FROM dba_users WHERE username IN (...) 确认状态已变
最常被忽略的是：锁定后已有会话仍存活，ALTER USER ... ACCOUNT LOCK 不杀连接；需要立刻阻断访问，就得配合 ALTER SYSTEM KILL SESSION 'sid,serial#'; 查 v$session 补刀
