Олег Летаев
Директор Центра Компетенции
компании Leaves,
Санкт-Петербург
oletaev@leaves.ru

Data Pump –
новая технология Oracle
для выгрузки/загрузки данных
(Часть II)

Data Pump – это новая технология Корпорации Oracle, предназначенная для высокоскоростной выгрузки/загрузки данных и метаданных из баз данных Oracle, которая к тому же обладает расширенным набором возможностей.

Вниманию читателя предлагается вторая часть статьи, посвящённой возможностям технологии Data Pump.

Часть I этой статьи была опубликована в предыдущем выпуске "Oracle Magazine/Русское Издание"

Содержание. Часть I:

• Обзор
• Архитектура
  • Перемещение данных
  • Перемещение метаданных
  • Мастер-таблица
  • Структура процессов<
    • Клиентский процесс
    • Серверный процесс
    • Master Control Process
    • Рабочие процессы
    • Процессы параллельного исполнения
  • Межпроцессные коммуникации
  • Управление файлами и директориями
    • Объекты-директории
  • Примеры
• Ключевые возможности
  • Управление заданием и мониторинг
    • Начальный запуск задания
    • Подключение к существующему заданию
    • Мониторинг
    • Останов и повторный запуск задания
    • Удаление задания

Содержание. Часть II:

• Сетевые операции
  • Режимы экспорта/импорта
    • FULL
    • SCHEMAS
    • TABLES
    • TABLESPACES
    • TRANSPORT_TABLESPACES
  • Детальный выбор объектов (метаданных)
  • Детальный выбор данных
  • Выбор содержимого
  • Параллельное исполнение
  • Оценка объёма данных
  • Генерация SQL-скрипта
  • Управление файлами и директориями
    • Параллельные операции
    • Форматные маски
  • Преобразование метаданных при импорте
  • Обработка ошибки: таблица уже существует
  • Поддержка Flashback
  • Поддержка различных версий

Содержание. Часть III:

• Утилиты expdp и impdp
  • Параметры командной строки
  • Некоторые недокументированные параметры
  • Команды интерактивного режима
  • Сравнение с традиционными утилитами экспорта/импорта
• Информация о Data Pump
• Data Pump API
  • Манипулятор задания
  • Состояния задания
  • Вызовы API
• Сравнительные тесты традиционных утилит экспорта/импорта и утилит Data Pump
  • Экспорт/импорт таблицx
  • Экспорт/импорт схем

Сетевые операции

Data Pump предоставляет возможность загрузки одной БД из другой (сетевой импорт) и выгрузки данных из удалённой БД (сетевой экспорт). И в том, и в другом случае используются связи БД.

При сетевом импорте вызовы DBMS_Metadata отсылаются на удалённый узел, а результаты их выполнения возвращаются на локальный узел, где и используются для создания объектов. Данные перегружаются операторами INSERT…SELECT с хинтами для прямого доступа. Таким образом, сетевой импорт фактически объединяет операции экспорта и импорта в одну без промежуточного создания дамп-файлов.

Задание Data Pump не может быть запущено на БД, открытой в режиме “только-для-чтения”, так как в такой БД нет возможности создать и вести мастер-таблицу, AQ-очереди и т.п. Однако сетевой экспорт позволяет решить эту проблему. При сетевом экспорте все процессы и мастер-таблица создаются в локальной БД, а чтение данных выполняется из удалённой БД. Перемещение данных при сетевом экспорте выполняется только через внешние таблицы.

Режим сетевой операции задаётся параметром командной строки NETWORK_LINK или в вызове API open.

Режимы экспорта/импорта

Экспорт и импорт Data Pump могут выполняться в одном из следующих режимов:

• FULL – вся БД (при импорте – всё содержимое набора дамп-файлов)
• SCHEMAS – указанные схемы и все объекты в них, включая определения самих схем
• TABLES – указанные таблицы (секции) и все зависимые от них объекты (индексы, триггеры, ограничения целостности и т.д.)
• TABLESPACES – таблицы, любая часть которых содержится в указанных табличных пространствах, и все зависимые от них объекты
• TRANSPORTABLE_TABLESPACES – перемещение табличных пространств.

