DBMS_LOCK.REQUEST必须先调ALLOCATE_UNIQUE获取handle，不可直传锁名；锁名需拼接业务字段且≤100字节、仅含字母数字下划线；request返回值须分0/1/4/2-3处理；RELEASE必须在正常流程和EXCEPTION中均显式调用。
DBMS_LOCK.REQUEST 必须搭配 ALLOCATE_UNIQUE 使用
直接传字符串给 DBMS_LOCK.REQUEST 会报 ORA-01031 权限不足或 ORA-20002 错误——因为 Oracle 要求锁句柄（handle）必须先通过 DBMS_LOCK.ALLOCATE_UNIQUE 注册，不能裸用锁名。这个注册过程会生成唯一、可复用的内部 ID，并缓存在会话级上下文里。
常见错误是跳过注册，写成：DBMS_LOCK.REQUEST('my_lock', DBMS_LOCK.x_mode, 30)；正确链路是：
- 先调
DBMS_LOCK.ALLOCATE_UNIQUE拿到lockhandle（输出参数） - 再用该 handle 调
DBMS_LOCK.REQUEST - 锁名（
lockname）只在ALLOCATE_UNIQUE阶段传一次，后续全靠 handle 通信
锁名必须带业务维度且严格校验长度与字符
锁名不是随便起的标签，它是全局命名空间里的唯一键。硬编码如 'proc_lock' 会导致所有调用串行化，哪怕它们处理的是完全无关的 org_id 或 batch_id。
正确做法是拼接关键业务字段，例如：g_pkg_name || '_' || p_org_id || '_' || p_batch_id。但要注意：
- 总长 ≤ 100 字节：超长会被静默截断，
'ORDER_PROC_12345678901234567890...'和'ORDER_PROC_12345678901234567891...'可能截成相同前缀，变成同一把锁 - 只用字母、数字、下划线：含点号（
.）、连字符（-）或空格会触发隐式类型转换，可能匹配失败或报 ORA-06502 - 避免动态拼接敏感值（如用户输入）：需提前
REPLACE(TRIM(p_input), ' ', '_')过滤
request() 返回值不能只判 0/非0，必须分情况响应
DBMS_LOCK.REQUEST 返回整数，每个值代表不同语义，笼统当成布尔值会掩盖关键状态：
-
0：成功获取锁（立即或等待后），可继续执行 -
1：等待超时——此时应决定是重试、记录告警，还是抛出业务异常（如RAISE_APPLICATION_ERROR(-20001, 'Lock timeout for '|| l_lockname)） -
4：当前会话已持有该锁——不是错误，但说明逻辑中存在重复加锁（比如递归调用或异常重入），需检查是否真有必要 -
2或3：死锁或参数非法，属严重异常，必须记录日志并终止
典型误写：IF l_ret != 0 THEN RAISE ... ——这会让 4（已持有）也被当错误处理，导致本可安全运行的嵌套调用失败。
锁释放必须覆盖正常路径和 EXCEPTION 两个出口
最危险的疏漏：只在主流程末尾写 DBMS_LOCK.RELEASE，却忘了 EXCEPTION 块。一旦过程中途异常退出，锁不会自动释放，后续所有同名请求都会永久阻塞，直到数据库重启或 DBA 手动清理 DBMS_LOCK.FORCE_RELEASE。
正确结构必须显式双写：
- 主流程结尾：执行完核心逻辑后，立刻
DBMS_LOCK.RELEASE(l_lockhandle) - EXCEPTION 块内：捕获异常后，先
DBMS_LOCK.RELEASE(l_lockhandle)，再RAISE或处理
注意：DBMS_LOCK.RELEASE 对已释放或不存在的 handle 是幂等的，不必额外判断 handle 是否有效。
复杂点在于锁生命周期和事务边界不耦合——锁是会话级资源，而事务可能回滚。所以释放锁的动作不能放在自治事务里，也不能依赖 COMMIT 触发；它必须由你亲手、在两个出口都写清楚。
