Можно использовать инструмент импорта объекта преобразования данных Oracle (IMPDP.EXE) для импорта одной схемы в другое использование опции REMAP_SCHEMA. Однако существует проблема в этом, триггеры правильно не повторно отображаются. Это приводит к триггеру, не создаваемому вообще с ошибкой следующим образом:
ORA-39083: Object type TRIGGER failed to create with error: ORA-00942: table or view does not exist Failing sql is: CREATE TRIGGER "**NEW_SCHEMA**"."METER_ALARMS_BI" BEFORE INSERT ON
**OLD_SCHEMA**.METER_ALARMS ...
Причина этого состоит в том, потому что создать SQL все еще относится к OLD_SCHEMA. Это действительно говорит в документации Oracle что:
Отображение не может быть на 100 процентов завершено, потому что существуют определенные ссылки схемы, что Импорт не способен к открытию. Например, Импорт не найдет ссылки схемы встроенными в теле определений типов, представлений, процедур и пакетов.
По моему скромному мнению, это - немного полицейский Oracle, но это - другое обсуждение!
Согласно примечанию 750783.1 к Метассылке Oracle, обходное решение к:
- Создайте SQLFILE для включения соответствующей команды (команд) DDL:
impdp system/****** directory=test_dp
DUMPFILE=export_schemas.dmp
remap_schema=u1:u2 sqlfile=script.sql
- Извлеките затронутый DDL из записанного SQLFILE и исправьте ссылку схемы. Затем выполните команду вручную.
Это не хороший способ сделать это особенно, если Вы имеете много неудавшихся объектов и хотите автоматизировать процесс объединения нескольких схема для в полевом обновлении баз данных.
Кто-либо нашел лучший способ сделать это? Мне нужно решение, которое должно быть на 100% надежно если, чтобы использоваться в поле. Я мог проанализировать сгенерированный файл SQL, но можно получить это корректных 100%? Есть ли не, некоторый способ прервать СОЗДАТЬ SQL-операторы выполняется IMPDP и исправляет его на лету при импорте? Можно было исправить файл DMP непосредственно?
Вы можете посмотреть DBMS_METADATATA
. Для этого есть вариант REMAP_SCHEMA . Не уверен, будет ли он работать лучше, чем dataPump (и я подозреваю, что dataPump будет использовать DBMS_METADATATA под крышками). Но было бы легче «постпроцесс» вывод.