Режимы задаются одноимёнными несовместимыми друг с другом параметрами командной строки. При использовании API режим экспорта/импорта задаётся в вызове open, список таблиц, схем или табличных пространств – вызовом metadata_Filter, список секций – вызовом data_Filter.

Если режим экспорта не задан явно, экспортируются все объекты собственной схемы.

Если режим импорта не задан явно, будет загружен весь набор дамп-файлов, т.е. предполагается режим FULL.

Никогда не экспортируются схемы Sys, OrdSys, OrdPlugIns, CtxSys, MDSys, LbAcSys, XDB и другие объекты, зарегистрированные в таблице Sys.KU_NoExp_Tab.

Без роли EXP_FULL_DATABASE/IMP_FULL_DATABASE можно экспортировать/импортировать только объекты собственной схемы и выполнять мониторинг своих заданий.

Пользователи, имеющие роли EXP_FULL_DATABASE и IMP_FULL_DATABASE, могут подсоединяться и управлять выполнением заданий других пользователей, экспортировать/импортировать объекты из других схем и объекты, не принадлежащие схемам (сами определения схем, табличные пространства, системные привилегии, планы ресурсов и т.п.).

Рассмотрим основные особенности каждого режима.

FULL

Для экспорта в режиме FULL нужна роль EXP_FULL_DATABASE.

Для импорта в режиме FULL нужна роль IMP_FULL_DATABASE, только если экспорт, в результате которого был получен набор дамп-файлов, требовал роль EXP_FULL_DATABASE.

SCHEMAS

В режиме SCHEMAS не экспортируются и не импортируются:

• зависимые от таблицы объекты, расположенные в других схемах (например, триггер на экспортируемую/импортируемую таблицу, находящийся в другой схеме, не указанной в списке, не будет проэкспортирован/проимпортирован).

В качестве примера, возьмём неоднократно употреблявшийся ранее пример вызова DataPump экспорта в режиме SCHEMAS и создадим эквивалентную последовательность вызовов DataPump API.

Вызов DataPump экспорта:

Последовательность вызовов DataPump API:

TABLES

В режиме TABLES, перечисляя список имён таблиц, в одном имени таблицы можно явно указать имя схемы. В этом случае все остальные таблицы должны находиться в той же схеме.

Недокументированный факт: Если некоторая таблица, заданная в параметре TABLES, не будет найдена в указанной схеме, она будет просто проигнорирована без каких-либо сообщений об ошибках.

Таким образом, все таблицы, выгружаемые в режиме TABLES за одно задание Data Pump, должны находиться в одной схеме. Это ограничение функциональности по сравнению с традиционным экспортом. Однако, его можно обойти, если использовать режим экспорта SCHEMAS с перечислением всех необходимых схем и параметр командной строки INCLUDE (см. Детальный выбор объектов (метаданных)) с фильтром на имена выгружаемых таблиц.

В режиме TABLES в одном имени таблицы на задание можно использовать шаблоны: символы % и _.

Недокументированный факт: При этом имя таблицы нужно заключать в экранированные кавычки и учитывать регистр имени. Например:

В режиме TABLES нельзя задавать синонимы вместо имён таблиц.

В режиме TABLES не экспортируются:

• зависимые от таблицы объекты, расположенные в других схемах (например, триггер на экспортируемую таблицу, находящийся в другой схеме не будет проэкспортирован)
• типы, используемые в таблице (они должны существовать в “приёмной” БД).

В качестве примера, возьмём вызов DataPump экспорта в режиме TABLES и создадим эквивалентную последовательность вызовов DataPump API.

Вызов DataPump экспорта:

Последовательность вызовов DataPump API:

TABLESPACES

В режиме TABLESPACES экспортируются/импортируются не только таблицы, любая часть которых находится в перечисленных табличных пространствах, но и все зависимые от них объекты.

TRANSPORT_TABLESPACES

Особенности режима TRANSPORT_TABLESPACES:

