怎样解决Oracle中GRANT授权语句执行缓慢卡顿的问题？-Oracle-PHP中文网

grant语句卡住主因是锁阻塞而非性能问题，需查v$lock定位ddl或dml锁链，确认blocking_sid后查sql_id分析阻塞源，kill session无效时需按spid用kill-9或orakill终止，library cache lock源于复杂对象授权触发重编译，权限延迟因pga缓存快照所致。

grant 语句卡住，基本不是 sql 本身慢，而是被锁住了——大概率是 ddl 锁或 library cache lock 阻塞，不是性能配置问题。

GRANT 被阻塞时怎么快速定位源头

别查 AWR 或执行计划，先看锁链。Oracle 执行 GRANT 前必须获取目标对象的排他锁（lmode = 6），若该表正被 ALTER TABLE、TRUNCATE 或未提交的 UPDATE 占着，就会死等。

运行这个查询，重点关注 l1.type 是 'DDL' 或 'DML' 且 l1.lmode = 6 的行：

SELECT s1.sid, s1.serial#, s1.username, s1.osuser, s1.program,
       s2.sid blocking_sid, s2.serial# blocking_serial,
       l1.type, l1.lmode, l2.request
FROM v$lock l1
JOIN v$session s1 ON l1.sid = s1.sid
LEFT JOIN v$lock l2 ON l1.id1 = l2.id1 AND l1.id2 = l2.id2 AND l2.request > 0
LEFT JOIN v$session s2 ON l2.sid = s2.sid
WHERE l1.block = 1 OR l2.sid IS NOT NULL;

如果 blocking_sid 非空，直接查它的 sql_id：SELECT sql_id FROM v$session WHERE sid = <blocking_sid></blocking_sid>，再查 v$sql 看是不是长事务或挂起的 DDL
若 blocking_sid 为空但 l2.request > 0，说明存在多层等待链，得逐级往上追

ALTER SYSTEM KILL SESSION 不生效怎么办

ALTER SYSTEM KILL SESSION 只发信号，会话不响应就白搭。常见于 IO 等待、归档日志写满、或卡在内核态——此时 v$session.status 显示 KILLED，但 sid 还挂着，锁也不释放。

先拿到 OS 进程号：SELECT p.spid, s.sid, s.serial#, s.username FROM v$session s JOIN v$process p ON s.paddr = p.addr WHERE s.sid = <blocking_sid></blocking_sid>
Linux/Unix 下执行：kill -9 <spid></spid>；Windows 下用：orakill <inst_name><spid></spid></inst_name>
⚠️ 切记只杀用户会话对应的 spid，别碰 tnslsnr、PMON 或监听进程

为什么 GRANT 自己会触发 library cache lock

给大视图或复杂对象授权（比如 GRANT SELECT ON v_emp_report TO app_user）时，Oracle 需重编译依赖的 cursor，这时会争抢 library cache lock。尤其当共享池里已有大量未失效的 SQL 引用该对象，NULL 锁没被打破，新授权就得等旧解析完成。

Crypto Sniper Oracle

机构级量化市场预言机，提供订单簿失衡（OBI）、VWAP分析、自动化报告及Telegram预警。

下载

现象：等待事件里出现 library cache lock，v$session.event 显示该等待
临时缓解：让阻塞会话主动退出（比如断开应用连接），或清空相关 cursor：ALTER SYSTEM FLUSH SHARED_POOL（慎用，影响全局）
长期规避：避免对含 SYS_CONTEXT、动态过滤逻辑的视图频繁授权；改用角色间接赋权，减少直接对象授权频次

权限生效延迟不是 bug，但容易误判为卡顿

执行完 GRANT 后，在原会话里立刻查新授权的表报 ORA-00942: table or view does not exist？这不是卡，是 PGA 缓存了旧权限快照。Oracle 解析 SQL 时读的是“授权快照”，不是实时元数据。

验证方式：新开一个会话，执行 SELECT * FROM target_table，通常立刻可访问
不想重连？在当前会话强制硬解析一次：ALTER SYSTEM FLUSH SHARED_POOL（高风险）或执行任意一条涉及该对象的新 SQL（如 SELECT COUNT(*) FROM target_table），触发权限重载
注意：角色权限（GRANT role TO user）同样受此机制影响，SET ROLE 后也需新解析才生效

真正难处理的从来不是 GRANT 语句本身，而是它背后牵扯的锁链、共享池状态和会话缓存行为——定位时盯死 v$lock 和 v$session.event，动手前确认阻塞源是否真能安全 kill，别为了跑一条授权，把正在跑的 ETL 给干掉了。