Шаг 134 - БД Oracle - Импорт (экспорт) в примерах

Для полноты картины напомню, что некоторые параметры утилиты импорта могут конфликтовать друг с другом. Например, если написать - FULL = Y и FROMUSER = MILLER, то получите ошибку! Так же параметр DESTROY может быть очень полезным для админов БД, которые работают с несколькими БД, на одном сервере. Поскольку в процессе полного экспорта БД, осуществляется запись всего словаря данных. А, в файл дампа экспорта, заносятся определения табличных пространств и файлов данных. При этом, если файл дампа экспорта используется для миграции в другую БД того же сервера у вас могут возникнуть проблемы. Это связано с тем что при импорте результатов полного экспорта, первой БД во вторую будут выполнены команды CREATE TABLESPACE, обнаруженные в файле дампа экспорта. Эти команды создадут такие же файлы во второй БД, в результате чего, если не указать параметр DESTROY = N файлы первой БД могут быть переписаны и ее данные будут потеряны! Избежать этого можно заранее создав табличные пространства и разделив их каталоги! Тогда ничего страшного не произойдет! А, сейчас давайте вспомним еще раз наш с вами первый импорт при создании пользователя MILLER:

rem Эта строка предотвращает появление вражеских кабалистических знаков при работе с командной строкой!
set nls_lang=russian_cis.ru8pc866 

rem А это собственно строка, выполняющая импорт!
imp.EXE USERID=MILLER/KOLOBOK@PROBA FILE=MILLER.DAT FROMUSER=MILLER TOUSER=MILLER

Здесь хорошо видно, что файл дампа экспорта имеет имя MILLER.DAT. При этом производится импорт данных, от имени пользователя MILLER моей БД, которую я создал для работы с шагами в вашу БД тому же пользователю MILLER. В данном случае работают операторы fromuser и touser. Данную строку можно было переписать и вот так:

imp.EXE MILLER/KOLOBOK@PROBA FILE=MILLER.DAT FROMUSER=MILLER TOUSER=MILLER

Так как данные пользователя БД, идут первыми в командной строке и запись USERID при этом не требуется. А, если импорт проводиться прямо на машине сервера, то можно записать еще проще:

imp.EXE MILLER/KOLOBOK FILE=MILLER.DAT FROMUSER=MILLER TOUSER=MILLER

В данном случае имя сетевой службы нет необходимости указывать, так как "ухо" сервера вашей БД и так поймет что от него хотят! Если у вас есть желание, то можете попробовать добавить в эту строку что-то еще из параметров прошлого шага и посмотреть, что будет получаться! Теперь, что касается команды COMMIT для выполнения импорта данных. Допустим в вашем дампе экспорта есть таблица на 300 Мбайт данных, это совсем не значит, что необходимо иметь сегмент отката такой же величины! Для того, чтобы уменьшить размеры элементов сегментов отката при выполнении данного импорта определите COMMIT = Y и задайте значение параметра BUFFER. Теперь команда COMMIT будет выполняться после каждого ввода информации объемом BUFFER. Например:

imp.EXE MILLER/KOLOBOK FILE=MILLER.DAT FROMUSER=MILLER TOUSER=MILLER

В данном случае COMMIT будет выполняться после ввода каждой таблицы, а в следующем примере:

imp.EXE MILLER/KOLOBOK FILE=MILLER.DAT FROMUSER=MILLER TOUSER=MILLER BUFFER = 64000 COMMIT = Y

COMMIT будет срабатывать каждые 64000 бит. Но учтите при этом, что наличие полей типа LOB или BLOB в вашем файле экспорта БД, может значительно превысить 64000 бит для одной порции данных импорта по этому не забывайте про это при определении параметра BUFFER импортируя данные с использованием больших двоичных объектов! Здесь следует увеличивать данный параметр, то минимально необходимого объема! Если при этом будет возвращена ошибка IMP-00020, значит параметр BUFFER не достаточно велик. Увеличивайте его значение и повторяйте импорт. Но при этом, если импорт таблицы закончился неудачно, некоторые ее строки все же могут оказаться импортированными. Следует удалить такую "частичную" таблицу перед повторным импортированием! А, что если скажем не удалось сразу импортировать все объекты БД? Что, делать в этом случае? При импорте таблицы создаются в алфавитном порядке! При этом могут возникнуть проблемы из-за существования зависимостей в таблицах БД. Если, например, утилита импорта пытается создать представление таблицы, которой еще не существует, то будет выдано сообщение об ошибке! В данном случае импорт следует повторить, задав параметры ROWS = N и IGNORE = Y! Это позволит создать только те структуры данных, которые не были созданы при последнем сеансе импорта! Например, вы дали такую команду для строки импорта:

