【发布时间】:2014-05-23 22:26:26
【问题描述】:
我们有一个运行 Firebird 数据库的实现,但出现此错误:
“超过实施限制 - 超出事务计数。执行备份和恢复以使数据库再次可操作。”
我们知道如何通过将数据库设为只读、执行备份和恢复并使其再次读写来解决此问题,但我们不太确定是什么原因造成的。我有一种感觉,交易仅限于十亿(?)。
谁能证实?防止这种情况的正确方法是什么?
【问题讨论】:
标签: firebird
我们有一个运行 Firebird 数据库的实现,但出现此错误:
“超过实施限制 - 超出事务计数。执行备份和恢复以使数据库再次可操作。”
我们知道如何通过将数据库设为只读、执行备份和恢复并使其再次读写来解决此问题,但我们不太确定是什么原因造成的。我有一种感觉,交易仅限于十亿(?)。
谁能证实?防止这种情况的正确方法是什么?
【问题讨论】:
标签: firebird
Firebird 有一个单调递增的事务计数器,其形式为带符号的 32 位整数(适用于 2.5 及更早版本)。所以交易数量被限制在 +/- 231-1。在 Firebird 3 中,事务 id 已更改为无符号 48 位整数(因此限制为 248),在未来 AFAIK 中有扩展为 64 位整数的空间。
事务计数器在使用gbak 执行备份和恢复时重置。这可以随时完成,但是当实际达到限制时,需要将数据库标记为只读,因为在只读数据库中,数据库的“最后一个”事务 id 用于新事务而不是分配新事务交易编号。
Firebird 是一个 MVCC(多版本并发控制)数据库,这意味着它维护一条记录的多个版本。这些记录版本标有创建该版本的事务的 ID。通过备份和恢复,仅备份最新版本,在恢复时,这些记录版本使用低事务 id(可能为 1)写入。
由于基于隔离级别、事务开始时间等的其他事务的记录版本的可见性,仅重置事务计数器是不可能的(或者至少:有很多复杂性)。例如具有可重复读取的事务只能查看由在事务开始时提交的事务创建的记录版本。由活动事务或事务启动后提交的事务创建的记录版本是不可见的。
没有办法防止这种情况,除了在达到事务限制之前进行定期备份和实际恢复(因为这也会重置事务 ID)。
【讨论】:
database owner。它可能会影响以后的应用程序正常过程,尤其是那些更改元数据的过程(将程序和数据库升级到新版本)。 2)可靠性:您将数据库重新创建到什么文件中?在旧数据库文件上“就地”重新创建有点冒险,最终可能导致数据丢失。较新的 FB 会