• выгружаются только метаданные
• задания нельзя перезапустить после останова/сбоя
• задания не могут выполняться параллельными потоками.

При экспорте или сетевом импорте в режиме TRANSPORT_TABLESPACES проверяются зависимости между объектами, находящимися внутри набора транспортируемых табличных пространств, и вне его. По умолчанию зависимости будут проверены в одну сторону: таблица может находиться в наборе, а индекс на неё остаться вне набора. Можно включить полную, двустороннюю проверку зависимостей. Для этого используется параметр командной строки TRANSPORT_FULL_CHECK или вызов API set_Parameter.

Детальный выбор объектов (метаданных)

Традиционные экспорт/импорт позволяют только включить в задание или исключить из задания индексы, триггеры, привилегии и ограничения целостности. Data Pump позволяет выбирать практически любые типы объектов и даже отдельные объекты для включения или исключения из задания.

Выбор объектов для экспорта или импорта производится при помощи параметров командной строки EXCLUDE и INCLUDE. В этих параметрах задаётся список типов объектов, включаемых в операцию или исключаемых из операции.

Параметры EXCLUDE и INCLUDE являются взаимоисключающими, т.е. в одном вызове можно использовать либо только INCLUDE, либо только EXCLUDE.

С параметром EXCLUDE экспортируются/импортируются все объекты, характерные для выбранного режима экспорта/импорта, кроме заданных в параметре EXCLUDE. С параметром INCLUDE экспортируются/импортируются только объекты, заданные в параметре INCLUDE.

Например, экспорт схемы без процедурных объектов выполняется со следующим значением параметра EXCLUDE:

Для экспорта только таблиц (и зависящих от них объектов) используется следующее значение параметра INCLUDE:

Можно задавать несколько параметров EXCLUDE или INCLUDE в одном вызове:

Для каждого типа объекта можно задать SQL-предикат на имя объекта. SQL-предикат должен быть заключён в кавычки. Если объекты указанного типа не имеют имён, например, привилегии, SQL-предикат не может быть задан. Если SQL-предикат не задан, исключаются/включаются все объекты указанного типа.

Например,

Если задано несколько предикатов, они объединяются по AND:

Вместе с объектом включаются или исключаются и все зависящие от него объекты.

Для того чтобы избежать проблем с интерпретацией специальных символов в командной строке, таких как кавычки, параметры EXCLUDE и INCLUDE, содержащие предикаты рекомендуется задавать через файл параметров.

Ни EXCLUDE, ни INCLUDE не могут быть заданы, если выполняется экспорт/импорт только данных (CONTENT=DATA_ONLY), потому что в этом режиме выгружаются/загружаются только записи таблиц, и никаких метаданных.

Типы объектов, которые можно использовать в фильтрах, можно увидеть в представлениях Database_Export_Objects (для режима FULL), Schema_Export_Objects (для режима SCHEMAS), и Table_Export_Objects (для режимов TABLES и TABLESPACES).

В Data Pump API для выбора объектов служит вызов metadata_Filter. Он также позволяет задать тип объекта, SQL-предикат и опцию включать/исключать.

Недокументированный факт: В дополнение к возможностям утилит expdp/impdp Data Pump API позволяет задать SQL-предикат на все типы объектов. Для этого при вызове metadata_Filter просто нужно опустить тип объекта.

Последний пример в формулировке вызова metadata_Filter мог бы выглядеть так:

Детальный выбор данных

Data Pump позволяет установить фильтры и на выгружаемые/загружаемые данные. При этом будет выполняться экспорт/импорт только части данных.

Фильтр данных устанавливается в виде SQL-фразы. SQL-фраза – это обычно условие WHERE, но можно использовать, например, и ORDER BY. Использование ORDER BY при экспорте позволяет получить отсортированный дамп-файл и затем проимпортировать данные в порядке сортировки.

Для установки фильтров данных используется параметр командной строки QUERY или вызов API data_Filter.

Фильтр данных может быть установлен:

