普通用户不能直接执行ALTER SYSTEM KILL SESSION，因该权限属高危系统级权限，易致业务中断；须通过AUTHID CURRENT_USER存储过程封装，按USERNAME和SID严格过滤，仅允许杀自己会话，并在RAC环境处理INST_ID。
普通用户不能直接执行 alter system kill session，必须通过存储过程封装 + 权限隔离来实现“仅杀自己会话”的安全控制。
为什么不能直接 GRANT ALTER SYSTEM 给普通用户
该权限属于高危系统级权限，一旦授予，用户可杀任意会话（包括其他用户、后台进程、甚至 SYS 会话），极易引发业务中断或数据不一致。Oracle 官方明确不建议在生产环境开放此权限给非 DBA 用户。
真实错误现象：ORA-01031: insufficient privileges —— 即使查到了自己的 SID 和 SERIAL#，执行 ALTER SYSTEM KILL SESSION '123,456' 仍会报错。
- 权限粒度太粗，无法按会话归属做限制
- 无法审计谁在什么时间杀了哪个会话
- RAC 环境下跨实例操作需显式指定
@inst_id，裸命令易出错
核心思路：用 AUTHID CURRENT_USER + USERNAME 过滤做身份绑定
关键不是“让普通用户能执行 KILL”，而是“让数据库替用户执行 KILL，且只对当前用户拥有的会话生效”。这靠两个机制协同：
-
AUTHID CURRENT_USER：确保存储过程中查询V$SESSION时，USER或SYS_CONTEXT('USERENV','SESSION_USER')返回的是调用者身份，而非定义者（SYS）身份 - WHERE 条件强制匹配
USERNAME = USER AND SID = :input_sid：查不到记录就拒绝执行，从源头堵死误杀他人会话的可能 - 不接受
SERIAL#作为输入参数（避免用户拼凑非法组合），改由存储过程内部查出
示例片段（精简版）：
CREATE OR REPLACE PROCEDURE kill_my_session(p_sid NUMBER) AUTHID CURRENT_USER AS
v_serial# NUMBER;
BEGIN
SELECT SERIAL# INTO v_serial#
FROM V$SESSION
WHERE USERNAME = USER AND SID = p_sid;
EXECUTE IMMEDIATE 'ALTER SYSTEM KILL SESSION ''' || p_sid || ',' || v_serial# || '''';
EXCEPTION
WHEN NO_DATA_FOUND THEN
RAISE_APPLICATION_ERROR(-20001, 'SID ' || p_sid || ' not found or not owned by ' || USER);
END;
授权与调用时必须注意的三件事
即使存储过程写对了，漏掉任一环节都会导致调用失败：
-
SYS用户必须显式执行GRANT EXECUTE ON kill_my_session TO your_user；仅授EXECUTE ANY PROCEDURE不够，因为是跨 schema 调用 - 普通用户调用时必须带 schema 前缀，如
EXEC SYS.kill_my_session(1234)（假设过程建在SYS下）；若建在自己 schema，则直接EXEC kill_my_session(1234) - 过程内不能用
DISCONNECT SESSION替代KILL SESSION：前者是优雅断连（等待事务结束），后者是强制终止（可能回滚未提交事务），行为不同，别混淆
RAC 环境下必须处理 INST_ID
单实例可忽略，但 RAC 中同一 SID 可能在多个节点上存在。若不指定实例，V$SESSION 查询可能返回多行，SELECT ... INTO 报 TOO_MANY_ROWS 错误。
正确做法：
- 过程参数增加
p_inst_id NUMBER - 查询条件加
AND INST_ID = p_inst_id -
EXECUTE IMMEDIATE语句中拼接',@' || p_inst_id，例如：'ALTER SYSTEM KILL SESSION ''123,456,@2''' - 调用前必须先确认目标会话所在实例，可通过
SELECT INST_ID, SID, SERIAL#, USERNAME FROM GV$SESSION查
容易被忽略的点：很多人写了 RAC 兼容逻辑，却忘了在 GRANT 时把 SELECT 权限授给 GV$SESSION（而非仅 V$SESSION），导致查询失败。
