422 Глава 8

Они, в лучшем случае, позволяют восстановить базу данных на определенный момент времени. При задании параметра CONSISTENT = Y можно получить моментальный снимок базы данных (помните, однако, что вероятность получить сообщение об ошибке ORA-01555 snapshot too old тем больше, чем длиннее транзакция), но не более того. Повторяю: это - снимок на определенный момент времени. Если использовать результат такого экспорта для восстановления, будут потеряны все изменения, произошедшие после запуска ЕХР. Кроме того, к результатам работы IMP нельзя применить архивные журналы повторного выполнения.

Восстановление базы данных сколько-нибудь существенного размера с помощью утилиты IMP происходит медленно; будут вставляться все данные (через SQL-ма-шину, с генерацией соответствующих объемов данных отката и повторного выполнения), все индексы придется перестраивать, все ограничения - проверять, весь код - компилировать и так далее. То, что при реальном восстановлении занимает минуты, потребует многих часов и даже дней при использовании утилиты IMP.

Инкрементное экспортирование и импортирование с помощью EXP/IMP скоро перестанет поддерживаться. Использование параметра INCTYPE = будет запрещено. Вот вам цитата из документации Oracle: Важно: Возможности инкремен-тного, кумулятивного и полного экспортирования - избыточны и будут убраны в следующих версиях. Необходимо уже сейчас переходить к использованию для резервного копирования баз данных диспетчера резервного копирования и восстановления Oracle . Подробнее см. в руководстве Oracle8iOperatingSystemBackup and Recovery Guide .

Означает ли это, что утилиты EXP/IMP становятся бесполезными в общесистемной стратегии резервного копирования и восстановления? Я, например, считаю, что они могут играть важную роль в общесистемной стратегии резервного копирования и восстановления. Производственная база данных должна работать в режиме архивирования журналов, чтобы обеспечить возможность восстановления на момент времени и восстановления носителей (т.е. восстановления после сбоя диска). Это принципиально важно, и альтернативы этому нет. Кроме того, определенное профилактическое выявление сбоев тоже важно в продуманной стратегии резервного копирования и восстановления. Именно для этого я и использую утилиту ЕХР, как уже упоминал ранее. При этом полностью проверяется словарь данных, используются практически все его индексы и объекты, что гарантирует целостность. В процессе экспортирования прочитываются все данные таблиц, что позволяет проверить их доступность (если индекс будет поврежден, его легко восстановить, поэтому я не беспокоюсь об их тестировании). Полученный файл DMP может также пригодиться для извлечения потерянных фрагментов кода или случайно удаленной таблицы, что во многих случаях позволяет избежать восстановления на определенный момент времени.

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

Есть и другие средства, такие как DBV (средство проверки базы данных), которые также можно периодически применять к файлам данных, чтобы обеспечить физическую целостность данных, в том числе индексных структур, не обрабатываемых утилитой ЕХР.

Утилиты IMP/EXP (уже) не являются средствами реорганизации

В прошлом утилиты экспорта и импорта использовались в основном в этих целях. Для того чтобы дефрагментировать табличное пространство, администратору базы данных приходилось сначала экспортировать набор объектов, затем удалить их и после этого импортировать. Администраторы базы данных тратили много времени на регулярное выполнение такой процедуры. Хотя на самом деле не требовалось делать это больше одного раза, а в большинстве случаев - вообще не нужно. Одноразового выполнения этой процедуры было достаточно, чтобы продумать более эффективную организацию хранения, позволяющую избежать фрагментации. В большинстве случаев, однако, никто ничего не менял, и история неизбежно повторялась. В некоторых случаях это делали, поскольку слышали, что это необходимо , хотя в их случае этого можно было избежать.

Более того, подобное использование утилит EXP/IMP б1ло небезопасно. Вы берете все данные из базы данных, удаляете их, а затем снова вставляете. Определенный промежуток времени данные не защищаются СУБД. Есть опасность, что утилита IMP не сработает (это ведь просто программа). Есть также опасность изменения данных при экспортировании (эти изменения в файл экспорта не попадут) и потери этих изменений. Можно потерять права доступа к объектам и т.д. Все это требует серьезного планирования и приостановки работы на длительное время.

В Oracle8i нет необходимости использовать утилиты ЕХР/IМР для реорганизации данных. Если вы действительно думаете, что это нужно (а я свято верю, что делать это надо не более одного раза для исправления неудачной реализации), то можно использовать оператор ALTER TABLE MOVE для переноса таблиц из одного табличного пространства в другое. В ходе такой реорганизации таблица будет доступна для запросов, но не для изменений. Сразу же после переноса индексы становятся недействительными и надо их пересоздать, так что на это время производительность запросов снизится. Но время простоя будет существенно меньше, чем при использовании утилит EXP/IMP, причем ни одной из перечисленных выше проблем не возникает; данные все время защищены СУБД, нет угрозы потери или изменения данных, процесс не затрагивает привилегии и т.д.

В заключение еще раз подчеркну: дни EXP/IMP как средства реорганизации данных сочтены. Даже не пытайтесь использовать их для этой цели.

Импортирование в другие структуры

Такая необходимость возникает достаточно часто. Как, например, файл экспорта с данными импортировать в отличную структуру? Я часто сталкивался с такой пробле-

Глава 8

мой, когда данные из версии 1 некоего программного пакета требовалось загрузить в базу данных, где установлена версия 2 (или наоборот). Ответ - да, но для этого потребуются определенные усилия. Рассмотрим три случая:

в таблицу добавлен столбец (никаких дополнительных усилий не надо - сервер Oracle поместит в столбец пустые или заданные стандартные значения);

из таблицы удален столбец (кое-что придется сделать);

изменен тип данных столбца (опять-таки, придется кое-что сделать).

В случае появления дополнительного столбца делать ничего не надо. Сервер Oracle выполнит вставку в таблицу как обычно, используя пустые значения или указанное при добавлении столбца стандартное значение. При удалении или изменении столбцов придется импортировать данные в представление, используя триггер INSTEAD OF для их сопоставления. Учтите, что использование триггера INSTEAD OF приводит к дополнительным затратам ресурсов; загружать с его помощью можно небольшие объемы данных, но десятки миллионов строк - не стоит. Рассмотрим пример со следующими таблицами:

tkyte@TKYTE816> create table added a column (x int) ; Table created.

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

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

tkyte@TKYTE816> insert into added a column values (1) ; 1 row created.

tkyte@TKYTE816> insert into dropped a column values (1, 1) ; 1 row created.

tkyte@TKYTE816> insert into modified a column values (1, 1) ; 1 row created.

tkyte@TKYTE816> commit; Commit complete.

Начнем с экспортирования этих трех таблиц (команда для этого должна вводиться в одну строку, иначе будет экспортирована вся схема):

tkyte@TKrE816> host exp userid=tkyte/tkyte

tables=(added a column,dropped a column,modi(ied a column)

Export: Release 8.1.6.0.0 - Production on Tue Mar 20 09:02:34 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 done in WE8ISO8859P1 character set and WE8ISO8859P1 NCHAR character set