Все здравствуйте!

Импортирую схемму impdp'ом. Все импортируется нормально.
Если же произвожу клонирование схеммы с помошью impdp remap_schema=SCHEM_SRC:SCHEM_DEST...

1)В исходной схемме Оракл насоздавал системных типов вида
  CREATE OR REPLACE TYPE "SYS_PLSQL_80913_9_1" as table of SCHEM_SRC."SYS_PLSQL_80911_125_1";
Ну и,собственно в SCHEM_DEST они не создаются
2)Также возникают ошибки такого плана
ORA-39083: Сбой при создании типа объекта TYPE с ошибкой:
ORA-02304: неверен литерал идентификатора объекта
SQL, вызвавший сбой:
CREATE TYPE "SCHEM_DEST"."SYS_PLSQL_79838_801_1"   OID '121FD79784C24A708EDE82003C0FAFCA' as table of "SYS_PLSQL_79838_746_1";

У меня возникает три общих вопроса

1) Как избежать сложившейся ситуации????
    Я, к примеру, в случае с SCHEM_SRC."SYS_PLSQL_80911_125_1" делаю так. Предварительно в исходной схемме выгружаю скрипт со всеми типами, замещаю в нем <SCHEM_SRC."> на <">. И выполняю его (на исходнике). Но при этом, некоторые типы просто не дают себя перекрмпилировать, т.к. существуют зависимости. И, вообще, мне этот метод совсем не нравится своей черезпоповостью!
2) Отношение количества созданных в конечной базе типов к исходному количеству (визуально) 0,05. При этом, все прочие объекты, вроде, создаются благополучно, таблицы, индексы (тоже проверил поверхностно) все на месте... Единственное, необходимо перекомпилить пакеты после ручного создания некоторых пользовательских типов. Причем, после этого в SCHEM_DEST появляются свои SYS_PLSQL_xxx. Т.е. вопрос: на что влияет отсутствие в схеме исходных системных типов?
3) Как вообще при этом в итоге проверить корректность клонирования схеммы?

Спасибо!!!!

Не забывай писать версию базы в посте. Это важно в данном случае.

Если у тебя 10gR2 или выше, то добавь параметр transform=oid:n, это должно исключить ORA-02304. А вот на счёт 10gR1 я не в курсе, там вроде этого параметра нет.

Добавлено @ 15:07
З.Ы. Правда в том, что impd/expdp не всегда работают. Количество подводных камней там огромное, как это не печально. При чём это не банальные ошибки кодинга это именно подводные камни.

Это сообщение отредактировал(а) ToshaCh - 23.6.2009, 15:08

У меня 10
касательно R1/R2 - не знаю..... это чего/где посмотреть...

но transform=oid:n работает.....

Спасибо!!!


а с первой проблемой что можно сделать?

И вобще, если типы выстраиваются после перекомпиляции пакетов, может ничего страшного и нет?

Или на что еще могут повлиять типы, если все объекты прочие, вроде дееспособны...

Как то это можно проверить?

R1/R2 это так сказать ревизии. Цикл разработки баз у оракла такой: 
1. Выбирается цель развития баз на ближайшее будущее, это отражается буквой в названии 8i,9i,10g, 11g, 12c, где g, например, это grid computing.
2. Серьёзные изменения функционала и ядра базы номируются цифрами, т.е. 9, 10, 11 и т.д.
3. Кроме того каждую версию базы оракл делит на две - три ревизии, которые обазначаются R1, R2 и т.д. и несут серьёзные апдейты функциональности.
4. Ну а каждая ревизия уже делится на минорные апдейты (обычно 5-7 штук), которые чаще всего просто багфиксы и небольшые улучшения.
Соответственно конаническое обозначение базы это 10gR2, что соответствует версиям 10.2.0.x. 


Ты уверен что они насоздавались после импорта. Т.к. они по идее должны были в исходной схеме и до это существовать.

Судя по названию это SQL типы автоматически созданные PL/SQL машиной для "прозрачного" использования PL/SQL типов в SQL. По идее, после рекомпиляции пакетов, в новой схеме эти типы создадутся сами, наверняка даже с другими именами.

Однако... я никогда не занимался импами/экспами (этим с успехом занимается мой ДБА и не мне его хлеб жевать), потому своей оценки "страшно" или "не страшно" - дать не могу ;)

Именно так, это автоматические типы, которые создаются при компиляции пакета, но они не должны были создаваться явно командой импорта, а лишь появляться на этапе рекомпиляции пакетов, поэтому и я сомневаюсь в словах setnull'а