Теперь давайте рассмотрим несколько немаловажных, моментов при работе с экспортом. Что такое вообще полный экспорт и инкрементальный и кумулятивный экспорт? Все упирается в параметр экспорта INCTYPE используемый совместно с параметром FULL. Все это в совокупе позволяет администратору БД экспортировать только те таблицы, которые изменились со времени последнего экспорта. Если изменилась хотя бы одна строка таблицы, то в ходе инкрементального или кумулятивного экспорта будут экспортированы все ее строки. Рассмотрим доступные значения INCTYPE:

Значение INCTYPE	Описание
COMPLETE	Значение по умолчанию, экспортированы будут все таблицы.
COMULATIVE	Его можно указать если FULL=Y. Экспортированы будут только те таблицы, которые содержат строки изменившиеся со времени последнего полного экспорта любого типа.
INCREMENTAL	Его можно указать если FULL=Y. Экспортированы будут только те таблицы, которые содержат строки изменившиеся со времени последнего кумулятивного, полного или инкрементального экспорта.

Строго говоря, основу стратегии экспорта при резервном копировании формирует полный экспорт. Инкрементальный и кумулятивный экспорт могут быть полезны, если изменились только некоторые таблицы базы данных и размер этих таблиц не велик! Хотя мое мнение, слил все в полный экспорт и голова не болит какие таблицы менялись или нет, главное гарантия, что я полностью восстановлю БД после сбоя! Собственно решать вам использовать данные методы или нет! Следующий вопрос это согласованный экспорт. Так как экспорт к великой радости можно проводить не останавливая экземпляр БД, (хотя можно сделать и на оборот!), а прямо во время работы вашего экземпляра, то возникает вывод, что при записи в таблицу информации из БД в файл дампа экспорта, утилита экспорта считывает только по одной таблице за единицу времени! Таким образом хотя экспорт и начинается в определенный момент времени, каждая таблица считывается в свое, отличающееся от времени начала экспорта. При этом экспортируются данные существующие в таблице на тот момент, когда утилита экспорта начинает считывать именно эту таблицу! Поскольку большинство таблиц связаны между собой и имеют различные размеры, это может привести к несогласованности экспортируемых данных. Как же решить эту проблему!? Есть два способа как с этим справиться! Во-первых, можно запланировать экспорт на то время кода никого нет на рабочих местах - часика эдак в три ночи! Здорово! Хотя думаю это вам не понравиться! А, что если БД в работе в режиме 365X24! Тогда есть еще один способ! Использовать параметр CONSISTENT. Этот параметр доступен только при полном экспорте. Инкрементальный и кумулятивный в данном случае не прокатывает! Если CONSISTENT=Y, то БД будет работать с сегментами отката и отслеживать все изменения сделанные с момента начала экспорта. Затем с помощью сегментов отката можно воссоздать данные существующие на тот момент. В результате экспортируемые данные будут согласованы, но ценой снижения производительности. Вообще по возможности обеспечивайте согласованность данных экспорта, проводя экспорт когда БД, не используется или установлена в режиме restricted session. При невозможности используйте экспорт с параметром CONSISTENT=Y для модифицируемых таблиц и CONSISTENT=N для полной БД. При таком способе не будет слишком низкой производительности, но обеспечите согласованность данных вашей БД. Так же с помощью утилиты экспорта и последующего импорта возможно проводить, работу с табличными пространствами и перемещениями объектов схем и самих табличных пространств. Думаю, в дальнейшем попробовав несколько сценариев, экспорта вы сможете сами научиться проводить, его так как это вам необходимо, тем более что изложенного вам должно хватить в избытке! Можете попробовать и рассказать мне, что у вас получилось! ;-)