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