Database 避免DB2ZOS上的锁定争用
我想在并行在线事务中大量使用的DB2表上放置用于Insert、Update和Delete的DB2触发器。这些表由Sysplex（DB2版本10）上的多个成员共享。 在每个DB2触发器中，我希望将一行插入一个中心表，并让一个后台进程每秒调用一个存储过程来读取该表，以处理新插入的行，按插入序列号或时间戳的顺序排列。 我非常关心DB2索引锁定争用，并希望确保不会给具有这些触发器的应用程序引入死锁/超时 显然，我会利用DB2特性来减少像行级锁定这样的锁定，但仍然看不到如何避免索引争用的真正好的方法 我看到三个不同的选项来选择新插入的行 将序列号放入表中，并将最后处理的序列号存储在后台进程中。我将执行以下select语句： 选择列_1。。。。列 从中央桌 其中序号>“最后序号” 按序号订购 锁定级别必须为CS，以避免选择未限制的行，这些行稍后将回滚。 我想我需要一个带有序号ASC的索引 Pro：后台进程只读取行，不进行更新/删除，只执行共享锁 Neg:索引争用，因为使用了升序键。 我可以稍后清理已处理的记录，例如通过滚动分区 在“已处理”和“未处理”表中放置一个状态字段，并按如下方式更改选择： 选择列_1。。。。列 从中央桌 其中状态='未处理' 按时间戳排序 稍后，我将更新要处理的选定行的状态 我想我需要一个状态索引 Pro：索引中没有升序编号，也没有直接删除 缺点：通过在线交易和后台进程进行并发更新 清理工作将在下班时间进行 删除已处理的记录，而不是状态字段更新。 选择列_1。。。。列 从中央桌 按时间戳排序 由于该表包含的记录很少，因此不需要任何可能创建热点的索引。 我还认为我可以选择隔离级别UR，因为我会在稍后删除此行时检测到潜在的未提交数据。 对于主键索引，我可以使用GENERATE_UNIQUE，它是随机的，不是递增的。 赞成：没有索引热点，插入可以通过随机唯一的\u ID分布在整个表空间中 缺点：每次调用存储过程时都会对表空间进行扫描和排序，并与联机插入并行删除记录 期待社会各界对这个问题的看法。这一定是一个非常常见的问题，例如SAP在其批输入表上应该有类似的问题。 我倾向于选择3，因为它避免了索引争用。Database 避免DB2ZOS上的锁定争用,database,db2,triggers,zos,Database,Db2,Triggers,Zos,我想在并行在线事务中大量使用的DB2表上放置用于Insert、Update和Delete的DB2触发器。这些表由Sysplex（DB2版本10）上的多个成员共享。 在每个DB2触发器中，我希望将一行插入一个中心表，并让一个后台进程每秒调用一个存储过程来读取该表，以处理新插入的行，按插入序列号或时间戳的顺序排列。 我非常关心DB2索引锁定争用，并希望确保不会给具有这些触发器的应用程序引入死锁/超时 显然，我会利用DB2特性来减少像行级锁定这样的锁定，但仍然看不到如何避免索引争用的真正好的方法 我看
也许在你的脑海里还有另一个解决方案 我认为您的各种解决方案都会出现许多性能问题。 我知道过早优化是一种罪恶，但经验告诉我们，在繁忙的系统中，有些事情是行不通的 您应该能够使用DB2s自动递增特性来获取序列号，而对性能影响很少或不太清楚 对于其余部分，您可能应该考虑一种基于队列的解决方案 让触发器将操作INSERT/UPDATE/DELETE和行的键放入MQ队列
那么在CICS中有一个长时间运行的backgound任务吗？做你的后处理，因为它一次处理一个更新，你不应该绊倒自己。拥有一个能够批量处理工作单元的单个已加载且活动的任务应该可以使您的吞吐量达到每秒3到500次更新的顺序 理论性能调整通常是徒劳的。您希望您的后台进程每秒处理多少行？首先，我将使用一个时间戳，不管时间戳如何，可能带有一个索引。这与初始性能无关，而更适用于理智的应用程序设计。你的版本是什么？如果可能的话，查看旧的_表数据更改表引用，这意味着SELECT将为您提供被DELETE语句删除的行。实际上，我更担心的是，如果您的进程在尝试处理单个记录时失败，会发生什么情况。触发器将每秒插入大约100行，在峰值时间每秒插入200行。估计每个LUW有10-20个插件，我估计大约有10个Tps。有时会通过直接SQL将表中的特定代码更新为新值，从而进行批量更新。这可能一次触发50000-100000个触发器，但是在夜间从单个批处理作业/LUW触发。关于时间戳。我完全同意，这比序列号好得多。然而，我仍然担心在时间戳上放一个索引，所有并发事务都会在e处插入或多或少相同的时间戳值
b-树的第二部分。我不确定DB2将如何同步索引更新，以及按照时间戳值的严格升序更新索引的最大速率是多少。作为主键，我仍然会使用GENERATE_UNIQUE Key，它在Sysplex中是随机且唯一的。MQ也是我的第一选择。我对使用MQ的担忧。除了在线更新之外，动态SQL批处理更新将是单个SQL语句对某些值进行批量更新。批处理作业使用TSO附件。我从IBM了解到，如果DB2事务不是在CICS或IMS/DC下运行，那么MQSSEND API不是事务性的。如果触发器是从TSO批处理附件触发的，则始终发送消息，即使LUW回滚。为了避免这种情况，触发器需要调用在WLM地址空间中运行的外部存储过程，并让RSS协调事务。我所合作的组织从未设置过WLM以在DB2和MQ之间建立2PC。我还希望将逻辑保持在仅在DB2地址空间中运行的本机触发器中。MQ上的另一个问题是性能，因为每个触发的触发器都必须为每个消息执行打开、放置和关闭操作。每个LUW将发送10-20条消息。这可能是性能和资源消耗问题。