миграция interbase -> firebird 2.5

Anton Gorlov написал(а) к All в Jan 18 11:39:22 по местному времени:

Привет All!

Народ- кому-нибудт приходилсоь мигрировать с interbase на firebird?
Да оба сервера крутятся под эхотагом.


Дано большая базка на ibase. О себе говорит
==== заливка "Fake Clipboard" ====

SQL> show version;

ISQL Version: LI-V10.0.0.304
InterBase/x86/linux Intel (access method), version "LI-V10.0.0.304"
InterBase/x86/linux Intel (remote server), version "LI-V10.0.0.304/tcp (dbs-01)/P15"
InterBase/x86/linux Intel (remote interface), version "LI-V10.0.0.304/tcp (dbs-01)/P15"
on disk structure version 15.0
==== конец "Fake Clipboard" ====

Бекап gback создаёт бинарый и соотвественно влить его в firebird нельзя.

Далее попробовал к базе цепануться http://ibexpert.net/ibe/
Родной либой firebird к базе оно не цепляется, подцепиться удалось только воспользоdавшись либой (gds32.dll) из поставки embarcadero.

Однако если в этой утилитке сделать дамп, подключившись к исходной базе через либу от embarcadero,а к "новой" родной либой от firebird то получаю ошибку

==== заливка "Fake Clipboard" ====
[11:53:01] gbak:do not recognize table attribute 18 -- continuing
IBE: Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
Invalid metadata detected. Use -FIXFSSMETADATA option.
Malformed string.
Exiting before completion due to errors.
==== конец "Fake Clipboard" ====

Если при восстановлении поставить, как и просят крыжики "FIX mailformed UNICODE_FSS DATA/METADATA" собственно ошибка остаётся таже самая.
При этом не восстанавливается на сколько вижу только данные таблиц,сама структура создаётся.

Данные из каждой таблицы по отдельности удаётся вытащить, только если открывать каждую табличку и делать из неё экспорт в скрипт (аля SQL на выходе).. но тту пробьема с другой стороны.. таблиц свыше 400...и в некотрых таблицах до неск миллионов записей.. + есть FK (FOREIGN KEY)

Вот и вопрос как же перетащить базку в firebird. Диалект 1.





С уважением. Anton aka Stalker

