我在Windows上运行Firebird 2.5（并且还尝试过早期版本）。每天中午12:00后，在一个特定的表上运行插入/更新查询挂起，但在12:35左右成功完成，无论何时启动。似乎Firebird正在对表进行某种维护，并且需要半个小时才能完成，在此期间无法写入表（但读取速度很快）。表本身非常小，大约10000行，相比之下我们在其他表中有数百万行 - 而其他表不会卡住。
我一直无法找到任何理由或解决方案。我尝试转储表并恢复它，这没有帮助，我尝试在超级服务器和经典之间切换，更改版本没有成功。
有没有人遇到这样的问题？
答案 0 :(得分：0)
没有。 Firebird没有任何内部维护程序绑定到一天的某个指定时间。似乎，您的服务器上有一些任务计划在中午12:00运行。或者服务器的网络用户在中午12:00开始进行大量访问。
答案 1 :(得分：0)
唯一的维护FB是“垃圾收集”（根据旧的记录版本），这是在“需要时”的基础上完成的（通常在选择记录时，请参阅firebird.conf中的GCPolicy）不是在某个预定的时间。
您是否仅在这几个小时内遇到此挂起，或者插入该表的速度总是很慢？您是否在减速期间检查了服务器负载（即在任务管理器中，CPU是否已超出）？无论如何，这里有一些想法要检查：
你在桌子上有什么约束/触发器？如果它们涉及一些广泛的检查（即针对包含数百万行的其他表），这可能是插入需要这么长时间的原因。
也许当时有其他服务被触发？也就是说你当时有一个cron工作来备份数据库？或者也许当时以更高优先级运行的其他系统服务会降低服务器的速度？
您是否为该表激活了跟踪服务？请参阅FireBird根目录中的fbtrace.conf。如果它处于活动状态，则广泛的日志记录可能是减速的原因，如果它不活动，使用它可能会帮助您找到原因。
ForcedWrites / UnflushedWrites有什么设置（参见firebird.conf）？改变它们会有所不同吗？
在firebird.log中是否记录了这个麻烦的时间框架？
答案 2 :(得分：0)
对我来说，看起来你有一个从12:00开始的过程并做了一些锁定整个表的事情。使用监控表或跟踪管理器查看是否存在可疑的任何连接或活动事务 我还认为您自己的事务是在没有LOCK TIMEOUT的情况下使用WAIT子句启动的，您可能希望将其更改为NO WAIT或使用LOCK TIMEOUT等待，以便您的事务立即失败或在超时后失败。
答案 3 :(得分：0)
我的建议是在2.5中使用TRACE API来追踪那个时间附近或周围发生的事情。这应该有助于您获得有关正在发生的事情的更多信息。 我用它来调试http://upscene.com/products.misc.fbtm.php有点儿车本身，但是当它工作时它是一个神派。
答案 4 :(得分：0)
某些客户端连接是否在中午12:00关闭？我在70.000记录大小的表上遇到了类似的问题：
客户端“A”具有永久打开的数据库连接，例如“select * from TABLE”。这是一个“只读事务”，但足以让服务器生成Record-Versions。为什么？ 客户端“B”对此表进行了大量更新，服务器试图保护世界，就像“A”启动她的“选择”一样。这对于Transactionable DB-Servers来说是正常的，它通过在更新之前创建记录数据的记录副本来实现。 所以在我的情况下，这个表170.000记录版本存在。您可以通过
来衡量这一点gstat -r -t TABLE db.fdb | grep版本
如果客户端“B”出现故障，则记录版本的数量不再增长。客户端“A”是有罪的，冻结所有这些版本，强制服务器持有它。最后，如果客户端“A”关闭（或者例如防火墙规则切断所有挂起的连接），Firebird很乐意开始摆脱现在无用的记录版本。 这个“扫”？！编程错误（甚至2.5.2）cpu是3％它只做<10.000版本/分钟所以这个TABLE的性能大约是2％。