DBMS_LOCK.SLEEP在某些数据库中不可用，因该包默认未向普通用户授权，且12c+多租户环境默认禁用；需DBA显式授权，但精度受OS调度影响，存在几十毫秒偏差。
DBMS_LOCK.SLEEP 为什么在某些数据库里根本用不了
因为 dbms_lock 包默认不向普通用户授权，甚至有些 oracle 版本（比如 12c 及以后的多租户环境）直接禁用了该包，除非显式执行 grant execute on dbms_lock to your_user。更麻烦的是，即使授了权，dbms_lock.sleep 的精度受限于操作系统调度，实际等待时间可能比指定值多出几十毫秒——它不是硬实时机制。
常见错误现象：ORA-06550: line X, column Y: PLS-00201: identifier 'DBMS_LOCK.SLEEP' must be declared，或运行时报 ORA-01031: insufficient privileges。
- 先确认是否已授权：
SELECT * FROM USER_TAB_PRIVS WHERE TABLE_NAME = 'DBMS_LOCK'; - 没结果？找 DBA 执行授权语句，别自己尝试
CREATE OR REPLACE PACKAGE仿写——内部依赖DBMS_LOCK_ALLOCATED等私有对象，不可替代 - Oracle 19c+ 在 CDB/PDB 架构下，需在目标 PDB 内单独授权，CDB$ROOT 授权无效
DBMS_SESSION.SLEEP 替代方案但只存在于 21c 及以上
DBMS_SESSION.SLEEP 是 Oracle 21c 引入的新函数，语义和用法跟 DBMS_LOCK.SLEEP 几乎一致，但无需额外授权，且精度略好（仍受 OS 限制）。但它在 19c 或更早版本中完全不存在——调用会直接报 PLS-00201: identifier 'DBMS_SESSION.SLEEP' must be declared。
使用场景：适合新项目、明确锁定 Oracle 21c+ 环境的批处理脚本或调试逻辑；老系统迁移前务必检查版本兼容性。
- 检查版本：
SELECT * FROM V$VERSION WHERE BANNER LIKE 'Oracle Database%'; - 参数单位统一是秒，支持小数（如
DBMS_SESSION.SLEEP(0.5)表示 500ms） - 它不会释放事务锁、不会提交或回滚，只是挂起当前会话控制流——这点和
DBMS_LOCK.SLEEP一致
不用包也能暂停？用隐式游标 + ROWNUM 做“伪睡眠”
当既没权限用 DBMS_LOCK，又卡在旧版本 Oracle（如 11g/12c），还不能改数据库配置时，有人用 SELECT ... INTO ... FROM DUAL CONNECT BY LEVEL 拖慢执行——这属于危险操作：它吃 CPU、触发硬解析、可能被并行执行优化绕过，且时间不可控。
真正可用的轻量级替代是结合 DBMS_UTILITY.GET_TIME 轮询，虽然不够优雅，但稳定、无权限依赖、兼容所有版本。
DECLARE
v_start NUMBER;
v_now NUMBER;
BEGIN
v_start := DBMS_UTILITY.GET_TIME; -- 单位：厘秒（10ms）
LOOP
v_now := DBMS_UTILITY.GET_TIME;
EXIT WHEN (v_now - v_start) >= 500; -- 等待 5000ms（5秒）
END LOOP;
END;- 注意单位：返回值是厘秒，不是毫秒，
500对应 5 秒 - 循环体尽量空，避免引入额外开销（比如不要在里面查表或调函数）
- 对高并发会话慎用，纯 CPU 轮询会抬高负载，不如协调应用层做 sleep
真实业务里该选哪个：看权限、版本、精度容忍度
没有银弹。DBA 给了 DBMS_LOCK 权限且版本够老？用它最省事；项目已上 21c 且不想管授权？直接切 DBMS_SESSION.SLEEP；连轮询都怕影响性能？那说明不该在数据库里 sleep——把延迟逻辑提到应用层，由 Java/Python 控制更可控、可观测、可中断。
最容易被忽略的一点：所有这些“sleep”都发生在服务端会话内，如果客户端设置了查询超时（比如 JDBC 的 socketTimeout），而你睡了 30 秒，连接大概率已被中间件或驱动主动断开，后续语句直接报 IO Error: Connection reset —— 这时候再准的 sleep 也没意义。
