Стратегия повышения производительности Oracle DELETE

У нас есть установка Oracle 11g, которая становится все более популярной. Эта база данных является серверной частью системы параллельной оптимизации, работающей в кластере. Входные данные для процесса содержатся в базе данных вместе с выходными данными этапов оптимизации. Входные данные включают механически измененные данные конфигурации и некоторые двоичные файлы (с использованием SecureFiles 11g). Вывод включает 1D, 2D, 3D и 4D данные, которые в настоящее время хранятся в БД.

Структура БД:

/* Metadata tables */
Case(CaseId, DeleteFlag, ...) On Delete Cascade CaseId
OptimizationRun(OptId, CaseId, ...) On Delete Cascade OptId
OptimizationStep(StepId, OptId, ...) On Delete Cascade StepId

/* Data tables */
Files(FileId, CaseId, Blob) /* deletes are near instantateous here */

/* Data per run */
OnedDataX(OptId, ...)
TwoDDataY1(OptId, ...) /* packed representation of a 1D slice */

/* Data not only per run, but per step */
TwoDDataY2(StepId, ...)  /* packed representation of a 1D slice */
ThreeDDataZ(StepId, ...) /* packed representation of a 2D slice */
FourDDataZ(StepId, ...)  /* packed representation of a 3D slice */
/* ... About 10 or so of these tables exist */

Сценарий Reaper появляется ежедневно и ищет случаи с DeleteFlag = 1 и продолжает DELETE FROM Case WHERE DeleteFlag = 1 , позволяя каскадам продолжаться.

Эта стратегия отлично работает для чтения / записи, но сейчас она превосходит наши возможности, когда мы хотим очистить данные! Проблема в том, что удаление кейса занимает ~ 20-40 минут в зависимости от размера и часто перегружает пространство нашего архиватора. В следующей основной версии продукта будет использован подход к решению проблемы «с нуля». Следующий второстепенный выпуск должен оставаться в пределах данных, хранящихся в базе данных.

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

1. REF Разделение на разделы , но вопрос КАК? Я хотел бы сделать INTERVAL для Case и REF для остальных, , но это не поддерживается . Есть ли способ вручную разделить OptimizationRun с помощью CaseId с помощью триггера?
2. Отключить архивирование / повторное выполнение журналов для удалений? Не удалось найти подсказку по этому поводу. Не уверен, что это вообще возможно.
3. Усечь? Это, вероятно, потребует какой-то сложной настройки таблицы. Но, может быть, я не рассматриваю весь свой вариант. (за ответ, отмечен)

Чтобы проиллюстрировать проблему, рассматриваемые данные для каждого случая варьируются от 15 МБ до 1,5 ГБ с любым количеством строк от 20 КБ до 2 МБ.

Обновление: Текущий размер БД ~ 1,5 ТБ.