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

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

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

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

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

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

gstat -h database_file_name

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

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

Например, если мы запустим gstat из InterBase 4 на базе данных из 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 пытается открыть базу данных IntrBase 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

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

Обновление 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 с открытым исходным кодом) и найти различия между ODS. Например, ODS 9.0 по сравнению с 8.x имеет декларативную ссылочную целостность, SQL-роли, сборку мусора в индексах. Но ODS 9.1 отличается от 9.0 только одним индексом, добавленным к некоторой системной таблице.

Обратите внимание, что мажорную версию ODS нельзя обновить «на лету». Её можно обновить только с помощью backup/restore.

Миграция между 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 — Binary Language Representation), и во время backup/restore метаданные не перекомпилируются (из SQL в BLR).

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

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

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

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

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

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

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

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

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

1. Сделать резервную копию на сервере X, используя его gbak
2. Скопировать утилиту gbak с X на X-1
3. Восстановить резервную копию на X-1, используя gbak с X

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

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 — никаких логических столбцов и имён объектов длиннее 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]