• на все обрабатываемые объекты
• на все объекты с одинаковыми именами
• на конкретный объект.

Например, фильтр на все таблицы:

Фильтр на конкретную таблицу или на все таблицы с одинаковыми именами (если выполняется экспорт из нескольких схем):

При использовании Data Pump API этот пример выглядит следующим образом:

На каждое имя таблицы можно задать не более одного фильтра. Ещё один фильтр можно установить на все обрабатываемые объекты. Фильтр данных, установленный на конкретный объект, имеет приоритет над фильтром, установленным на все обрабатываемые объекты.

Фильтр данных не может быть установлен если выполняется экспорт/импорт только метаданных (CONTENT=METADATA_ONLY).

При установленном фильтре данных в качестве метода доступа используются внешние таблицы.

Выбор содержимого

Как при экспорте, так и при импорте можно задать обработку только данных (DATA_ONLY), только метаданных (METADATA_ONLY), или и того, и другого (ALL) (по умолчанию).

Режим задаётся параметром командной строки CONTENT.

В Data Pump API существует два вызова для управления выбором содержимого: data_Filter и set_Parameter.

Вызов data_Filter позволяет отключить экспорт/импорт данных для отдельных таблиц. В следующем примере экспорт данных будет отключён только для таблицы Documents:

Чтобы отключить экспорт/импорт данных для всех таблиц (режим METADATA_ONLY), достаточно опустить имя таблицы:

Вызов set_Parameter позволяет управлять экспортом/импортом метаданных.

Если параметр INCLUDE_METADATA имеет значение 0, метаданные не будут обрабатываться. По умолчанию этот параметр имеет значение 1.

Существует ещё один параметр – USER_METADATA, который может быть установлен вызовом set_Parameter. Этот параметр в режиме экспорта схемы определяет, будут ли выгружаться метаданные, необходимые для создания самой схемы (параметры схемы, привилегии и т.п.). Значение 0 отключает выгрузку таких метаданных. По умолчанию этот параметр имеет значение 1, если владелец задания Data Pump имеет роль EXP_FULL_DATABASE.

Параллельное исполнение

Задание Data Pump может исполняться несколькими параллельными потоками, причём их количество можно изменять в ходе выполнения задания, чтобы обеспечить компромисс между максимальной производительностью задания и доступностью ресурсов системы для обслуживания других пользователей.

Существенный факт – параллельные потоки работают не только при загрузке данных, но и при создании и компиляции объектов.

Не стоит, однако, злоупотреблять параллельным исполнением: количество параллельных потоков больше 2xCPU_COUNT, как правило, неэффективно.

Операции генерации SQL-скрипта при импорте и экспорт/импорт в режиме TRANSPORTABLE_TABLESPACES всегда работают со степенью параллелизма 1.

При изменении количества параллельных процессов в ходе выполнения задания добавление процессов производится немедленно. Сокращение количества параллельных процессов, однако, производится по мере завершения ими текущего фрагмента работы, причём сами процессы не удаляются до самого конца задания, а просто остаются неактивными.

Начальная степень параллелизма операции задаётся параметром командной строки PARALLEL. В ходе выполнения операции степень параллелизма можно изменять командой интерактивного режима PARALLEL. В Data Pump API в обоих случаях используется вызов set_Parallel.

Продемонстрируем задание начального количества параллельных потоков и изменение их количества в ходе выполнения задания.

Запускаем задание с 2 параллельными потоками:

Увеличиваем количество параллельных потоков до 4. Изменение выполняется немедленно.

Уменьшаем количество параллельных потоков до 2. По мере завершения текущего фрагмента работы параллельные потоки переходят в неактивное состояние, но не завершаются.

Интерфейс вызова Data Pump API для изменения количества параллельных потоков содержит только манипулятор задания и желаемое количество параллельных потоков.

Оценка объёма данных

Перед выполнением операции экспорта всегда производится оценка объёма выгружаемых данных. Оценивается как суммарный объём выгружаемых данных, так и объём по каждой таблице в отдельности.

Существует два метода оценки:

