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