Все версии Firebird и InterBase On-Disk-Structure (ODS)

Автор: Дмитрий Кузьменко, 24 мая 2016 г.

Что такое номер ODS (On-Disk Structure)

Простыми словами, ODS (On-Disk Structure) - это номер формата файла базы данных для конкретной версии Firebird или InterBase RDBMS.

Почти все версии используют так называемый «Y-valve» для поддержки текущего ODS и некоторых старых ODS. Это позволяет серверу работать с файлами баз данных предыдущих версий и упрощает переход со старого сервера на новый. Но есть некоторые ограничения, о которых будет рассказано далее.

Вы можете узнать ODS вашей базы данных, выполнив следующую команду:

Code

gstat -h имя_файла_базы_данных

Пользователь и пароль здесь не нужны, потому что gstat с опцией -h просто читает физическую часть базы данных (страницу заголовка, номер 0).

Если gstat не сможет понять прочитанную информацию, он покажет соответствующее сообщение - что он ожидал и что нашёл.

Например, если мы запустим gstat из InterBase 4 на базе данных Firebird 2, он покажет:

Code

Wrong ODS version, expected 8, encountered 32779?

Здесь вы видите номер ODS 32779 - это закодированное 11, со старшим битом, добавленным начиная с Firebird 2.0 (в шестнадцатеричном виде это будет 800B, где B = 11), чтобы избежать путаницы между базами данных InterBase и Firebird, потому что с определённого момента у них были одинаковые номера ODS, но очень разные форматы баз данных. Исключение из получения понятного сообщения - когда gstat не может найти firebird.msg или interbase.msg. Он покажет что-то вроде:

Code

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:

Code

unsupported on-disk structure for file ...; found 32779, support 10

Здесь вы можете увидеть таблицу версий ODS, начиная с InterBase 4.0 (1994).

Версия сервера	Основной номер 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	ODS 10.1 64-битного Firebird 1.5 несовместим с 32-битным ODS 10.1. Это единственная известная несовместимость формата базы данных между 32/64-битными версиями.
InterBase 7.0	11.0	10.0	Несовместим с ODS 11 Firebird 2.x
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	ODS 11 Firebird 2.0 несовместим с InterBase 7.x
Firebird 2.1	11.1	10.x/11.0	ODS 11 Firebird 2.0 несовместим с 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	Базу данных можно обновить с 13.0 до 13.1 с помощью gfix -upgrade с 13.0 или с помощью резервного копирования/восстановления
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 до более нового без уведомления. Это может привести к невозможности возврата к предыдущей версии. Например, если вы откроете базу данных с ODS 8.0 с помощью InterBase 4.2, он обновит ODS до 8.2, который не понимается InterBase 4.0/4.1. Таким образом, незначительное обновление ODS делает базы данных несовместимыми в пределах одной основной версии сервера. Это также справедливо для Firebird 2.5 и InterBase 7.5.

Чтобы избежать проблем с возвратом к предыдущей версии, мы рекомендуем делать резервные копии на текущей версии сервера даже перед незначительным обновлением версии сервера.

Разница между ODS (основным или незначительным) может быть огромной или небольшой. Если вам достаточно любопытно, вы можете открыть jrd\ods.h (Firebird open source) и найти различия между 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, миграция между последними версиями этих серверов затруднена.

В любом случае, если вы попытаетесь это сделать, вам нужно извлечь скрипт метаданных из базы данных, а затем попытаться создать новую базу данных из этого скрипта, используя тот же сервер.

Code

isql -x db.gdb …
isql -i script.ddl …

Это нужно сделать, чтобы проверить, есть ли в вашей базе данных какие-либо плохие старые метаданные или ошибки извлечения скрипта на используемом сервере. InterBase и Firebird хранят процедуры, триггеры и представления (и некоторые другие объекты) в скомпилированном виде (BLR - Binary Language Representation), и во время резервного копирования/восстановления метаданные не перекомпилируются (из SQL в BLR).

В этом случае, если база данных была создана давно и постоянно изменялась, для некоторых объектов может быть неправильный (старый) BLR. Эти объекты могут продолжать работать, но попытка их пересоздать (ALTER) может вызвать синтаксическую (или другую) ошибку.

Затем вы можете попытаться создать базу данных из исправленного скрипта на новом сервере. После того как вы исправите все несовместимости в этом скрипте, вы сможете перенести данные из старой базы данных в новую.

Даже если вы попытались сделать резервную копию на старом сервере и восстановить её на новом, и это сработало - никогда не доверяйте этому. Если ваша база данных содержит много объектов, вы не можете проверить их все сразу на новом сервере, поэтому ошибка появится позже.

Как вернуться к предыдущей версии Firebird или InterBase

Иногда вам может потребоваться выполнить даунгрейд и вернуться с нового сервера. Причины могут быть разными - внезапная ошибка в сервере, проблемы с производительностью и так далее.

Если вы сделали резервную копию перед обновлением сервера, проблем с возвратом не будет. Но если нет, вы столкнётесь с проблемой возврата с нового ODS на старый ODS.

Для этого вам понадобятся 2 компьютера с новым сервером и старым. Если вы не использовали никаких новых функций сервера X (версии InterBase или Firebird), вы можете вернуться к X-1, выполнив следующие шаги:

Возьмите утилиту gbak с сервера X-1 и сделайте с её помощью резервную копию на сервере X
Перенесите резервную копию на сервер X-1 и восстановите её

Если на первом шаге возникнут проблемы, вы можете попробовать:

Сделать резервную копию на сервере X с помощью его собственной gbak
Скопировать утилиту gbak с X на X-1
Восстановить резервную копию на X-1 с помощью gbak с X

Обратите внимание, что локальный протокол между серверами X и X-1 может быть несовместимым, поэтому лучше указывать имя сервера:

Code

gbak -b localhost:c:\dir\data.gdb

Результат будет успешным только при условии, что вы не изменяли никакие объекты базы данных на сервере X после обновления с X-1.

Вот примеры:

С 5.x на 4.2 - не должны использоваться роли и новая декларативная ссылочная целостность
С 6.x на 5.x - никаких изменений метаданных, так как 6.x использует новый формат BLR
С InterBase 7.x на Firebird - никаких логических (boolean) колонок и имён объектов длиннее 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 таблиц и несколькими тысячами ad hoc SQL-запросов, менее чем за 3 месяца.

Если у вас есть вопросы, пожалуйста, свяжитесь с нами: [email protected]