428 Глава 8

Непосредственный экспорт

Непосредственный экспорт нельзя считать операцией, обратной непосредственной загрузке с помощью SQLLDR (см. главу 9). При непосредственном экспорте данные не читаются напрямую из файлов данных перед записью в DAT-файлы. Экспортирование в непосредственном режиме позволяет миновать буфер обработки SQL (избежать обработки конструкции WHERE, форматирования столбцов и т.д.). Девяносто процентов пути, проходимого данными, - те же. Утилита ЕХР так же считывает блоки в буферный кэш, обеспечивает согласованность по чтению и т.д.

Тем не менее ускорение при использовании непосредственного экспорта может оказаться существенным. Сокращение обработки всего на десять процентов оборачивается значительным сокращением времени выполнения. Например, я только что экспортировал около 100 Мбайт данных (1,2 миллиона записей). Непосредственный экспорт занял около минуты. Обычное же экспортирование продолжалось три минуты. К сожалению, соответствующего непосредственного импорта нет. При импортировании для вставки данных в таблицы используются обычные операторы SQL. Для высокопроизводительной загрузки данных по-прежнему приходится использовать SQLLDR.

Следует заметить, что в режиме непосредственного экспорта нельзя использовать параметр QUERY = для выбора подмножества строк. В этом есть смысл, если учесть, что DIRECT = Y - это просто способ обойти буфер обработки SQL, а ведь именно в нем обычно и обрабатывается конструкция WHERE.

Проблемы и ошибки

В этом разделе я хочу описать ряд проблем, с которыми часто сталкиваются при использовании утилит EXP/IMP. Мы рассмотрим:

использование утилит EXP/IMP для клонирования схемы;

использование утилит EXP/IMP в различных версиях Oracle;

исчезновение индексов;

влияние требований, имена которых сгенерированны системой;

проблемы, связанные с поддержкой национальных языков (National Language

Support- NLS);

проблемы, возникающие при использовании объектов, сс1лающихся на имена нескольких табличных пространств, например таблиц со столбцами типа больших двоичных объектов.

Клонирование

Это стандартное использование утилит EXP/IMP; для этого нужно скопировать всю схему приложения. Необходимо скопировать все таблицы, триггеры, представления, процедуры и т.д. Как правило, это замечательно получается с помощью следующих команд:

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

Exp userid=tkyte/tkyte owner=old user

Imp userid=tkyte/tkyte fromuser=old user touser=new user

Неприятности, однако, возникают, когда в копируемой схеме приложения используются сс1лки на ее же объекты, уточненные именем схемы. Я имею в виду, что в пользовательской схеме А имеется такой, например, код:

create trigger MY trigger before insert on A.table name begin

end; /

Здесь явно создается триггер для таблицы A.TABLE NAME. Если экспортировать такой триггер и импортировать его в другую схему, он останется связанным с таблицей A.TABLE NAME, а не с таблицей по имени TABLE NAME в новой схеме. Утилиты EXP/IMP, однако, работают в этом случае по-разному:

tkyte@TKYTE816> create table tl

2 (x int primary key); Table created.

tkyte@TKYTE816> create table t4 (y int references TKYTE.tl); Table created.

tkyte@TKYTE816> create trigger t2 trigger

2 before insert on TKYTE.tl

3 begin

4 null;

5 end;

6 / Trigger created.

tkyte8TKYTE816> create or replace view v

2 as

3 select * from TKYTE.tl; View created.

Имеется декларативное требование целостности, явно ссылающееся на таблицу TKYTE.T1, триггер по явно заданной таблице TKYTE.T4 и представление, явно ссылающееся на TKYTE.T1. Давайте экспортируем эту схему и создадим пользователя, в схему которого будет выполняться импорт (учтите, что пользователю, выполняющему импорт с параметрами FROMUSER и TOUSER, необходимо предоставить роль IMP FULL DATABASE):

tkyte@TKYTE816> host exp userid=tkyte/tkyte owner=tkyte

tkyte@TKYTE816> grant connect, resource to a identified by a; Grant succeeded.

tkyte@TKYTE816> host imp userid=system/change on install fromuser=tkyte touser=a

430 Глава 8

Import: Release 8.1.6.0.0 - Production on Tue Mar 20 09:56:17 2001 (c) Copyright 1999 Oracle Corporation. All rights reserved.

Connected to: Oracle8i Enterprise Edition Release 8.1.6.0.0 - Production With the Partitioning option

JServer Release 8.1.6.0.0 - Production

Export file created by EXPORT:V08.01.06 via conventional path Warning: the objects were exported by TKYTE, not by you

import done in WE8ISO8859P1 character set and WE8ISO8859P1 NCHAR character

. importing TKYTEs objects into A

. . importing table T1 0 rows

imported

. . importing table T4 0 rows

imported

IMP-00041: Warning: object created with compilation warnings

CREATE FORCE VIEW A . V ( X ) AS

select X from TKYTE.tl

Import terminated successfully with warnings.

Теперь уже видно, что с представлением у нас проблема: оно явно ссылается на таблицу TKYTE.T1; пользователь А не может создать представление для этого объекта, поскольку у него нет соответствующих привилегий. К счастью, утилита IMP явно сообщает, что представление создано с ошибкой. Менее понятно, что случилось с декларативным требованием целостности и триггером. Если обратиться к словарю данных, подключившись от имени пользователя А, получим:

a@TKYTE816> select table name, constraint name,

2 constraint type, r constraint name

3 from user constraints

TABLE NAME CONSTRAINT NAME С R CONSTRAINT NAME

Tl SYS C002465 P

T4 SYS C002466 R SYS C002465

a@TKYTE816> select trigger name, table ow}ner, table name

2 from user triggers

TRIGGER NAME TABLE OWNER TABLE NAME

T2 TRIGGER TKYTE T4

Удивительно, но декларативное требование целостности ссылается на таблицу пользователя А. Буква R в имени означает сс1лку, а требование, на которое она указывает, SYS C002465, - это первичный ключ таблицы Т1 в схеме пользователя А. При наличии в схеме TKYTE уточненного требования целостности ссылок, указывающего на таблицу В.Т (таблица Т пользователя В), это требование тоже будет импортировано в схе-