Linux Registered User #386476
[#TEAM:*#] [#Злой СисОп_#] [*Нeavy Metal!*] [*_Усачи]
--- GoldED+/LNX 1.1.5-b20160322

Oleg Levkin написал(а) к Anton Gorlov в Jan 18 22:43:30 по местному времени:

Я рад пообщаться с тобой, Anton!

Однажды, сидя за компутером и покуривая бамбук, увидел я как 26 Янв 2018 Anton Gorlov и All травили байки про миграция interbase -> firebird 2.5:
AG> ISQL Version: LI-V10.0.0.304
AG> InterBase/x86/linux Intel (access method), version "LI-V10.0.0.304"
AG> InterBase/x86/linux Intel (remote server), version "LI-V10.0.0.304/tcp
AG> (dbs-01)/P15" InterBase/x86/linux Intel (remote interface), version
AG> "LI-V10.0.0.304/tcp (dbs-01)/P15" on disk structure version 15.0
AG> ==== конец "Fake Clipboard" ====
AG> Бекап gback создаёт бинарый и соотвественно влить его в firebird нельзя.
Ты бэкап для миграции каким gbak'ом делал? Если целевой сервер - firebird, то gbak нужно брать от него и им проводить операции бэкапа/восстановления. Хотя в твоем случае не поможет: форматы хранения данных Firebird и Interbase к версиям, которые у тебя установлены уже настолько разные, что для миграции нужно пользоваться сторонними утилитами, а не серверными.

AG> ==== заливка "Fake Clipboard" ====
AG> [11:53:01] gbak:do not recognize table attribute 18 -- continuing
AG> IBE: Unsuccessful execution caused by system error that does not preclude
AG> successful execution of subsequent statements.
AG> Invalid metadata detected. Use -FIXFSSMETADATA option.
AG> Malformed string.
AG> Exiting before completion due to errors.
AG> ==== конец "Fake Clipboard" ====
Знакомо. В одной служебной таблице Interbase считает, что это поле должно быть char[31] (и пишет он туда символьную строку), а Firebird считает, что в этом поле должен быть smallint (о чем я писал в верхней квоте), вот ты и получаешь данный эффект.
Для твоей задачи нужно поднять Interbase до ближайшей стабильной версии (в твоем случае: 10.0.5.595), создать скрипт генерации метаданных и проверить, что он в Firebird выполняется без ошибок, а данные перекачать IBPump'ом.
Подробное руководство по миграции читать тут: http://www.ibase.ru/prevver/#6

За SIMM прощаюсь, пишите письма
Oleg
ин зе хоум

Team [Квакеров&Думеров - Давить!] [Мультфильмы - RULEZ FOREVER!]

... Я те доставлю райское наслаждение :-E~~~~
--- Модный таракан/W32 1.1.5

Anton Gorlov написал(а) к Oleg Levkin в Jan 18 11:20:38 по местному времени:

Привет Oleg!

28 янв 18 года (а было тогда 22:43)
Oleg Levkin в своем письме к Anton Gorlov писал:

OL> Ты бэкап для миграции каким gbak'ом делал? Если целевой сервер -
OL> firebird, то gbak нужно брать от него и им проводить операции
OL> бэкапа/восстановления. Хотя в твоем случае не поможет: форматы
OL> хранения данных Firebird и Interbase к версиям, которые у тебя
OL> установлены уже настолько разные, что для миграции нужно пользоваться
OL> сторонними утилитами, а не серверными.

Бэкап делал из утилиты ibexpert, подключив либу от interbase.
NТо что нативным методом не получится был о ясно изначально.


AG>> ==== заливка "Fake Clipboard" ====
AG>> [11:53:01] gbak:do not recognize table attribute 18 -- continuing
AG>> IBE: Unsuccessful execution caused by system error that does not
AG>> preclude successful execution of subsequent statements.
AG>> Invalid metadata detected. Use -FIXFSSMETADATA option.
AG>> Malformed string.
AG>> Exiting before completion due to errors.
AG>> ==== конец "Fake Clipboard" ====

OL> Знакомо. В одной служебной таблице Interbase считает, что это поле
OL> должно быть char[31] (и пишет он туда символьную строку), а Firebird
OL> считает, что в этом поле должен быть smallint (о чем я писал в верхней
OL> квоте), вот ты и получаешь данный эффект. Для твоей задачи нужно
OL> поднять Interbase до ближайшей стабильной версии (в твоем случае:
OL> 10.0.5.595), создать скрипт генерации метаданных и проверить, что он в
OL> Firebird выполняется без ошибок, а данные перекачать
OL> IBPump'ом. Подробное руководство по миграции читать тут:
OL> http://www.ibase.ru/prevver/#6

Обновить не судьба.
В общем всё таки удалсоь влить данные от 1 из базок..не основных.. включив FIXFSSMETADATA и указав там win1251
влилось без каких либ ошибок, но смущает то что в UDF на восстановленной базе функций оказалось почему-то больше чем на исходной

http://stlk.name/scr/src.jpg
http://stlk.name/scr/dst.jpg

Да ещё и подсвечены, как не живые что ли..
В описании этих UDF

==== заливка "Fake Clipboard" ====
DECLARE EXTERNAL FUNCTION RDB$GET_CONTEXT
VARCНAR(80) NULL,
VARCНAR(80) NULL
RETURNS VARCНAR(255) FREE_IT
ENTRYPOINT 'get_context' MODULE_NAME 'systemmodule';
==== конец "Fake Clipboard" ====





С уважением. Anton aka Stalker

Linux Registered User #386476
[#TEAM:*#] [#Злой СисОп_#] [*Нeavy Metal!*] [*_Усачи]
--- GoldED+/LNX 1.1.5-b20160322