超过Firebird交易计数 [英] Firebird Transaction Count Exceeded

问题描述

我们有一个运行Firebird数据库的实现，在此错误出现:

We have an implementation running a Firebird database where we get this error:

"超出了执行限制-超出了事务计数.执行备份和还原以使数据库再次可操作."

我们知道如何通过将数据库设置为只读，执行备份&来解决此问题.恢复并再次使其变为读写状态，但是我们不太确定是什么原因造成的.我感觉交易限制在十亿(?)以内.

We know how to fix this by making the database read only, performing backup & restore and making it read write again, however we're not too sure what is causing this. I have a feeling that the transactions is limited to a billion(?).

任何人都可以确认吗?预防这种情况的正确方法是什么?

Can anyone confirm that? And what is the correct way to prevent this?

推荐答案

Firebird具有以带符号的32位整数形式(用于2.5及更早版本)的单调递增的事务计数器.因此，交易数量限制为+/- 2 ³¹ -1.在Firebird 3中，交易ID已更改为无符号的48位整数(因此限制为2 ⁴⁸ )，并且在将来的AFAIK中有扩展为64位整数的空间.

Firebird has a monotonically increasing transaction counter in the form of a signed 32 bit integer (for 2.5 and earlier). So the number of transactions is limited to +/- 2³¹-1. In Firebird 3 the transaction id has been changed to an unsigned 48 bit integer (so the limit there is 2⁴⁸), with room to expand to 64 bit integers in the future AFAIK.

使用gbak执行备份和还原时，事务计数器将重置.可以随时执行此操作，但是当实际达到限制时，需要将数据库标记为只读，因为在只读数据库中，数据库的最后一个"事务标识用于新事务，而不是分配新的事务.交易ID.

The transaction counter is reset when performing a backup and restore using gbak. This can be done at any time, but when the limit is actually reached it requires marking the database read-only, because in a read-only database the 'last' transaction id of the database is used for new transactions instead of allocating a new transaction id.

Firebird是MVCC(多版本并发控制)数据库，这意味着它可以维护记录的多个版本.这些记录版本标记有创建该版本的事务的ID.在进行备份和还原时，仅备份最新版本，在还原时，这些记录版本的事务ID较低(可能为1).

Firebird is a MVCC (Multi Version Concurrency Control) database, which means it maintains multiple versions of a record. These record versions are marked with the id of the transaction that created that version. With a backup and restore only the latest versions are backed up and on restore those record versions are written with a low transaction id (probably 1).

由于基于隔离级别，事务开始的时间等其他事务的记录版本的可见性，因此无法仅重置事务计数器(或至少:具有很多复杂性).例如，具有可重复读取的事务只能看到由事务开始时提交的事务创建的记录版本.由活动事务或事务开始后提交的事务创建的记录版本不可见.

Just resetting transaction counter is not possible (or at least: has a lot of complications) due to visibility of record versions for other transactions based on the isolation level, time that the transaction started etc. For example a transaction with repeatable read can only see record versions created by transactions that were committed at the time the transaction started. Record versions created by active transactions, or by transactions that were committed after transaction start are invisible.

除了在达到交易限制之前进行常规备份和实际还原(否则也会重置交易ID)之外，没有其他方法可以防止这种情况.

There is no way to prevent this, except for doing regular backup and an actual restore before the transaction limit is reached (as that will reset the transaction id as well).

这篇关于超过Firebird交易计数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！