перенос данных с ib7.5 на firebird 2.0.1

Методы, механизмы и инструментарий для репликации

Модератор: kdv

Ответить
vortex
Сообщения: 9
Зарегистрирован: 17 июн 2007, 21:01

перенос данных с ib7.5 на firebird 2.0.1

Сообщение vortex » 02 июл 2007, 21:30

Есть база на 15 Гб в 1 диалекте под ib 7.5. Подправил метадату, выгрузил. Из скрипта заливается в firebird-е без проблем. Но backup/restore-ом перенести базу не удается, получаю при ресторе error на тему BLR offset. Это уже после того как метадата закоммитилась и в логе бегут надписи о раздаче прав юзеру SYSDBA на объекты БД (это какие-то системные таблицы не ресторятся?). Лога сейчас нет под рукой, могу воспроизвести и выложить, если есть решения для переноса через b/r.

Пока есть мысть просто перегнать данные из одной базы в другую, хотя на 15 гигах наверное будет не быстро.... Какой инструмент взять? Нужна поддержка блобов и максимально быстрый перенос. Здесь http://ibase.ru/d_tools.htm нашел раздел с утилитами, но ни одной не пользовался. Посоветуйте плз, что из этого пошустрее работает. Если конечно с b/r никак...

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 02 июл 2007, 22:41

оно и не должно через b/r переноситься, в общем случае...

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 03 июл 2007, 01:49

Создай скрипт со всеми процедурами\триггерами\вьями и т.п.
Убей их в оригинальной БД
Бекап-рестор
Накат скрипта

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 03 июл 2007, 09:51

О как. Экстремально :D
kdv обычно DataPump советует.

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 03 июл 2007, 13:22

ibpump, а не datapump. в любом случае, все это описано в
www.ibase.ru/devinfo/prevver.htm

vortex
Сообщения: 9
Зарегистрирован: 17 июн 2007, 21:01

Сообщение vortex » 07 июл 2007, 23:50

Всем спасибо за советы, но кажется обошлось малой кровью, т.е. база сресторилась под FB. Отдельное спасибо hvlad, правда я не стал дропать процедуры, а просто "деактивировал" их через ibexpert, закомментарив тело процедур и триггеров. В ресторенной под FB базе они активировались и перекомпилировались без проблем.

Не без проблем правда прошел сам рестор, в связи с чем завел соответствующий топик:
http://forum.ibase.ru/phpBB2/viewtopic.php?p=22669

Хочется услышать "помощь зала".

vortex
Сообщения: 9
Зарегистрирован: 17 июн 2007, 21:01

Сообщение vortex » 08 июл 2007, 14:11

WildSery, а в чем кстати экстрим? Сначала как-то не обратил внимания на эту ремарку, теперь задумался. У нас вопрос уперся в лицензирование и в ряд проблем с которыми неизвестно как бороться (на 5.6 не проявлялись, зато на 7.5 вылезли во всей красе). А без наличия лицензии саппорт особо нашими проблемами не озадачишь. Посмотрел графики производительности (tpc-c), вроде как 2.0 прилично опережает 1.5 в обоих архитектурах, поэтому на ней и остановился, т.к. в базе порядка 150-170 тысяч транзакций в день. Или с этой веткой есть реальные проблемы?

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 09 июл 2007, 09:52

vortex писал(а):WildSery, а в чем кстати экстрим?
Мой комментарий никоим образом не относился к переходу, тобой задуманному, а только к способу, предложенному Владом :)

VerLeon
Сообщения: 44
Зарегистрирован: 24 ноя 2007, 08:43

Сообщение VerLeon » 11 мар 2008, 09:04

а вот этот метод с b/r с предварительным убиением процедур и триггеров не канает при миграции на FB 2.1?
Попробовал и получил вот что:
при ресторе каждой таблицы (т.е. еще метаданных):

gbak:restoring table CARDASRTATTRIBSP
gbak:do not recognize table attribute 18 -- continuing

но идет дальше. А потом:
gbak:restoring table SMP_STATES
IBE: Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
string truncated.

Ничего особенного в этой таблице не нашел, но судя по всему срубился он фатально опять на этом загадочном 18-м атрибуте (кстати, что это?)
Повторюсь - это еще на этапе восстановления метаданных.
Исходная база - IB 7.5.1, ODS 11.2.

