перенос данных с ib7.5 на firebird 2.0.1
Модератор: kdv
перенос данных с ib7.5 на firebird 2.0.1
Есть база на 15 Гб в 1 диалекте под ib 7.5. Подправил метадату, выгрузил. Из скрипта заливается в firebird-е без проблем. Но backup/restore-ом перенести базу не удается, получаю при ресторе error на тему BLR offset. Это уже после того как метадата закоммитилась и в логе бегут надписи о раздаче прав юзеру SYSDBA на объекты БД (это какие-то системные таблицы не ресторятся?). Лога сейчас нет под рукой, могу воспроизвести и выложить, если есть решения для переноса через b/r.
Пока есть мысть просто перегнать данные из одной базы в другую, хотя на 15 гигах наверное будет не быстро.... Какой инструмент взять? Нужна поддержка блобов и максимально быстрый перенос. Здесь http://ibase.ru/d_tools.htm нашел раздел с утилитами, но ни одной не пользовался. Посоветуйте плз, что из этого пошустрее работает. Если конечно с b/r никак...
Пока есть мысть просто перегнать данные из одной базы в другую, хотя на 15 гигах наверное будет не быстро.... Какой инструмент взять? Нужна поддержка блобов и максимально быстрый перенос. Здесь http://ibase.ru/d_tools.htm нашел раздел с утилитами, но ни одной не пользовался. Посоветуйте плз, что из этого пошустрее работает. Если конечно с b/r никак...
ibpump, а не datapump. в любом случае, все это описано в
www.ibase.ru/devinfo/prevver.htm
www.ibase.ru/devinfo/prevver.htm
Всем спасибо за советы, но кажется обошлось малой кровью, т.е. база сресторилась под FB. Отдельное спасибо hvlad, правда я не стал дропать процедуры, а просто "деактивировал" их через ibexpert, закомментарив тело процедур и триггеров. В ресторенной под FB базе они активировались и перекомпилировались без проблем.
Не без проблем правда прошел сам рестор, в связи с чем завел соответствующий топик:
http://forum.ibase.ru/phpBB2/viewtopic.php?p=22669
Хочется услышать "помощь зала".
Не без проблем правда прошел сам рестор, в связи с чем завел соответствующий топик:
http://forum.ibase.ru/phpBB2/viewtopic.php?p=22669
Хочется услышать "помощь зала".
WildSery, а в чем кстати экстрим? Сначала как-то не обратил внимания на эту ремарку, теперь задумался. У нас вопрос уперся в лицензирование и в ряд проблем с которыми неизвестно как бороться (на 5.6 не проявлялись, зато на 7.5 вылезли во всей красе). А без наличия лицензии саппорт особо нашими проблемами не озадачишь. Посмотрел графики производительности (tpc-c), вроде как 2.0 прилично опережает 1.5 в обоих архитектурах, поэтому на ней и остановился, т.к. в базе порядка 150-170 тысяч транзакций в день. Или с этой веткой есть реальные проблемы?
а вот этот метод с 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Гб).
Впрочем сравнить по скорости не получилось вот.
Попробовал и получил вот что:
при ресторе каждой таблицы (т.е. еще метаданных):
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Гб).
Впрочем сравнить по скорости не получилось вот.
Ну... сам я понял
Коннект через 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"
Коннект через 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"
Похоже на правду. Значит - только пампом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"