imp.EXE MILLER/KOLOBOK@PROBA FILE=MILLER.DAT FULL = Y COMMIT = Y BUFFER = 64000

После этого вы получили сообщение об ошибке ORA-00942(таблица или представление не существуют)! Что делать дальше? Все просто! Даем вот такую строку:

imp.EXE MILLER/KOLOBOK@PROBA FILE=MILLER.DAT FULL = Y IGNORE = Y ROWS = N COMMIT = Y BUFFER = 64000

При этом не забывайте о связи объектов БД! Я вам о них рассказывал ранее! Например, если вы удалили таблицу, а представление созданное от нее осталось в словаре данных, то последующий импорт так же будет неудачным в следствии того, что представлению некуда ссылаться! Не забывайте об этом! Следует быть внимательным при работе с объектами БД и их экспортом для последующего импорта в другую или в эту же БД! Теперь давайте рассмотрим еще один параметр при импорте данных, а именно INDEXES и INDEXFILE. Эти параметры позволяют "развести" при необходимости таблицы и индексы по разным табличным пространствам. При использовании INDEXFILE файл данных при импорте будет прочитан, но не импортирован. Все сценарии создания таблиц будут записаны в файл на выходе. При этом в сценарий, который будет создан, все конструкции DDL будут закомментированы и в дальнейшем на его основе изменив параметры storage и tablespace вы можете переопределить местоположение таблиц и индексов. Так же следует отметить, что использование INDEXFILE требует либо определить параметр FROMUSER, либо параметр FULL значением Y! Рассмотрим это на примере. Первое проводим экспорт пользователя MILLER вот так:

.
.
exp.EXE USERID=MILLER/KOLOBOK FILE=MILLER.DAT OWNER=MILLER
.

Получаем файл MILLER.DAT. Затем напишите bat файл вот с такой командой импорта данного пользователя:

.
.
imp.exe USERID=MILLER/KOLOBOK FILE=MILLER.DAT indexfile=milleridx.sql full=y
.

На экране должно получиться, что-то вроде:

134_1.gif (6113 b)

Затем отредактируйте как вам нужно файл сценария milleridx.sql изменив в нем конструкции STORAGE и TABLESPACE. Вот примерное содержимое этого файла, которое получилось у меня:

.
.
REM  ALTER TABLE "MILLER"."CUSTOMERS" ADD PRIMARY KEY ("CUST_NUM") USING 
REM  INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 81920 
REM  FREELISTS 1 FREELIST GROUPS 1) TABLESPACE "USERS" LOGGING ENABLE ;
REM  CREATE TABLE "MILLER"."GIRLS" ("NM" NUMBER(*,0), "NAME" VARCHAR2(20), 
REM  "CITY" VARCHAR2(20)) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 
REM  STORAGE(INITIAL 81920 FREELISTS 1 FREELIST GROUPS 1) TABLESPACE 
REM  "USERS" LOGGING NOCOMPRESS ;
REM  ... 6 rows
REM  CREATE TABLE "MILLER"."OFFICES" ("OFFICE" NUMBER(*,0), "CITY" 
REM  VARCHAR2(30) NOT NULL ENABLE, "REGION" VARCHAR2(30) NOT NULL ENABLE, 
REM  "MGR" NUMBER(*,0), "TARGET" NUMBER, "SALES" NUMBER NOT NULL ENABLE) 
REM  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 STORAGE(INITIAL 81920 
REM  FREELISTS 1 FREELIST GROUPS 1) TABLESPACE "USERS" LOGGING NOCOMPRESS ;
REM  ... 5 rows
.
.

Затем запустите сценарий создания таблиц и индексов в SQL*Plus и проведите импорт данных с такими параметрами:

imp.exe USERID=MILLER/KOLOBOK FILE=MILLER.DAT FROMUSER=MILLER TOUSER=MILLER BUFFER = 64000 
		COMMIT = Y INDEXES = N

Но если количество индексов для отделения не большое, то можно воспользоваться опцией rebuild команды alter index. Вот собственно кратко о том, как выполняется импорт и экспорт в БД Oracle! Все остальное я надеюсь вы сможете одолеть и сами, если есть желание и время! И конечно же, если что-то не совсем ясно, можете спрашивать! Чем могу помогу!


Предыдущий Шаг | Следующий Шаг | Оглавление
Автор Летучий Сергей - 16.05.2004