А самому проверить и узнать ответ?
Не через cron, а просто вручную, чтоб не ждать.

Только не используйте параметр JOB_NAME, тогда Data Pump будет генерировать уникальные имена для Master Table с "_01", "_02" и тд в названии.

FrequencyЕжедневный full бэкап кроме RMAN, на стороннний смонтированный диск в целях страховки

Т.е. Вы как бы RMAN'у не доверяете? Может лучше тогда просто в ежедневный скрипт бекапа добавить CHECK LOGICAL, или RESTORE PREVIEW / VALIDATE, чтобы "перепроверять" что там RMAN набекапил?

Возвращаясь к теме - так в этой схеме идёт ежедневная разработка, или это таки Production? Просто 800 ГБ, и "всё нужное" немного смущает. Вряд ли на Prod системе допустим экспорт, длящийся сутки. К тому же, как выше заметили, если Вы делаете консистентный экспорт (а Вы же делаете?). Т.е. экспорт с FLASHBACK_TIME=SYSTIMESTAMP, правда? (иначе зачем это все..?). Представьте нагрузку на Undo в течение этих суток, я к этому.

Если разработка - обычно для "страховки" хватает делать экспорт METADATA_ONLY, чтобы сохранять всю структуру системы. Ну и какие-то конфигурационные/важные таблицы, список которых обычно известен.

А если Prod - как уже предлагалось выше, лучше "вложить" час времени, посидеть / подумать и разделить систему (таблицы) на статические и обновляемые. И исключить хотя бы топ 5 или 10 самых больших. И написать в файл параметров экспорта простыню QUERY запросов (и/или INCLUDE/EXCLUDE) на список реально нужных таблиц. А если есть нужные/большие таблицы - отсекать в них только свежие данные, фильтровать их по какому-то признаку (каждую таблицу можно фильтровать отдельно по своему признаку), чтобы только свежие/новые данные экспортировать. Можно даже ссылаться друг на друга в QUERY блоке, можно подзапросы делать - в общем, там очень много можно накрутить. Но это того стОит, потому что экспорт можно действительно очень сильно оптимизировать по времени (ну и по размеру конечно). Главное только "know your data" - все это получится, если Вы владеете знаниями о хранимых данных в таблицах, как они организованы, ссылаются друг на друга и тд.

Ну если вспомнили про FLASHBACK как средство защиты от удаления таблицы, то тогда уж и про Recycle Bin стоит упомянуть.

А если серьёзно - то справедливости для стоит упомянуть что RMAN таки умеет восстанавливать таблицу из бекапа, начиная с 12c. Как именно он это делает (пардон за капитанство, вдруг кто не знает) - создаётся (автоматически) временный экземпляр (AUXILLARY), таблица извлекается из бекапа и сохраняется в дамп файл методом Data Pump Export. И сразу же импортируется обратно в базу (тем же DP Import), причём можно указать таблице новое имя и даже импортнуть в другую схему или TBS (REMAP в общем). Т.е. можно не задевая существующую таблицу, рядом восстановить её же, на какой-то момент времени до. Но это мы уже отошли от темы удаления таблицы, этот сценарий про испорченную таблицу и как её восстановить. И потом RMAN все за собой подтирает. И последнее - фазу импорта можно и не выполнять, тогда из бекапа таблица извлечется, и останется в дампе. И вся эта радость одной командой.

И ещё есть BLOCKRECOVER, можно из бекапа чинить corrupted блоки сегментов с данными, доставая из бекапа нужные блоки, и догоняя их до нужной консистенции из архивлогов. Крутая фича, но требует EE редакции. Ну и ещё конечно PDB restore, иначе как.