所有Firebird和InterBase磁盘结构（ODS）版本
作者：Dmitry Kuzmenko，2016年5月24日
什么是磁盘结构（ODS）编号
简单来说，ODS（磁盘结构）是特定Firebird或InterBase RDBMS版本的数据库文件格式编号。
几乎所有版本都使用所谓的“Y-valve”来支持当前ODS和一些旧ODS。这允许服务器处理来自以前版本的数据库文件，并简化从旧服务器到新服务器的过渡。但有一些限制，将在后面描述。
您可以通过运行以下命令来查看数据库的ODS：
gstat -h database_file_name这里不需要用户和密码，因为带-h选项的gstat只读取数据库的物理部分（头页，编号0）。
如果gstat无法理解读取的信息，它将显示相应的消息–它期望什么，以及它发现了什么。
例如，如果我们从InterBase 4运行gstat来处理Firebird 2的数据库，它将显示：
Wrong ODS version, expected 8, encountered 32779?在这里，您看到ODS编号32779–这是编码后的11，自Firebird 2.0起添加了高位（十六进制为800B，其中B=11），以避免InterBase和Firebird数据库之间的混淆，因为从某个时间点起它们具有相同的ODS编号，但数据库格式却大不相同。当gstat找不到firebird.msg或interbase.msg时，会出现无法获得可理解消息的例外情况。它将显示类似：
can't format message 21:3 -- message file ...msg not found所以，这意味着您的Firebird或InterBase安装不正确，需要修复。
几个示例：
Wrong ODS version, expected 8, encountered 32779? - InterBase 4.x尝试打开Firebird 2.x数据库
Wrong ODS version, expected 8, encountered 13? - InterBase 4.x尝试打开InterBase 2009数据库
Wrong ODS version, expected 15, encountered 32779 - InterBase XE/XE3尝试打开Firebird 2.x数据库
Wrong ODS version, expected 11, encountered 11 - Firebird 2.x尝试打开InterBase 7.x数据库
Wrong ODS version, expected 11, encountered 15 - Firebird 2.x尝试打开InterBase XE/XE3数据库
有时您可能会收到来自服务器（而非gstat）的另一种消息，但含义相同。
例如，当Firebird 1.5服务器尝试打开Firebird 2.x数据库时：
unsupported on-disk structure for file ...; found 32779, support 10以下是自InterBase 4.0（1994年）以来的ODS版本表。
| 服务器版本 | 主要ODS编号 | 可处理的ODS | 备注 |
|---|---|---|---|
| InterBase 4.0/4.1 | 8.0 | ||
| InterBase 4.2 | 8.2 | 8.2 | InterBase 4.2强制将ODS 8.0升级到8.2 |
| InterBase 5.0/5.1 | 9.0 | 8.2 | InterBase 5.x强制将ODS 8.0升级到8.2 |
| InterBase 5.5/5.6 | 9.1 | 8.2 | |
| InterBase 6.0 Firebird 1.0 Yaffil 1.0 |
10.0 | 9.0/9.1 | 处理ODS 9.x是危险的，因为新的InterBase和Firebird使用新的元数据格式，InterBase 5.x无法识别 |
| Firebird 1.5 | 10.1 | 9.0/9.1/10.0 | 64位Firebird 1.5的ODS 10.1与32位ODS 10.1不兼容。这是已知的唯一32/64位版本之间数据库格式不兼容的情况。 |
| InterBase 7.0 | 11.0 | 10.0 | 与Firebird 2.x的ODS 11不兼容 |
| InterBase 7.1 | 11.1 | 10.0 | InterBase 7.5会将InterBase ODS 11.0/11.1升级到11.2，这对以前的版本（7.0/7.1）不兼容 |
| InterBase 7.5 | 11.2 | 10.0 | |
| Firebird 2.0 | 11.0 | 10.x | Firebird 2.0的ODS 11与InterBase 7.x不兼容 |
| Firebird 2.1 | 11.1 | 10.x/11.0 | Firebird 2.0的ODS 11与InterBase 7.x不兼容 |
| Firebird 2.5 | 11.2 | 10.x/11.x | ODS 11.2与Firebird 2.0/2.1不兼容。 |
| Firebird 3.0 | 12.0 | 不支持以前的ODS，仅支持12.0 | |
| Firebird 4.0 | 13.0 | 13.0 | |
| Firebird 5.0 | 13.1 | 13.0, 13.1 | 数据库可以通过gfix -upgrade从13.0升级到13.1，或通过备份/恢复 |
| InterBase 2007 | 12.0 | 11.x | |
| InterBase 2009 | 13.1 | 12.0 | |
| InterBase XE, XE3 | 15.0 | 13.1 | ODS 14在哪里？ |
| InterBase XE7 | 16.0 | 15, 13 | “当前”ODS可以在IBCONFIG中设置。这样XE7将使用指定的ODS（13、15、16）作为默认值创建数据库（包括恢复）。 |
ODS升级
每个服务器版本总是使用（除InterBase XE7外）其主要ODS编号来创建或恢复数据库。如果数据库的ODS小于服务器的主要ODS，服务器可以在支持该ODS的情况下处理该数据库。
有时服务器可能会在无通知的情况下将旧ODS升级到较新的版本。这可能导致无法返回到之前的版本。例如，如果您使用InterBase 4.2打开ODS 8.0的数据库，它会将ODS升级到8.2，而InterBase 4.0/4.1无法理解。因此，ODS的次要升级会使同一主要服务器版本内的数据库变得不兼容。这也适用于Firebird 2.5和InterBase 7.5。
为避免返回到之前版本的问题，我们建议即使在服务器版本进行次要升级之前，也要在当前服务器版本上进行备份。
ODS（主要或次要）之间的差异可能很大，也可能很小。如果您足够好奇，可以打开jrd\ods.h（Firebird开源）来查找ODS之间的差异。例如，ODS 9.0与8.x相比具有声明性参照完整性、SQL角色、索引中的垃圾回收。但ODS 9.1与9.0的区别仅在于添加到某个系统表的一个索引。
请注意，主要ODS版本无法即时升级。您只能通过备份/恢复来升级。
InterBase和Firebird之间的迁移
最新版本的Firebird（3.0）和InterBase（XE7）在功能和ODS方面差异很大。如前所述，最后一个共同的是ODS 10，自那时起（Firebird 2.0和InterBase 7.0）数据库格式就不兼容了。
因此，如果您没有使用自InterBase 7.x或Firebird 1.5以来的功能，迁移会更容易。如果使用了，迁移的复杂性将取决于您在数据库或管理过程中使用了多少功能。
目前，经过多年的Firebird和InterBase开发，在这些服务器最新版本之间进行迁移是困难的。
无论如何，如果您尝试这样做，您需要从数据库中提取元数据脚本，然后尝试使用同一服务器从该脚本创建新数据库。
isql -x db.gdb …
isql -i script.ddl …这需要完成，以检查您的数据库中是否有任何不良的旧元数据，或您使用的服务器中脚本提取的缺陷。InterBase和Firebird以编译形式（BLR - 二进制语言表示）存储存储过程、触发器和视图（以及其他一些对象），在备份/恢复期间元数据不会被重新编译（从SQL到BLR）。
在这种情况下，如果数据库是很久以前创建的并不断修改，某些对象可能存在不正确（旧）的BLR。这些对象可能仍然可以工作，但尝试重新创建（ALTER）可能会引发语法（或其他）错误。
然后您可以尝试在新服务器上从修正后的脚本创建数据库。在修复脚本中的所有不兼容性后，您可以将数据从旧数据库泵入新数据库。
即使您尝试在旧服务器上备份并在新服务器上恢复，并且成功了–也永远不要信任这一点。如果您的数据库包含大量对象，您无法一次性在新服务器上检查所有对象，因此错误会在稍后某个时间出现。
如何返回到Firebird或InterBase的先前版本
有时，您可能需要降级并从新服务器返回。原因可能各不相同–服务器中的突然错误、性能问题等。
如果您在服务器升级前进行了备份，返回将没有问题。但如果没有，您将面临从新ODS返回到旧ODS的问题。
为此，您需要两台计算机，一台运行新服务器，一台运行旧服务器。如果您没有使用服务器X（InterBase或Firebird的版本）的任何新功能，那么您可以按照以下步骤返回到X-1：
- 从服务器 X-1 获取 gbak 工具，并使用它在服务器 X 上制作备份
- 将备份传输到 X-1 服务器，并恢复它
如果在第 1 步遇到一些问题，你可以尝试
- 在服务器 X 上使用其自带的 gbak 制作备份
- 将 gbak 工具从 X 复制到 X-1
- 使用来自 X 的 gbak 在 X-1 上恢复备份
请注意，服务器 X 和 X-1 之间的本地协议可能不兼容，因此最好指定服务器名称：
gbak -b localhost:c:\dir\data.gdb只有在自你从 X-1 升级以来，没有更改服务器 X 上的任何数据库对象的情况下，结果才会成功。
以下是一些示例：
- 从 5.x 到 4.2 - 不得使用任何角色和新的声明式参照完整性
- 从 6.x 到 5.x - 不得有任何元数据更改，因为 6.x 使用新的 BLR 格式
- 从 InterBase 7.x 到 Firebird - 不得有布尔列和超过 31 个字符的对象名称。
- 从 Firebird 1.5 到 InterBase - 不得有 BIGINT 列以及触发器和存储过程中的新 SQL 扩展
- 从 Firebird 2.0 到 Firebird 1.5 - 不得使用任何新的 Firebird 2.0 功能。
- 依此类推
如果仍然存在无法修复的错误，唯一的方法是在 X-1 服务器上根据 SQL 脚本创建数据库并泵送数据。
Firebird 迁移服务
迁移通常是一项复杂的任务，尤其是对于被原始开发者遗弃的旧版 Firebird 数据库。我们公司为复杂的 Firebird 数据库提供全面的迁移服务。常规费用为 2900 美元。
例如，我们曾迁移过一个 SQL 脚本大小为 55 兆字节的数据库，其中包含超过 5000 个存储过程、1000 张表和数千个临时 SQL 查询，用时不到 3 个月。
如果您有任何问题，请联系我们 [email protected]