Просто метод заманчивый, мне кажется он быстрее, чем перекачка DataPump'ом, а лично мне скорость очень критична (в перспективе маячит миграция баз размером ~100Гб).
Впрочем сравнить по скорости не получилось вот.

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 11 мар 2008, 10:41

Бекапь gbak'ом от FB.
Если не получится - тогда только DataPump

VerLeon
Сообщения: 44
Зарегистрирован: 24 ноя 2007, 08:43

Сообщение VerLeon » 11 мар 2008, 10:53

Так gbak от FB сразу на версию ODS ругается - она ж 11.2

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 11 мар 2008, 10:59

VerLeon писал(а):Так gbak от FB сразу на версию ODS ругается - она ж 11.2
Да ? gbak научили работать мимо сервера ?! От это молодцы :lol:

VerLeon
Сообщения: 44
Зарегистрирован: 24 ноя 2007, 08:43

Сообщение VerLeon » 11 мар 2008, 11:23

Не понял чего-то..
gbak от FB к серверу IB цепляться не хочет, а при цеплянии к серверу FB ругается именно на ODS базы

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 11 мар 2008, 12:00

VerLeon писал(а):gbak от FB к серверу IB цепляться не хочет
Что говорит ? А через localhost ?

VerLeon
Сообщения: 44
Зарегистрирован: 24 ноя 2007, 08:43

Сообщение VerLeon » 11 мар 2008, 12:30

да, ступил, через localhost цепляется.
только не бэкапится
Ругается на conversion из "PERSISTENT " на первой же таблице
Собственно похоже это и есть проблема - это поле RDB$RELATION_TYPE у таблицы RDB$RELATIONS.
В IB оно char(31), а в FB - smallint.
Видимо и при ресторе из-за этого падает

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 11 мар 2008, 13:01

Кто-нить что-нить понял ? Кроме коннекта через localhost ;)

VerLeon
Сообщения: 44
Зарегистрирован: 24 ноя 2007, 08:43

Сообщение VerLeon » 11 мар 2008, 13:18

Ну... сам я понял :)

Коннект через localhost прошел, пошел бэкап (gbak от FB, сервер - IB).
Как только процесс бэкапа дошел до таблиц - он срубился с сообщением
conversion error from string "PERSISTENT "

Я посмотрел - что это может быть - и пришел к выводу, что срубился он на системной таблице RDB$RELATIONS - у нее есть последнее 17-е поле - RDB$RELATION_TYPE.
У IB-шных баз оно типа char(31) и там лежат строчки типа "PERSISTENT", "VIEW", "GLOBAL TEMPORARY" и т.д.

У FB-шных баз это поле типа smallint.

Могу ошибаться, но проблема по-моему в этом - FB-шный gbak ожидает там увидеть smallint, а получает строчку вроде "PERSISTENT"

Кроме того, мне кажется, что и при ресторе (с чего у меня проблемы и начались) проблема именно в этом, правда тогда не понятно, как он все-таки умудряется разресторить несколько таблиц и только потом срубиться с ошибкой "string truncated"

hvlad
Разработчик Firebird
Сообщения: 1244
Зарегистрирован: 21 мар 2005, 10:48

Сообщение hvlad » 11 мар 2008, 14:12

VerLeon писал(а):Как только процесс бэкапа дошел до таблиц - он срубился с сообщением
conversion error from string "PERSISTENT "

Я посмотрел - что это может быть - и пришел к выводу, что срубился он на системной таблице RDB$RELATIONS - у нее есть последнее 17-е поле - RDB$RELATION_TYPE.
У IB-шных баз оно типа char(31) и там лежат строчки типа "PERSISTENT", "VIEW", "GLOBAL TEMPORARY" и т.д.

У FB-шных баз это поле типа smallint.

Могу ошибаться, но проблема по-моему в этом - FB-шный gbak ожидает там увидеть smallint, а получает строчку вроде "PERSISTENT"
Похоже на правду. Значит - только пампом

VerLeon
Сообщения: 44
Зарегистрирован: 24 ноя 2007, 08:43

Сообщение VerLeon » 11 мар 2008, 18:21

Печально... Ладно будеем пробовать памп.
Спасибо за ответы!

Ответить