delphi - Firebird强行解除僵局

Question

我正在使用 Delphi IBQuery 和 IBTransaction 组件通过此查询更新数据库中的所有记录:

UPDATE INVOICES SET BLK = 0;

当用户打开另一个客户端应用程序时，某些记录(由用户打开)会陷入死锁。

问题在于我的应用程序必须完成上述查询。

是否可以实现某种解决方案来强制消除死锁？例如 SQL 查询？

Firebird版本是2.1.2.18118在 Windows 7 上运行

Answer 1

最好的选择是重构这些应用程序。

FB/IB 的自然模式是有两个并行事务。

• #1 将是只读的、已提交的、永不关闭的，它仅用于读取数据。

• #2 将在短时间内打开/提交以实际应用更改。任何“正在编辑”的数据本身都不会打开交易。

长期存在的编辑事务通过阻止垃圾收集并迫使数据库(和索引)包含大量虚假数据来影响数据库。

我不知道您是否可以通过 IBX + IBQuery + 某种自定义更新查询(例如 bDE 时代的 TUpdateSQL)来完成此操作。 3rd-party FB 连接库通常对双向事务模式有一些支持。

然而，这种方法强加了一种非常具体的应用程序设计模式，并使 Firebird 无法保证数据一致性 - 这现在是您应用程序的负担。评论带来了一个很好的链接:Re: [firebird-support] Long read-only Transactions

<小时/>

在现代 Firebird 中，如果您具有数据库管理员/所有者角色，您可以强制删除事务。阅读有关监控表的内容。请注意，2.5.1 中存在错误，因此您可能需要等待 2.5.2 版本。

• http://www.upscene.com/documentation/fbtm2/index.html?dm_monitoringtables.htm
• c:\Program Files\Firebird\Firebird_2_5\doc\README.monitoring_tables.txt

但是，如果您强制回滚这些事务 - 应用程序将如何表现？用户仍在进行编辑，只是突然发现他的大部分更改都丢失了。

PS。 http://www.sql.ru/forum/actualthread.aspx?tid=910920此代码使用 mon$transactions 将事务映射到连接，然后强制断开违规应用程序。如果直接 delete from mon$transactions where...不可用，那么这就是剩下的选项。

PPS。由于 FB 2.1 长时间事务最好每隔几分钟提交(并关闭)一次(甚至是 r/o 事务)。原因是，如果他们碰巧使用 BLOB 计算，可能会导致数据库无法控制的增长，只能通过事务关闭来重置。虽然这可能会触发重新读取所有数据库感知控件，但在没有像 MIDAS ClientDataset 这样的中间缓存的情况下使用事务，这可以说仍然比数据库膨胀更好，在某些罕见的情况下，据报道数据库膨胀非常快。