Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
миграция interbase -> firebird 2.5
38 views
Skip to first unread message
Anton Gorlov
Jan 26, 2018, 4:15:00 AM1/26/18
to
Привет 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 -FIX_FSS_METADATA 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:*#] [#_Злой СисОп_#] [*Heavy Metal!*] [*_Усачи_*]
Народ- кому-нибудт приходилсоь мигрировать с 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 -FIX_FSS_METADATA 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:*#] [#_Злой СисОп_#] [*Heavy Metal!*] [*_Усачи_*]
Oleg Levkin
Jan 28, 2018, 4:15:00 PM1/28/18
to
Я рад пообщаться с тобой, 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 -FIX_FSS_METADATA 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~~~~
Однажды, сидя за компутером и покуривая бамбук, увидел я как 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 -FIX_FSS_METADATA 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~~~~
Anton Gorlov
Jan 29, 2018, 3:45:00 AM1/29/18
to
Привет 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.
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 из базок..не основных.. включив
FIX_FSS_METADATA и указав там win1251
влилось без каких либ ошибок, но смущает то что в UDF на восстановленной базе
функций оказалось почему-то больше чем на исходной
http://stlk.name/scr/src.jpg
http://stlk.name/scr/dst.jpg
Да ещё и подсвечены, как не живые что ли..
В описании этих UDF
==== заливка "Fake Clipboard" ====
DECLARE EXTERNAL FUNCTION RDB$GET_CONTEXT
VARCHAR(80) NULL,
VARCHAR(80) NULL
RETURNS VARCHAR(255) FREE_IT
ENTRY_POINT 'get_context' MODULE_NAME 'system_module';
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>> Invalid metadata detected. Use -FIX_FSS_METADATA option.
AG>> Malformed string.
AG>> Exiting before completion due to errors.
AG>> ==== конец "Fake Clipboard" ====
OL> Знакомо. В одной служебной таблице Interbase считает, что это поле
AG>> Malformed string.
AG>> Exiting before completion due to errors.
AG>> ==== конец "Fake Clipboard" ====
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 из базок..не основных.. включив
FIX_FSS_METADATA и указав там win1251
влилось без каких либ ошибок, но смущает то что в UDF на восстановленной базе
функций оказалось почему-то больше чем на исходной
http://stlk.name/scr/src.jpg
http://stlk.name/scr/dst.jpg
Да ещё и подсвечены, как не живые что ли..
В описании этих UDF
==== заливка "Fake Clipboard" ====
VARCHAR(80) NULL,
VARCHAR(80) NULL
RETURNS VARCHAR(255) FREE_IT
ENTRY_POINT 'get_context' MODULE_NAME 'system_module';
==== конец "Fake Clipboard" ====
0 new messages