Firebird备份恢复令人沮丧,有没有办法避免它？

Question

我正在使用Firebird,但最近数据库变得非常认真.实际上有很多delete语句在运行,以及更新/插入,并且数据库文件大小增长得非常快.在大量删除记录之后,数据库大小不会减少,更糟糕的是,我感觉实际上查询速度有所降低.为了解决这个问题,我们已经涉及了每日备份/恢复过程,但由于是时候完成了 - 我可以说使用Firebird真的很令人沮丧.

• 任何有关变通方法或解决方案的想法都将受到欢迎.

• 同时,我正在考虑转换到Interbase,因为我从朋友那里听说它没有这个问题 - 是这样的吗？

Answer 1

我们在生产中有很多关于Firebird的庞大数据库,但从未遇到过数据库增长的问题.是的,每次删除或更新记录时,旧版本的记录都将保留在文件中.但是垃圾收集者迟早会把它一扫而光.一旦两个进程相互平衡,数据库文件将仅增加新数据和索引的大小.

作为防止数据库大量增长的一般预防措施,请尽量缩短您的交易时间.在我们的应用程序中,我们使用一个READ ONLY事务来读取所有数据.此交易在整个应用程序生命周期内开放.对于每批插入/更新/删除语句,我们使用短的单独事务.

数据库操作的减少可能是由过时的指数统计数据引起的.在这里,您可以找到如何重新计算所有索引的统计数据的示例:http://www.firebirdfaq.org/faq167/

Answer 2

检查您的应用程序中是否有未完成的事务.如果事务已启动但未提交或回滚,则数据库将在最早的活动事务之后为每个事务创建自己的修订.

您可以检查数据库统计信息(gstat或外部工具),最旧的事务和下一个事务.如果这些数字之间的差异持续增长,那么您就会遇到卡住的交易问题.

检查情况也有监控工具,我使用的是Sinatica Monitor for Firebird.

编辑:此外,数据库文件不会自动缩小.它的一部分被标记为未使用(扫描操作后)并将被重复使用.http://www.firebirdfaq.org/faq41/

Answer 3

被删除的记录占用的空间将在Firebird垃圾收集后立即重新使用.如果GC没有发生(事务问题？),DB将继续增长,直到GC能够完成它的工作.

此外,当您在表中执行大量删除时存在问题(例如:数百万条记录),该表中的下一个选择将"触发"垃圾收集,并且性能将下降,直到GC完成.解决这个问题的唯一方法是在服务器使用不当的时候进行大量删除,然后运行扫描,确保没有卡住的事务.

另外,请记住,如果您使用"标准"表来保存临时数据(即:多次插入和删除信息),则在某些情况下可能会损坏数据库.我强烈建议您开始使用全局临时表功能.