Oracle批量作业，如何防止锁

Question

我们有几个夜间作业在 Oracle 11g R2 实例中运行，并非所有这些作业都在我们的控制之下。其中一些是由第三方运行的外部数据加载。这些作业以 PL/SQL 包的形式实现，并使用 DBMS_SCHEDULER 工具运行。

其中一些作业对同一组数据进行操作，即包含用户条目的表，例如。 G。更新个人数据、移除退休用户、添加新加入的用户。由于作业大多使用批量语句来运行更新，我们现在已经多次遇到阻塞锁，不得不杀死单个作业以允许其他作业运行。

有什么好的方法可以防止工作相互冲突？

我正在考虑这样的事情：

• 设置了解依赖关系并协调依赖作业的元作业
• 创建计划，尽可能将冲突的作业分开
• 与第三方协调工作以防止“外部”和“内部”工作之间的冲突
• 不使用批量语句（使用单个 MERGE 或 UPDATE 一次更新所有内容）而是逐个更新以提交中间结果

特别是最后一个选项对我来说似乎是一种合理的方法，以减少阻塞锁的可能性。但我知道，当我将工作从批量更新切换到循环游标时，性能会受到很大影响。

Answer 1

这可能是 DBMS_LOCK 包的一个很好的用途。 DBMS_LOCK 允许您访问 Oracle 内部使用的相同入队/锁定模型。

您可以建立一个入队，然后多个进程可能会以各种锁定模式占用该入队。锁将像任何其他队列一样显示，类型为“UL”（用于用户锁）。

例如，假设您有三个可以同时运行的进程，但是您有一个进程需要等待所有这三个进程都运行，并且需要自己运行，然后它后面还有两个进程完成后可以同时运行的进程。

您可以让前三个进程在“S”（共享）模式下使用 UL 入队，它们都可以同时运行。然后运行需要自己运行的进程，但是在代码的开头，让它以'X'（独占）模式进入UL入队。该进程将等待以共享模式保持队列的三个进程完成。现在，您也可以再次使用共享模式运行最后两个进程。他们将在请求独占模式锁的进程后面排队，一切都按照你想要的顺序运行。

这是一个简单的例子。使用不止一种 UL 类型的锁，以及可以持有多种锁的模式，您的流程和锁定策略可能会变得任意复杂。

希望对您有所帮助。

Answer 2

在不了解所有细节的情况下很难给出任何建议。

最简单的事情是安排作业不重叠（如果流程允许）。

如果你不能这样做，那么可能没有简单的解决方案，特别是如果有你无法修改的作业。

Answer 3

较小的交易使其发生冲突的可能性较小，但墨菲可能/将会打击你。我会以“正确”的顺序开始工作......