Wszystkie wersje struktury dyskowej (ODS) Firebird i InterBase

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

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

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

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

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

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

Пользователь и пароль здесь не нужны, потому что 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 пытается открыть базу данных 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

Здесь вы можете увидеть таблицу версий 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 не может быть обновлена на лету. Вы можете обновить её только с помощью резервного копирования/восстановления.

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

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

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

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

Как вернуться к предыдущей версии 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 таблиц и несколькими тысячами специальных SQL-запросов, менее чем за 3 месяца.

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