• BLOCKS (по умолчанию) – количество блоков данных, занятых каждой таблицей умножается на размер блока
• STATISTICS – для оценки используется статистика оптимизатора; если для некоторой таблицы статистика отсутствует, для неё используется режим BLOCKS.

Второй способ точнее, но только при условии актуальности статистики.

Оценка объёма выполняется только для данных, она не включает метаданные. Поэтому оценка объёма не имеет смысла в режиме TRANSPORTABLE_TABLESPACES.

К сожалению, оценка объёма не учитывает SQL-предикатов, задаваемых для детального выбора данных.

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

Метод оценки объёма задаётся параметром командной строки ESTIMATE.

Очень полезным представляется параметр командной строки ESTIMATE_ONLY, который позволяет задать выполнение только оценки объёма без фактического экспорта данных. С помощью этого параметра можно быстро оценивать объём отдельных таблиц и целых схем, а с учётом возможности детального выбора объектов (метаданных) – практически любого произвольного набора объектов.

Для установки этих параметров через API используется вызов set_Parameter.

Генерация SQL-скрипта

При импорте вместо фактического импорта данных можно задать генерацию SQL-скрипта, содержащего DDL-операторы для объектов, которые были бы созданы при выполнении импорта с заданными параметрами. Используя возможности детального выбора объектов, можно ограничивать набор объектов, DDL-операторы для которых будут сгенерированы.

Спецификация файла для SQL-скрипта задаётся параметром командной строки SQLFILE.

Возьмём дамп-файл, содержащий схему PerfStat, и опробуем на нём несколько примеров.

Следующий пример сгенерирует DDL-операторы для создания всего набора объектов, содержащихся в дамп-файле:

Фрагмент полученного SQL-скрипта:

Следует отметить, что “львиную” долю получаемого скрипта занимают вызовы пакета DBMS_Stats для загрузки статистики оптимизатора, выгруженной в дамп-файл. Отключить загрузку статистики можно, используя возможности детального выбора объектов:

Наконец, используя возможности детального выбора объектов, можно получить SQL-скрипт для произвольного набора объектов:

В Data Pump API спецификация файла для SQL-скрипта задаётся вызовом add_File.

Следует отметить, что с точки зрения Data Pump API существует отдельная операция – SQL_FILE (другие две операции – это экспорт и импорт), которая задаётся при создании задания вызовом open. А с точки зрения интерфейса утилит expdp и impdp генерация SQL-скрипта – это запуск утилиты impdp с параметром SQLFILE. Таким образом, эквивалентный набор вызовов Data Pump API должен выглядеть следующим образом:

Управление файлами и директориями

Data Pump работает с тремя типами файлов: дамп-файлы, журнальные файлы и SQL-скрипты. Журнальный файл, как и SQL-скрипт, может быть только один. А вот дамп-файлов может быть задано несколько.

Размер каждого дамп-файла может быть принудительно ограничен (минимум – 40К, по умолчанию – неограничен). По достижении заданного размера дамп-файл закрывается и делается попытка открыть другой файл из набора. Если открыть не удаётся, например, по причине отсутствия достаточного количества свободного пространства на устройстве, задание приостанавливается.

При работе с утилитами expdp/impdp запись журнального файла по умолчанию включена, но её можно отключить. Имена журнальных файлов по умолчанию: export.log – для expdp и import.log для impdp.При работе с Data Pump API запись журнального файла по умолчанию выключена. Журнальный файл всегда записывается в кодовой странице БД.

Спецификации перечисленных файлов задаются параметрами командной строки DUMPFILE, LOGFILE, SQLFILE. Основной директорий для записи/чтения всех этих файлов устанавливается параметром командной строки DIRECTORY. Размеры дамп-файлов ограничиваются параметром командной строки FILESIZE. При использовании API и имена файлов, их размеры, директории задаются вызовом add_File.

Недокументированный факт: При использовании Data Pump API для каждого дамп-файла можно задать свой размер.

Ещё один недокументированный факт: Через API можно добавлять последовательные устройства вместо файлов – вызов add_Device.

