FirebirdSQL查询在12:00下午卡住

我在Windows上运行的是Firebird 2.5（也尝试过早期版本）。每天中午12:00之后，在一个特定表上运行插入/更新查询挂起，但在12:35左右成功完成，无论何时启动。似乎Firebird在桌面上进行某种维护，并且需要半个小时才能完成，在此期间无法写入表（但读取速度很快）。该表本身非常小，大约10000行，而我们在其他表中有数百万行 - 而其他表不会卡住。FirebirdSQL查询在12:00下午卡住

我一直未能找到任何理由或解决方案。我试图倾倒桌子并恢复它，这没有帮助，我尝试在超级服务器和经典版本之间切换，但没有成功更改版本。

有没有人遇到过这样的问题？

来源

2011-09-23 Rytis

编号火鸟没有任何内部维护程序绑定到某一特定时间的一天。看起来，您的服务器上有一些任务计划在中午12点运行。或者服务器的网络用户在下午12:00开始进行大量访问。

来源

2011-09-23 11:45:18

唯一的维护FB是“垃圾收集”（geting摆脱旧的记录版本），这是在“需要时”的基础上完成的（通常在选择记录时，请参阅firebird.conf中的GCPolicy）预定义时间。

您是否仅在这些特定时间内感受到这种情况，或者在插入该表时总是很慢？你是否在减速过程中检查了服务器的负载（例如，在任务管理器中，CPU是否被最大化）？无论如何，这里有一些想法来检查：

你有什么限制/触发器在桌子上？如果它们涉及一些广泛的检查（即针对其他包含数百万行的表），这可能是插入时间过长的原因。
也许还有一些其他的服务在当时被触发？即你当时是否有cron作业来备份数据库？或者，当时以更高优先级运行的其他系统服务会降低服务器的性能？
您是否对表格有跟踪服务？请参阅FireBird根目录中的fbtrace.conf。如果它处于活动状态，则广泛的日志记录可能是导致速度放慢的原因，如果它不活跃，使用它可能会帮助您找到原因。
ForcedWrites/UnflushedWrites（请参阅firebird.conf）的注册是什么？改变它们会不会改变？
在firebird.log中是否有这种麻烦的时间表记录？

来源

2011-09-23 11:50:04 ain

对我来说，它看起来像你有一个过程，开始于12:00，并做了一些锁定整个表的东西。使用监控表或跟踪管理器查看是否有任何看起来可疑的连接或活动事务。
我也认为你自己的事务是在没有LOCK TIMEOUT的情况下以WAIT子句开始的，你可能想用LOCK TIMEOUT将其更改为NO WAIT或WAIT，这样你的事务就会立即失败或者在超时之后失败。

来源

2011-09-24 08:04:24

我的建议是使用2.5中的TRACE API来追踪当时或附近发生的事情。这应该有助于让你了解正在发生的事情。我用它来调试http://upscene.com/products.misc.fbtm.php有点儿车本身，但是当它工作时它是一个神派。

来源

2012-03-29 18:24:33

是一些客户端连接在12:00 PM下去？我曾在一个70.000记录尺寸表了类似的问题：

客户“A”具有像“SELECT * FROM表”永久开放的DB连接。这是一个“只读事务”，但足以让服务器生成记录版本。为什么？客户端“B”对此表进行了大规模更新，服务器试图保持与“A”启动她的“选择”时一样的世界。这对于事务处理能力强的数据库服务器来说是正常的，并且通过在其更新之前创建记录数据的记录副本来实现。所以在我的情况下这个TABLE 170.000记录版本存在。您可以通过

gstat -r -t表db.fdb衡量这个| grep的版本

如果客户端“B”出现故障，记录的版本的数量没有任何更多的增长。客户端“A”是有罪的，冻结所有这些版本，强制服务器持有它。最后，如果客户端“A”出现故障（或者例如防火墙规则切断了所有挂起的连接），Firebird很乐意开始摆脱现在无用的记录版本。这“扫”？？编程不良（甚至2.5.2）cpu仅为3％< 10.000版本/分钟，因此该表的性能约为2％。

来源

2014-01-28 20:50:57

FirebirdSQL查询在12:00下午卡住

回答

相关问题