我正在使用Firebird，但最近数据库变得非常认真。 实际上有很多delete语句在运行，以及更新/插入，并且数据库文件大小增长得非常快。 在大量删除记录之后，数据库大小不会减少，更糟糕的是，我感觉实际上查询速度有所降低。 为了解决这个问题，我们已经涉及了每日备份/恢复过程，但由于是时候完成了 - 我可以说使用Firebird真的很令人沮丧。
欢迎任何有关变通方法或解决方案的想法。
同样，我正在考虑转换到Interbase，因为我从朋友那里听说它没有这个问题 - 就是这样吗？
答案 0 :(得分：9)
我们在Firebird上有很多庞大的数据库，但从未出现数据库增长问题。是的，每次删除或更新记录时，旧版本的记录都将保留在文件中。但是垃圾收集者迟早会把它一扫而光。一旦两个进程相互平衡，数据库文件将仅增加新数据和索引的大小。
作为防止数据库大量增长的一般预防措施，请尽量缩短交易时间。在我们的应用程序中，我们使用一个READ ONLY事务来读取所有数据。此交易在整个应用程序生命周期内开放。对于每批插入/更新/删除语句，我们使用简短的单独事务。
数据库操作的减少可能是由过时的指数统计数据引起的。在这里，您可以找到有关如何重新计算所有索引的统计信息的示例：http://www.firebirdfaq.org/faq167/
答案 1 :(得分：7)
检查您的应用程序中是否有未完成的事务。如果事务已启动但未提交或回滚，则数据库将在最早的活动事务之后为每个事务创建自己的修订。
您可以检查数据库统计信息（gstat或外部工具），最旧的事务和下一个事务。如果这些数字之间的差异持续增长，那么您就会遇到卡住的交易问题。
还有监控工具检查情况，我使用的是Sinatica Monitor for Firebird。
编辑：此外，数据库文件不会自动缩小。它的一部分被标记为未使用（扫描操作后）并将被重复使用。 http://www.firebirdfaq.org/faq41/
答案 2 :(得分：6)
被删除的记录占用的空间将在Firebird垃圾收集后立即重新使用。 如果GC没有发生（事务问题？），DB将继续增长，直到GC能够完成它的工作。
此外，当您在表中执行大量删除时存在问题（例如：数百万条记录），该表中的下一个选择将“触发”垃圾收集，并且性能将下降，直到GC完成。解决这个问题的唯一方法是在服务器使用不当时进行大量删除，然后运行扫描，确保没有卡住的事务。
另外，请记住，如果您使用“标准”表来保存临时数据（即：多次插入和删除信息），则在某些情况下可能会损坏数据库。我强烈建议您开始使用全局临时表功能。