KDV, 01.02.1998. last updated 23.12.2004, 03.04.2006, 20.09.2006, 12.03.2007, 20.01.2009, 10.08.2009.
InterBase и Firebird для работы с базами данных от разных версий IB/FB использует понятие ODS (OnDisk Structure, или "формат базы данных"), номер которого меняется от версии к версии. Это позволяет серверу работать с базами данных от предыдущих версий IB (так называемый Y-valve, или "мост"), и одновременно с новыми.
Узнать версию ODS можно выполнив команду
gstat -h <database>
в выводе будет строка "ODS version", сопровождаемая номером.
примечание: эту команду gstat выполняет считывая первую (нулевую) страницу базы данных самостоятельно, прямо из файла БД, не обращаясь к серверу. Если версия ODS будет "непонятна" конкретной версии gstat (от любой версии InterBase/Firebird), то gstat выдаст ошибку, из которой все равно будет видна версия ODS базы данных. В частности, gstat от InterBase 4 при обращении к базе данных от Firebird 2 выдал следующее:
Wrong ODS version, expected 8, encountered 32779?
что в переводе означает "Неверная версия ODS, ожидалась 8, обнаружено 32779
(для того, чтобы отличить базы Firebird 2.x от баз InterBase 7.x Firebird прибавляет "знак" (старший бит) к значению ODS. Т.е. в 16-ричном виде 32779 это будет 800B, что означает ODS 11).
или, например, тот же gstat выдает при обращении к базе от InterBase 2009:
Wrong ODS version, expected 8, encountered 13?
исключение составляет ситуация, когда gstat не может найти interbase.msg/firebird.msg. В этом случае сообщение будет следующим:
can't format message 21:3 -- message file <path>...msg not found
В этом случае для исправления проблемы достаточно поместить требуемый файл в ожидаемый gstat-ом путь.
Вот список основных ODS для каждой версии Interbase и Firebird:
| Версия | Основная версия ODS | Может работать с ODS |
| InterBase 4.0/4.1 | 8.0 | ... |
| InterBase 4.2 | 8.2 | 8.2 |
| InterBase 5.0/5.1 | 9.0 | 8.2 |
| InterBase 5.5 | 9.1 | 8.2 |
| InterBase 5.6 | 9.1 | 8.2 |
| InterBase 6.01 Firebird 1.0 Yaffil |
10.0 | 9.0/9.12 |
| Firebird 1.5 | 10.1 | 9.0/9.12, 10.0 |
| InterBase 7.03 | 11.0 | 10.0 |
| InterBase 7.1 | 11.1 | 10.0 |
| InterBase 7.54 | 11.2 | 10.0 |
| Firebird 2.0 | 11.05 | 10.x |
| Firebird 2.1 | 11.15 | 10.x, 11.0 |
| Firebird 2.5 | 11.26 | 10.x, 11.x |
| InterBase 2007 | 12.0 | 11.x (InterBase 7.x) |
| InterBase 2009 | 13.1 | 12.0 |
| InterBase XE | 15.07 | 13.1 |
1 - сюда же относятся InterBase 6.5, Firebird 1.0, Yaffil. Они могут добавлять незначительные изменения в отношении системных таблиц (например, дополнительные индексы), которые не влияют на совместимость между разными версиями серверов.
2 - из-за отличий в версиях BLR, используемых IB 6 и IB 5.x, не рекомендуется полноценно работать с базой ODS 9 из IB 6 (особенно, если предполагается возврат на IB 5.6), в частности модифицировать триггеры и процедуры. То же самое относится к рестору под 5.6 бэкапа, с БД которого успели поработать (меняли процедуры и триггеры) в 6.0 и выше.
3 - подробно о функциональности IB 7 см. в документе.
4 - перед установкой IB7.5 обязательно нужно сделать backup, даже если вы работаете на 7.0/7.1 с базой ODS 11.0/11.1. IB 7.5 автоматически обновит ODS до 11.2, что не гарантирует обратную работоспособность 7.0/7.1 с этой ODS. В ODS 11.2 как минимум поддерживаются индексы со специальным хранением null, новые конструкции SQL, и т.п. Подробнее см. документ.
5 - Firebird 2.0 имеет ODS 11.0, однако эта версия ODS не совпадает с ODS 11.x от InterBase 7.x. Firebird никакой версии не работает с базами формата InterBase ODS 11.x, и наоборот - никакая версия InterBase не поддерживает формат Firebird 2.0 ODS 11.0. В данном случае никаких опасений по поводу "порчи базы не тем сервером" нет.
6. ODS 11.2 Firebird 2.5 несовместима с Firebird 2.1 и 2.0. То есть, базы от Firebird 2.5 не могут быть открыты Firebird версий 2.0 и 2.1.
7. Где ODS 14? никто не знает.
примечание: при backup в файл бэкапа пишется номер версии gbak для того, чтобы можно
было произвести restore версией gbak не ниже текущей. При restore ODS базы
данных будет определяться уже версией сервера, а не версией gbak, т.к. только
сервер создает базу данных, а gbak при restore всего-лишь ее наполняет метаданными
и данными. Таким образом, если на сервере Firebird 1.5 сделать restore утилитой
gbak от InterBase 7.1, база данных будет иметь формат ODS 10.1, а не 11.1.
При переходе с IB 7 на FB 1.5 или обратно, если использовалась только общая функциональность (IB 6, и без специфики FB 1.5 или IB 7.x), достаточно сделать backup одним сервером, и restore другим.
примечание: соответственно, бэкап произведенный на конкретной версии сервера, можно восстановить на сервере младшей версии, используя утилиту gbak от старшей версии. Например: БД создана или восстановлена в 6.0. Делается бэкап. для его рестора на сервере 5.6 надо использовать gbak от 6.0. Нужно добавить, что смысл таких действий в большинстве случаев сомнителен.
Разница между ODS может быть как существенной, так и незначительной (подробно
отличия ODS можно увидеть в файле jrd\ods.h
исходных текстов и файлах ods*.gdl). Например, ODS
9.0 по сравнению с 8.x поддерживает декларативную ссылочную целостность,
роли SQL, сборку мусора в индексах. А ODS 9.1 отличается от 9.0 только ускоренной
работой с constraint (добавлен индекс на одну из системных таблиц).
"Мост" предназначен для поддержки версии ODS, меньшей текущей на 1. Например,
IB 5.x работает с базами данных ODS 8.x. Базу данных с ODS 8.x можно "превратить"
в базу данных с ODS 9.x только путем backup/restore.
Если версии 4.x и 5.x поддерживают разные ODS при помощи механизма Y-valve,
т.е. когда для соответствующей ODS выбирается способ работы с данными, то версия
6.0 может работать только с ODS 10. Поэтому при переходе на 6.0 базы данных
можно использовать только после backup в 4.x/5.x и restore в 6.0.
примечание: подробно по переходу на IB 6 см. документ.
Версия IB Обновление ODS 4.2 8.0 -> 8.2 5.0 8.0 -> 8.2 5.1 8.0 -> 8.2 5.5 8.0 -> 8.2, 9.0->9.1 5.6 8.0 -> 8.2, 9.0->9.1 6.0 9.0 -> 9.1 7.1 11.0 -> 11.1 7.5 11.0/11.1 -> 11.2
примечание: Firebird 1.5 для базы ODS 10.0 обновит ее до 10.1. Одно время была ситуация, когда Firebird не мог обновить базу до ODS 10.1, если там уже был создан дополнительный индекс по одной из системных таблиц. Сейчас такой проблемы нет.
Это означает, что при переходе на IB, версия которой отличается от текущей
младшим номером, возможна обратная несовместимость с базами данных. Например:
Вы работаете с IB 4.0 (ODS 8.0), затем устанавливаете IB 4.2 или 5.x. При
первом-же обращении к базе данных ее ODS будет автоматически обновлен до
8.2. Если Вам чем-то не понравится IB 4.2 или 5.x, то после их деинсталляции
и установки IB 4.0 может оказаться, что IB откажется от работы с новой
ODS. Точно так-же gbak не может восстановить резервную копию базы данных,
если ее версия больше, чем версия gbak.
ODS 10 совершенно несовместима с предыдущими ODS, т.к. в IB 6.0 введены
новые типы данных.
Чтобы не попасть в "капкан" подобной ситуации, при любом переходе с
версии на версию необходимо предварительно делать backup всех баз данных.
Firebird 1.5 и InterBase 7.x уже достаточно сильно отличаются по функциональности. Поэтому смысл в таком переходе есть если
а) вы не пользовались специфической функциональностью Firebird 1.5 или InterBase 7.x
б) вы пользовались специфической функциональностью
Firebird 1.5 или InterBase 7.x, но готовы все переделать под новый сервер.
На сегодняшний момент для ряда баз это уже практически неосуществимая задача. И дальше, с появлением все новой функциональности в Firebird 2.0 и InterBase 2007 расхождения будут еще больше.
Первое, что нужно сделать, это извлечь метаданные из БД в скрипт и попробовать создать новую БД под новым сервером из этого скрипта (isql -x db.gdb, isql -i script.ddl). Так вы обнаружите все несоотвествия и несовместимости в метаданных.
Если все прошло нормально, можно делать backup/restore. В соответствии с изложенным в предыдущих разделах нужно
после чего нужно выполнить restore полученного backup под новым сервером.
Если backup/restore прошел, и создание метаданных БД из скрипта также прошло, то нужно быть готовым к несовместимости BLR. BLR - это псевдокод в виде которого хранятся объекты БД - процедуры, триггеры, view и т.п. При restore, разумеется, эти объекты не перекомпилируются. И, в Firebird и InterBase константы языка BLR могут не совпадать, даже при совершенно идентичном тексте SQL процедур, триггеров и view. Вероятность такого несовпадения мала, но ее не стоит исключать.
Если вы заметили, что процедура или триггер под новым сервером работает как то "не так" - перекомпилируйте этот объект.
Если backup/restore не проходит, тогда единственный путь - это
Если вы сделали backup баз данных перед переходом на новую версию IB, то никаких проблем с возвратом к предыдущей версии нет. Однако если это не так (backup нет), или по другим причинам, вернуть базы данных в предыдущий формат ODS все-таки возможно. Это делается при помощи двух компьютеров с серверами IB/FB разных версий, или на одном компьютере с поочередно запускаемыми версиями IB/FB (подробнее об этом - здесь).
Самый простой вариант уже изложен выше. Если вы не использовали никакой специфической функциональности сервера версии X, то вы можете легко перейти на версию X-1 следующим способом:
Если бэкап в пункте 1 не проходит, можно попробовать другой способ:
сервер версии X-1 при восстановлении создаст базу в своем родном формате, который, очевидно, вам и нужен.
При бэкапе или восстановлении бэкапа рекомендуется использовать формат команды
gbak -b localhost:c:\dir\db.gdb ...
т.е. обращаться к серверу по tcp, т.к. локальный протокол может быть несовместим между серверами, и без указания localhost или бэкап или восстановление не пройдет.
Процесс переноса базы с сервера X на X-1 пройдет успешно только при одном условии - метаданные базы данных, которой делается backup, не должны содержать никаких особенностей новой версии. Например,
Операцию можно выполнить или на одном компьютере, запуская сервера поочередно, или на разных компьютерах. В этом случае желательно, чтобы между серверами было сетевое соединение с максимальной пропускной способностью (100МБит), т.к. backup по сети выполняется намного дольше, чем backup на винчестер.
Если восстановление БД таким образом не прошло, остается единственный способ - извлечение метаданных в виде скрипта из исходной базы, затем создание базы из скрипта под сервером предыдущей версии, и копирование данных с одного сервера на другой (утилитой IBPump, например).
примечание: перенос баз данных диалекта 3 в диалект 1 возможен только через скрипт и копирование данных утилитой IBPump. В любом случае такая процедура требует тщательной проверки совместимости переносимых данных.