Отключение записи журнального файла выполняется параметром командной строки NOLOGFILE. Для получения аналогичной функциональности через API просто не нужно определять журнальный файл.

Объект-директорий, куда будут записываться, или откуда будут читаться дамп-файлы, журнальные файлы, SQL-скрипты, определяется на основе следующих источников (в порядке приоритетов):

1. объект-директорий, заданный непосредственно в спецификации файла в параметрах DUMPFILE, LOGFILE, SQLFILE
2. объект-директорий, заданный в параметре DIRECTORY
3. объект-директорий, заданный в переменной окружения DATA_PUMP_DIR
4. объект-директорий в БД с именем DATA_PUMP_DIR.

Вышеописанные правила определения директория верны для утилит expdp и impdp. При использовании Data Pump API имя объекта-директория должно задаваться явно для каждого файла в вызове add_File или по умолчанию будет принят объект-директорий в БД с именем DATA_PUMP_DIR.

В ходе операции экспорта к определённому перед началом операции набору дамп-файлов можно добавлять новые файлы. Для этого служит команда интерактивного режима ADD_FILE и вызовы API add_File, add_Device.

Недокументированный факт: При работе через Data Pump API пользователи, имеющие роли EXP_FULL_DATABASE и IMP_FULL_DATABASE, могут задавать пути в файловой системе вместо имён объектов-директориев. При использовании утилит expdp/impdp это запрещено.

Если в ходе операции экспорта обнаруживается, что один из дамп-файлов уже существует, он никогда не перезаписывается – операция завершается ошибкой. Журнальные файлы и SQL-скрипты перезаписываются.

В качестве примера приостановим работающее задание, создадим новый директорий, добавим дамп-файл к набору и запустим задание с места останова.

Параллельные операции

При параллельном экспорте/импорте для получения оптимальной производительности желательно, чтобы каждый поток работал со своим дамп-файлом, т.е. чтобы количество дамп-файлов было не меньше, чем количество параллельных потоков. При этом для удобства в именах дамп-файлов можно использовать форматные маски.

Форматные маски

При экспорте в имени дамп-файла можно использовать форматную маску %U, которая будет автоматически заменяться на уникальный номер от 01 до 99. При этом каждому параллельному процессу будет предоставлен свой дамп-файл, и по мере их заполнения (достижения значения FILESIZE) будут создаваться новые. Если задано несколько шаблонов имён дамп-файлов, они будут использоваться по кругу: сначала во все шаблоны будет подставлен номер 01, потом 02 и т.д.

Соответственно, если есть необходимость использовать в имени файла символ %, во избежание неоднозначности, его необходимо продублировать – %%.

Размер дампа в нашем примере составляет приблизительно 70Мб. Зададим 3 шаблона имён дамп-файлов (First%U.dmp, Second%U.dmp, Third%U.dmp) и ограничение на размер дамп-файла – 10Мб. В результате мы должны получить 7 файлов First01.dmp, Second01.dmp, Third01.dmp, First02.dmp, Second02.dmp, Third02.dmp и First03.dmp.

При импорте также можно использовать ту же форматную маску. Поскольку первой операцией импорта должна быть загрузка мастер-таблицы, импорт начинает генерировать имена файлов по шаблону и перебирать их последовательно в поисках мастер-таблицы. Например, если заданы шаблоны expA%U.dmp и expB%U.dmp, импорт проверяет файлы expA01.dmp, expB01.dmp, expA02.dmp, expB02.dmp, и т.д. Если, например, файл expA03.dmp не найден, то поиск по шаблону expA%U.dmp прекращается. Поиск продолжается до тех пор, пока не будет найдена мастер-таблица, или не закончатся все шаблоны.

Если набор дамп-файлов включает в себя несколько файлов, в заголовки всех файлов помещается вся необходимая информация: идентификатор набора дамп-файлов, количество файлов в наборе, порядковый номер файла в наборе. Таким образом, невозможно запустить процесс импорта, не перечислив в параметре DUMPFILE все файлы набора.

Преобразование метаданных при импорте

