Ошибки, часто возникающие при переносе БД

Метки: ,

Наиболее распространённые ошибки, возникающие во время переноса базы данных, EXP-00091, ORA-00904, ORA-28031, IMP-00032 и неверные кодировки.

EXP-00091: Exporting questionable statistics.

Может возникать при экспорте данных таблицы, если вместе с данными экспортируется собранная статистика оптимизатора. Причины возникновения: ошибка записи, кодировка клиента не соответствует кодировке сервера, были указаны дополнительные условия экспорта, экспортируется только часть разделов таблицы. Можно отказаться от экспорта статистики совсем, указав параметр STATISTICS=NONE

exp 'sys@orcl as sysdba' file=expfull.dmp log=expfull.log full=y statistics=none

 

или установить кодировку, соответствующую серверу – параметр NLS_LANG

#Linux:
export NLS_LANG=RUSSIAN_RUSSIA.CL8MSWIN1251

rem Windows:
set NLS_LANG=RUSSIAN_RUSSIA.CL8MSWIN1251

ORA-00904: “POLTYP”: invalid identifier

Эта ошибка – явный признак несоответствия версии БД Oracle и версии клиента, выполняющего экспорт. При логическом бэкапе/восстановлении данных работает несколько правил:

  1. файл, созданный экспортом более поздней версии не может использоваться импортом более ранней версии;
  2. экспорт более поздней версии не может сделать дамп базы более ранней версии (описываемая ошибка появилась как раз в такой ситуации – БД 11iR1, экспорт 11iR2);
  3. экспорт более ранней версии может сделать дамп более поздней версии БД.

Подводя итог, перенос данных, например, из 11iR1 в 11iR2 (из ранней версии в позднюю) можно сделать следующим образом: exp v11.1 -> imp v11.2; перенос 11iR2 в 11iR1 (из поздней в раннюю): exp v11.1 -> imp v11.1.

ORA-28031: maximum of 148 enabled roles exceeded.

Ошибка возникает в том случае, если у пользователя, под которым происходит соединение, оказывается активировано более 148 ролей. Такое явление легко получить при развертывании БД в момент создания всех необходимых пользовательских ролей. Просто при создании роли пользователю, эту роль создавшему, она назначается автоматически. Обычно это случается с пользователем system. В этом случае выход простой – после создания всех ролей просто отменить их назначение пользователю system – вряд ли они ему понадобятся все разом.

Тем не менее, нельзя не вспомнить про параметр max_enabled_roles. Почему бы просто не назначить этому параметру большее значение? Потому что начиная с версии 10g этот параметр был отменен и его присутствие сохраняется только для обратной совместимости, но значение фактически ни на что не влияет. Итак, в результате мы имеем жесткое ограничение на присутствие у пользователя не более 150 активных пользовательских ролей (фактически 148, т.к. каждый пользователь обязательно имеет 2 роли: PUBLIC и свою собственную). Если же имеется острая необходимость превысить это ограничение, то единственный выход – назначить роли, но не делать их активными по-умолчанию, а активировать необходимые (только напрямую назначенные пользователю) роли во время сессии.

-- активировать роли myrole1, myrole2, myrole3
set role myrole1, myrole2, myrole2;
-- активировать все роли, кроме myrole3, myrole4
set role all except myrole3, myrole4;

IMP-00032: SQL statement exceeded buffer length; IMP-00008: unrecognized statement in the export file

Иногда ошибку IMP-00032 могут вызывать параметры кодировки, с которыми выполнялся экспорт данных (в моем случае экспорт выполнялся в UTF8). На Metalink по этому поводу присутствуют решения для некоторых случаев (Note 278980.1). Но для начала полезно просто задать большее значение размера буфера в байтах при вызове команды импорта.

imp 'sys@orcl as sysdba' file=exp.dml log=imp.dmp buffer=1000000

Проблема кодировки. Вместо символов знаки вопроса (?????).

Неправильное перекодирование символов происходит при неверных параметрах кодировки NLS_LANG во время экспорта и импорта. В лучшем случае, если экспорт был выполнен с подходящими параметрами, и национальные символы были обработаны правильно, но импортировались данные с другими настройками, то можно получить знаки вопроса в кодах объектов (комментарии к таблицам, триггера, функции, процедуры и т.д.), при этом записи таблиц будут отображаться правильно. В этом случае достаточно повторно выполнить импорт с параметрами, соответствующими экспорту. В худшем случае кодировка может быть нарушена и в объектах и в таблицах. В этом случае следует заново выполнить экспорт с подходящими настройками NLS_LANG.

Close Menu