Импорт и экспорт

Сценарий просто добавит в базу данных дополнительные представления версии 7, позволяющие работать утилите ЕХР версии 7.

Куда делись индексы?

Логично ожидать, что если экспортирована схема, после чего все объекты в этой схеме удалены, а затем схема импортирована, то должен получиться тот же набор объектов. Да, но могут быть сюрпризы. Рассмотрим следующую простую схему:

tkyte@TKYTE816> create table t

(x int, у int,

constraint t pk primary key(x)

Table created.

tkyte@TKYTE816> 2 /

Index created.

create index t idx on t(x,y)

tkyte@TKYTE816> create table

2 (x int primary key,

3 у int

5 / Table created.

tkyte@TKYTE816> 2 /

Index created.

create index t2 idx on t2(x,y)

Две очень похожие таблицы отличаются наличием явного (а не сгенерированного системой) имени первичного ключа. Давайте посмотрим, какие объекты созданы в базе данных:

tkyte@TKYTE816> select object type, object name,

2 decode(status,INVALID,*, )

3 tablespace name

4 from user objects a, user segments b

5 where a.object name = b.segment name (+)

6 order by object type, object name

status,

OBJECT TYPE OBJECT NAME

S TABLESPACE NAME

INDEX

TABLE

SYS C002559

T2 IDX

T IDX

T PK

DATA DATA DATA DATA DATA DATA

6 rows selected.

438 Глава 8

Как видите, для каждого из первичных ключей автоматически сгенерирован индекс - это индексы SYS C002559 и Т РК. Мы видим также и два явно создававшихся индекса. После удаления таблиц Т и Т2 я выполнил полный импорт. К моему удивлению, обнаружилось следующее:

tkyte@TKYTE816> select object type, object name,

2 decode(status,INVALID,*, ) status,

3 tablespacenatne

4 from user objects a, user segments b

5 where a.object name = b.segment name (+)

6 order by object type, object name

OBJECT TYPE OBJECT NAME S TABLESPACE NAME

INDEX T2 IDX DATA

T IDX DATA

T PK DATA

TABLE T DATA

T2 DATA

Один из моих индексов исчез . Дело в том, что сервер Oracle использовал индекс T2 IDX по столбцам (X,Y) для поддержки первичного ключа. Это вполне нормально. Мы и сами можем воспроизвести такое поведение, немного изменив порядок выполнения операторов CREATE (в чистой схеме, где еще нет никаких объектов):

tkyte@TKYTE816> create table t (x int, у int) ; Table created.

tkyte@TKYTE816> create index t idx on t(x,y); Index created.

tkyte@TKYTE816> alter table t add constraint t pk primary key(x); Table altered.

tkyte@TKYTE816> select object type, object name,

2 decode(status,INVALID,*,) status,

3 tablespace name

4 from user objects a, user segments b

5 where a.object name = b.segment name (+)

6 order by object type, object name

OBJECT TYPE OBJECT NAME S TABLESPACE NAME

INDEX T IDX DATA

TABLE T DATA

В этом случае сервер Oracle будет использовать индекс T IDX для поддержки первичного ключа. Это легко понять, попытавшись удалить индекс:

tkyte@TKYTE816> drop index t idx;

drop index t idx

Импорт и экспорт 439

E<OR at line 1:

ORA-02429: cannot drop index used for enforcement of unique/primary key

Что ж, то же самое происходит и в ходе работы утилит EXP/IMP. Определения индексов, имена которых сгенерированы системой, не экспортируются. В противном случае происходили бы ошибки. Утилиты EXP/IMP полагаются на то, что индекс неявно создается при создании объекта (если вообще создается). Если бы действительно б]л экспортирован индекс SYS C002559, а затем его попытались бы импортировать, могла бы произойти одна из двух ошибок. Во-первых, сгенерированное имя SYS C002559 вполне могло бы совпадать с уже существующим автоматически сгенерированным именем (например, именем требования проверки). Во-вторых, при создании объекта индекс мог быть уже создан, то есть наш индекс оказывается лишним (и выдается сообщение об ошибке). Поэтому утилиты ЕХР и IMP работают правильно: вы просто видите побочный эффект того, что при создании требования индекс не обязательно создается.

Задавая имя для требования первичного ключа, мы создаем индекс, имя которого совпадает с именем требования; при каждом создании объекта имя индекса будет неизменным. Утилита ЕХР экспортирует определение этого индекса, a IMP будет его импортировать.

Вывод: надо избегать автоматического именования объектов не только по рассмотренной выше причине, но и по причине, описанной в следующем разделе. Не говоря уже о том, что имя SYS C002559 никому ни о чем не говорит, а имя Т РК для кого-то вполне может означать первичный ключ (РК) таблицы Т .

Явно и автоматически именуемые требования

Еще одна проблема с автоматически сгенерированными именами требований состоит в том, что при импорте для таблицы может добавляться избыточное требование (я мог бы назвать этот раздел Откуда взялись все эти ограничения? ). Рассмотрим пример. Начнем с таблицы Т:

tkyte@TKYTE816> create table t

2 (x int check (x > 5) ,

3 у int constraint my rule check (y > 10) ,

4 z int not null ,

5 a int unique,

6 b int references t,

7 с int primary key

8 ) ; Table created.

tkyte@TKYTE816> select constraint name name, constraint type type, search condition

2 from user constraints where table name = T;

NAME T SEARCH CONDITION

SYS C002S74 С Z IS NOT NULL

SYS C002675 С x > 5