不能一键锁所有用户，因误锁SYS、SYSTEM等关键账户会导致数据库管理中断；必须先筛选普通用户，排除系统用户、组件用户及示例用户后，再批量执行ALTER USER ... ACCOUNT LOCK。
能批量锁定，但不能“一键锁所有”——必须先筛选出真正需要锁定的普通用户，否则可能误锁 system、sys 等关键账户，导致数据库管理中断。
为什么不能直接 ALTER USER ... ACCOUNT LOCK 全库扫一遍
Oracle 的 DBA_USERS 视图包含所有用户，包括内置管理账户（如 SYS、SYSTEM、DBSNMP、ORDDATA 等）和 Oracle 组件专用用户（如 APEX_220100）。对这些用户执行 ACCOUNT LOCK 可能引发：
- 数据库后台作业失败（如统计信息收集、AWR 快照）
- EM Express 或 OEM 无法访问
- 某些 PL/SQL 包调用报
ORA-01031: insufficient privileges（因依赖被锁用户对象） - 后续无法用 SQL*Plus 连接（若误锁了
SYSTEM且无其他 DBA 账户）
安全筛选普通用户的 WHERE 条件怎么写
核心思路：排除已知高权限/系统用户 + 排除已锁定/过期状态（避免重复操作） + 限定创建来源（如只锁应用类用户）
推荐查询（适配大多数生产环境）：
SELECT 'ALTER USER ' || username || ' ACCOUNT LOCK;' AS lock_stmt
FROM dba_users
WHERE account_status = 'OPEN'
AND 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'
)
AND username NOT LIKE 'APEX%'
AND username NOT LIKE 'FLOWS%'
AND username NOT LIKE 'MDDATA%'
AND username NOT LIKE 'SP%'; -- 示例：若你约定应用用户以 SP 开头，则此处应改为 IN说明：
-
account_status = 'OPEN'：跳过已锁或过期用户，防止报错或无效操作 - 显式
NOT IN列出常见系统/示例用户，比依赖oracle_maintained = 'Y'更可靠（该字段在旧版本 Oracle 中不存在） -
username NOT LIKE 'APEX%'等：规避 APEX、Spatial、Data Mining 等组件用户 - 若你有明确命名规范（如所有业务用户为
APP_USER_XXX），建议改用username LIKE 'APP_USER_%'正向匹配，更安全
生成后怎么安全执行这些语句
生成的是一堆 ALTER USER ... ACCOUNT LOCK; 文本，不是可直接运行的脚本。必须人工确认 + 分批执行：
- 把查询结果复制到文本编辑器，检查前 5 行和末尾几行，确认没混入
SYS或SYSTEM - 不要全选执行；建议每次最多执行 20 条，中间加
COMMIT;（虽然 DDL 自动提交，但便于观察） - 执行前先查锁前状态：
SELECT username, account_status FROM dba_users WHERE username IN ('U1','U2','U3'); - 执行后立刻验证：
SELECT username, account_status FROM dba_users WHERE username IN ('U1','U2','U3');—— 必须全为LOCKED - 若某条报错（如
ORA-01918: user 'XXX' does not exist），说明源数据有脏数据，跳过即可，别强行重试
想用存储过程自动执行？注意 COMMIT 和异常处理
用 EXECUTE IMMEDIATE 批量执行时，最容易踩的坑是：没加异常捕获，一条失败就中断整个循环；或者误以为需要手动 COMMIT（其实 DDL 自动提交，加了反而报错）
最小可用存储过程示例：
CREATE OR REPLACE PROCEDURE batch_lock_users AUTHID CURRENT_USER AS
v_sql VARCHAR2(500);
BEGIN
FOR r IN (
SELECT 'ALTER USER ' || username || ' ACCOUNT LOCK' stmt
FROM dba_users
WHERE account_status = 'OPEN'
AND username NOT IN ('SYS','SYSTEM')
AND username NOT LIKE 'APEX%'
) LOOP
BEGIN
EXECUTE IMMEDIATE r.stmt;
DBMS_OUTPUT.PUT_LINE('Locked: ' || r.stmt);
EXCEPTION
WHEN OTHERS THEN
DBMS_OUTPUT.PUT_LINE('Failed on ' || r.stmt || ': ' || SQLERRM);
END;
END LOOP;
END;
/关键点：
-
AUTHID CURRENT_USER：确保权限基于调用者，而非定义者（避免权限不足） - 必须包在
BEGIN...EXCEPTION...END内，否则一个用户不存在就终止全部 - 不要在循环里写
COMMIT——ALTER USER是 DDL，自带隐式提交 - 执行前需授予调用者
ALTER ANY USER权限，或用DBA角色用户执行
真正麻烦的从来不是生成语句，而是确认“哪些用户真的该锁”——名字像普通用户，但可能是某个中间件的连接池账户；看似闲置，实则被定时任务调用。动手前花 10 分钟翻一翻应用文档或最近一周的 v$session，比事后救火强十倍。
