Усі версії Firebird та InterBase On-Disk-Structure (ODS)
Автор: Дмитрий Кузьменко, 24 травня 2016 р.
Що таке номер On-Disk Structure (ODS)
Простими словами, ODS (On-Disk Structure) - це номер формату файлу бази даних для конкретної версії Firebird або InterBase RDBMS.
Майже всі версії використовують так званий «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 намагається відкрити базу даних 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 | Може працювати з 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) і знайти відмінності між 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, виконавши такі кроки:
- Візьміть утиліту gbak із сервера X-1 і зробіть за допомогою неї резервну копію на сервері X
- Перенесіть резервну копію на сервер X-1 і відновіть її
Якщо на кроці 1 виникнуть проблеми, можна спробувати:
- Зробіть резервну копію на сервері X за допомогою його gbak
- Скопіюйте утиліту gbak із X на X-1
- Відновіть резервну копію на 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]