Firebird 是否适合生产工作？ [关闭]答案

【问题标题】：How suitable is Firebird for production work? [closed]Firebird 是否适合生产工作？ [关闭]
【发布时间】：2012-04-19 17:39:24
【问题描述】：

我听说过在生产系统中使用 Firebird 数据库的两大反对意见：不支持复制，以及无法恢复备份的严重问题。但那是不久前的事了，我知道 Firebird 已经（并且仍在）不断改进和发展。

那么今天这些问题的相关性有多大，是否有任何其他破坏交易的因素会使其在生产系统中不必要地难以使用？

【问题讨论】：

恢复备份有什么问题？
@MarkRotteveel （仍然是？）可以创建无法恢复的备份，即 IIRC 的一种方法是将 NOT NULL 约束添加到具有 NULL 的列。 DDL 成功，但如果您在用有效值替换 NULL 之前进行备份，则从该备份恢复失败。
@ain 使用-NO_VALIDITY 恢复应该会有所帮助。（之后唯一的问题是您需要自己重新添加这些约束）。
顺便说一句，只有在手动编辑系统表的情况下才能为包含空数据的列添加非空约束，但从未推荐这样做。
@WarmBooter：还有第二种方法可以解决这个问题。创建表 FOO。插入 FOO（数据）。 ALTER TABLE FOO 添加列栏不为空。突然你有问题了。在某些数据库中，除非表有 0 行或者您在 ALTER TABLE 中提供了默认值，否则会引发错误，但 Firebird 接受它。

【解决方案1】：

【讨论】：

【解决方案2】：

除了我个人遇到的不可恢复的备份情况（必须对其进行测试！）和复制之外，Firebird 还缺少许多高级功能，例如：

此外，每个表的行数和索引的宽度也有一些限制，但这不是一个固定的数字——它取决于页面和行的大小。我记得行数限制通常在数十亿。

*(使用“小心写入”，Firebird 数据库文件本质上是一个事务日志和数据库文件，因此在崩溃时它应该直到最后提交的事务没有损坏。这也意味着重启后的恢复时间为 0 .)

【讨论】：

【解决方案3】：

从 2000 年发布的第一个版本（0.9 beta）开始，我们在生产中的金融应用程序（2 层）中使用 Firebird 作为数据库服务器。

复制 - 我们为此使用自己的内部解决方案，因此我对可用的 3d 派对服务无话可说。

至于 无法恢复备份的严重问题。。我已经有一段时间没有遇到这些问题了。在可以备份但不能恢复的情况下，可以修改数据库结构。但是，如果不删除原始数据库，则始终可以修复数据或元数据，从而使备份/恢复例程再次为该数据库工作。

唯一要遵循的规则：还原时不要覆盖原始数据库。始终在新文件中恢复备份。

【讨论】：

【解决方案4】：

即使您的数据库或备份（firebird）崩溃 - 也有团队按需进行恢复（损坏的备份或损坏的数据库）：http://ib-aid.com/team/

【讨论】：