При импорте, в т.ч. при генерации SQL-скрипта, над метаданными можно выполнить ряд преобразований.

В настоящее время поддерживаются следующие преобразования:

• отображение имён файлов данных
• отображение имён табличных пространств (перенос объектов из одного табличного пространства в другое)
• отображение имён схем (перенос объектов из одной схемы в другую)
• игнорирование (неиспользование) атрибутов сегмента (табличное пространство, параметры хранения, PCTFREE, PCTUSED, INITRANS, LOGGING/NOLOGGING)
• игнорирование (неиспользование) параметров хранения.

Можно задавать несколько параметров отображения имён каждого типа.

Для отображения имён используются параметры командной строки REMAP_DATAFILE, REMAP_TABLESPACE, REMAP_SCHEMA. Отображение задаётся в формате:

Имена нескольких схем можно заменить на одно и то же, загрузив, тем самым, объекты из нескольких схем в одну.

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

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

В Data Pump API для отображения имён используется вызов metadata_Remap, причём вызов API предоставляет больше возможностей, например, отображение имён схем только для объектов определённых типов. Например, перенесём из схемы ACC только таблицы:

Игнорирование атрибутов сегмента и параметров хранения задаётся параметром командной строки TRANSFORM и вызовом API metadata_Transform.

Параметр TRANSFORM имеет следующий синтаксис:

где <имя преобразования> – STORAGE или SEGMENT_ATTRIBUTES, <значение> – Y (использовать) или N (игнорировать), <тип объекта> – TABLE или INDEX.

Игнорирование атрибутов сегмента и параметров хранения может быть задано по-разному для таблиц и индексов, например, игнорировать для таблиц и не игнорировать для индексов:

Аналогичные вызовы Data Pump API:

Если задано игнорировать все атрибуты сегмента, то установка для параметров хранения не имеет значения, поскольку параметры хранения являются подмножеством атрибутов сегмента.

Обработка_ошибки: таблица уже существует

Data Pump предоставляет расширенные возможности обработки ситуации, когда импортируемая таблица уже существует.

Можно выбирать между следующими опциями:

• APPEND – добавить записи (по умолчанию, если CONTENT=DATA_ONLY)
• SKIP – пропустить (по умолчанию во всех остальных случаях)
• TRUNCATE – перезагрузить таблицу, если структура совпадает
• REPLACE – удалить таблицу, пересоздать и перезагрузить её.

Описанные опции устанавливаются параметром командной строки TABLE_EXISTS_ACTION или вызовом API set_Parameter.

При REPLACE объекты, зависящие от таблицы, также удаляются и пересоздаются, если они не исключены явно или неявно и присутствуют в наборе дамп-файлов.

При APPEND и TRUNCATE предварительно выполняются проверки, чтобы гарантировать, что структура строки в дамп-файле совместима со структурой строки в таблице.

При APPEND данные всегда загружаются в новый экстент.

Ошибки типа “…already exists”, как относительно таблиц, так и относительно объектов других типов, считаются ошибками и включаются в общий счётчик ошибок, значение которого выводится при просмотре состояния задания или по завершении выполнения задания.

Поддержка Flashback

При экспорте и сетевом импорте можно задать SCN или время, на момент которого должны быть согласованы выгружаемые данные.

SCN и время задаются параметрами командной строки FLASHBACK_SCN и FLASHBACK_TIME соответственно или вызовом API set_Parameter. Параметры являются взаимоисключающими.

Поддержка различных версий

Версия, совместимость с которой нужно обеспечить. Объекты или атрибуты, не совместимые с заданной версией не будут обрабатываться.

Допустимые значения:

• COMPATIBLE (по умолчанию) – соответственно параметру инициализации COMPATIBLE экземпляра
• LATEST – соответственно версии БД
• <номер версии> (не ниже 10.0.0).

Версия устанавливается параметром командной строки VERSION или вызовом API open.

В будущем обещана также поддержка генерации дамп-файлов в форматах различных версий СУБД не ниже 10g.

Окончание в следующем номере