判断僵尸账号需综合会话活跃度、资源占用和业务依赖，优先锁定而非删除，锁定前须清理残留会话并检查dblink、definer程序等隐式依赖。
确认账号是否真处于“僵尸”状态
不能单凭last_login为空或很久没登录就判定是僵尸账号。Oracle不记录所有用户的登录时间，尤其用连接池、中间件或应用直连的账号，dba_users.last_login字段常为空或不更新。必须结合会话活跃度、资源占用和业务归属综合判断。
- 查最近是否有会话活动：
SELECT sid, username, status, last_call_et FROM v$session WHERE username = 'YOUR_USER' AND status = 'ACTIVE'—— 若长期无ACTIVE且last_call_et > 86400（24小时），再往下看 - 查是否还在占临时段：
SELECT * FROM v$sort_usage u JOIN v$session s ON u.session_addr = s.saddr WHERE s.username = 'YOUR_USER'—— 有结果说明 TEMP 还没释放，不能直接锁 - 查是否有对象依赖：比如该用户下有被其他 schema 的视图/同义词引用的表，或作为
DEFINER执行的存储过程，贸然停用可能引发运行时错误
优先选择锁定而非删除
生产环境里，删账号是高危操作——可能残留对象、触发隐式依赖、影响审计合规。绝大多数“僵尸账号”只需停用访问权限，保留元数据即可。Oracle 提供标准机制：ALTER USER ... ACCOUNT LOCK，它不删任何东西，只让下次登录立刻报 ORA-28000: the account is locked。
- 锁定带原因（可选但推荐）：
ALTER USER app_report ACCOUNT LOCK FAILED_LOGIN_ATTEMPTS 3;—— 后续审计能追溯操作意图 - 若账号关联了
DEFAULTprofile，且该 profile 启用了FAILED_LOGIN_ATTEMPTS，锁定后重试登录会自动触发账户锁定，无需额外操作 - 注意：锁定不影响已存在的活跃会话，需配合
kill session清理残留连接（见下一条）
清理残留会话再锁定，避免 TEMP 残留
账号被长期闲置，但后台可能仍有未释放的会话在占临时表空间（比如某次大排序没做完就断连）。直接锁定账号，这些会话仍存在，TEMP 段持续不释放，v$sort_usage里 blocks 不降，最终导致 TEMP 表空间爆满。
- 先查该用户所有会话：
SELECT sid, serial#, status, sql_id, event FROM v$session WHERE username = 'YOUR_USER' - 对每个
status = 'INACTIVE'但last_call_et > 3600的会话，执行：ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE - 若执行后状态变为
KILLED但v$sort_usage仍有记录，说明 OS 进程还活着，需查v$process.spid并用kill -9强杀对应系统进程（仅限 Linux/Unix；Windows 用orakill）
Profile 配合实现自动空闲超时
靠人工定期巡检“僵尸账号”不可持续。更可靠的做法是提前设防：用 Profile 控制空闲会话生命周期，让系统自动断开长期不动的连接，从源头减少僵尸产生。
- 修改用户 profile：
ALTER PROFILE default LIMIT IDLE_TIME 30—— 会话空闲 30 分钟后自动断开 - 注意：
IDLE_TIME只对新建立的会话生效，已有会话不受影响；且它不终止账号，只断连接 - 若想进一步限制登录频率，可加：
FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1，防止暴力试探 - 真正长期不用的账号，仍需人工评估后锁定——Profile 是辅助手段，不是替代方案
最容易被忽略的一点：锁定账号前，务必确认它没被用作数据库链路（DB LINK）的目标用户、没被DEFINER RIGHTS程序调用、也没在调度作业（DBMS_SCHEDULER）中硬编码。这些隐式依赖不会报错，直到某个业务功能突然失效。
