Усі версії 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 | Може працювати з 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]