DBMS_LOCK锁名必须带业务上下文以确保互斥边界精准：硬编码锁名会导致误阻塞，并发请求应按关键维度（如org_id、batch_id）拼接锁名，长度≤100字节且仅含字母、数字、下划线；request()返回值需分0（成功）、1（超时）、4（已持有）等情形分别处理；锁必须在EXCEPTION和主流程中显式release，否则会话级残留致死锁。
dbms_lock 可以实现存储过程的互斥运行，但必须在有 apps 权限的会话中调用，且锁名需保证业务唯一性，否则可能锁错范围或漏锁。
为什么 DBMS_LOCK 的锁名必须带业务上下文
锁名（lockname）是全局唯一的字符串标识，Oracle 用它映射到内部锁句柄。如果多个 OU 或多个参数组合共用同一个锁名（比如硬编码为 'my_proc_lock'），会导致本该并行执行的请求被错误阻塞；反之，若锁名过于宽泛（如只含包名不含 org_id），又起不到互斥作用。
- 正确做法：把关键业务维度拼进锁名，例如
g_pkg_name || '_' || g_org_id || '_' || p_batch_id - 注意长度限制：
lockname最长 100 字节，超长会被截断，导致不同值生成相同锁名 - 避免特殊字符：空格、点号、斜杠等可能引发隐式转换或解析异常，建议只用字母、数字、下划线
DBMS_LOCK.request() 返回值要逐个判断，不能只看是否为 0
DBMS_LOCK.request() 返回整数，不同值代表不同状态，直接 IF l_lock_output 0 THEN RAISE ... 会掩盖可恢复的等待场景。
-
0：成功获取锁（立即或等待后） -
1：超时（未等到锁释放），此时应决定是重试、报错还是跳过 -
4：当前会话已持有该锁（递归调用或逻辑重复加锁），不是错误，但需检查业务是否真需要嵌套锁 -
2或3：死锁或参数错误，属于异常，应记录日志并退出
示例片段：
l_lock_output := dbms_lock.request(l_lockhandle, 6, 30, FALSE); -- 等待30秒 CASE l_lock_output WHEN 0 THEN NULL; -- 继续执行 WHEN 1 THEN RAISE_APPLICATION_ERROR(-20001, 'Lock timeout for ' || l_lockname); WHEN 4 THEN NULL; -- 已持有，不处理 ELSE RAISE_APPLICATION_ERROR(-20002, 'Lock error: ' || l_lock_output); END CASE;
锁必须在 EXCEPTION 和正常流程里都释放
忘记调用 DBMS_LOCK.release() 是最常见也最危险的错误——锁不会自动释放，后续所有同名请求都会卡死，直到数据库重启或手动清理（DBMS_LOCK.ALLOCATE_UNIQUE 不会覆盖已存在的锁句柄）。
- 释放操作必须放在
EXCEPTION块和主流程末尾两个位置 - 不要依赖
AFTER STATEMENT触发器或自治事务来释放，它们无法感知当前会话的锁状态 - 释放前检查
l_lock_output = 0，避免对未成功获取的锁调用release报错
替代方案：没有 apps 权限时怎么安全互斥
当数据库账号无 EXECUTE 权限给 DBMS_LOCK（比如普通开发账号或云数据库受限实例），不能强行授予权限，否则违反最小权限原则。
- 用
SELECT ... FOR UPDATE NOWAIT在业务表上加行级锁，例如插入/更新一条control_flag记录，失败则说明已被占用 - 查
fnd_concurrent_requests表（EBS 环境）或自建运行状态表，确认同参数组合无'R'（Running）状态的活跃请求 - 避免轮询：不要写
WHILE (exists...) LOOP dbms_lock.sleep(1); END LOOP;，容易拖垮数据库连接池
真正难的不是加锁，而是定义清楚“互斥边界”——是按用户、组织、批次、还是数据范围？锁名设计和释放时机只是技术落地环节，边界模糊时，再严谨的 DBMS_LOCK 调用也会失效。
