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

Question

У нас есть установка Oracle 11g, которая начинает расти.Эта база данных является бэкендом для параллельной системы оптимизации, работающей в кластере.Входные данные для процесса содержатся в базе данных вместе с выходными данными шагов оптимизации.Входные данные включают в себя данные конфигурации rote и некоторые двоичные файлы (с использованием 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 */

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

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

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

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

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

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

Answer 1

Удаление данных - адская работа для базы данных. Он должен создавать перед изображениями, обновлять индексы, записывать журналы повторов и удалять данные. Это медленный процесс. Если у вас есть окно для выполнения этой задачи, проще всего и быстрее создать новые таблицы, содержащие нужные данные. Удалите старые таблицы и переименуйте новые таблицы. Это требует некоторой работы по настройке, это очевидно, но очень хорошо возможно сделать. Один шаг менее радикальный - сбросить индексы до того, как произойдет удаление. Мой голос будет идти за CTAS (Создать таблицу как выбрать из) и построить новые таблицы. Хорошая схема разбиения, безусловно, будет полезна, возможно, в следующем выпуске Oracle сможет объединить интервальное и ссылочное разбиение. Было бы очень хорошо иметь.

Отключение ведения журнала .... не может быть сделано для удалений, но CTAS может использовать nologging. Сделайте резервную копию, когда будете готовы, и обязательно перенесите файлы данных в резервную базу данных, если она у вас есть.

Answer 2

Просто некоторые мысли:

1. Я предполагаю, что у вас есть индексы для всех внешних ключей.ON DELETE CASCADE будет удерживать блокировки на уровне строк до тех пор, пока не будет завершено удаление Case, и без индексов будет удерживать блокировки таблиц. Я верю и, конечно, буду очень медленным

2. Есть ли у вас какие-либо отложенные ограничения?Это, скорее всего, замедлит процесс каскадирования Oracle через различные удаления таблиц

3. Вы пытались выполнять удаление отдельно для всех затронутых таблиц (вместо того, чтобы полагаться на каскад удаления)?Не так просто, но вы можете быть удивлены.

РЕДАКТИРОВАТЬ:

Еще одна мысль.Вы можете рассмотреть возможность ПРОГРАММНОГО удаления из таблицы Case, то есть у вас есть поле состояния, которое сообщит вашему приложению, следует ли рассматривать этот Case.Этот флаг может иметь много разных значений, но может быть «A» для активного и «I» для неактивного.Предполагая, что вы всегда используете Case в качестве основной / основной таблицы в соединениях с другими таблицами, вы можете избежать одновременного удаления HARD (и, если хотите, время от времени выполнять очистку в нерабочее время).Конечно, приложения должны знать об этом флаге, и вы будете привязаны к тому, чтобы вернуться к таблице дел.Может или не может соответствовать вашей ситуации ...

Answer 3

CASCADE DELETE внутренне медленно-медленно, э-э, построчно.

Некоторые параметры:

1. Сделайте снимок своего задания очистки всехкейсы для очистки в скретч-стол с CTAS.Затем выполните цикл очистки для этой таблицы, удалив каждый случай (и его дочерние элементы) по отдельности.Это может быть неприятно, особенно если вы столкнетесь с миллионами строк-потомков.Недавно нам пришлось изменить один из процессов в [бизнес-редактировании], который сделал это, чтобы определить, какие конечные родители имели количество детей, что было бы проблематично, а затем использовать ограничитель rownum при удалении против проблемных дочерних таблиц.Это не быстро, но, по крайней мере, безопаснее с точки зрения управления отменой / повторением, установив верхнюю границу того, насколько крупной может быть любая транзакция.

2. Если вы используете CASCADE DELETE в качествеудобство, вы всегда не могли этого сделать.Вам нужно было бы написать более сложную процедуру очистки, которая удаляет из вашего дерева зависимостей «снизу вверх».

3. Если вы можете позволить генерацию отмен / повторов при мягком удалении, вы можетеRange-разделить конечного родителя на DeleteFlag, затем разделить дочерние элементы BY REFERENCE, все таблицы с помощью ENABLE ROW MOVEMENT.Вы бы понесли затраты на отмену / возврат для перемещения строк при мягком удалении, но когда пришло время окончательно очистить, это будет усечение разделов, где DeleteFlag = 1, ничего больше.

4. Добавление хранилища относительно дешево.Если есть опция хранения на основе даты, используйте ее и просто выберите опцию мягкого удаления, чтобы скрыть данные из внешнего интерфейса приложения.Это не элегантно, но так же, как и CASCADE DELETE.

Answer 4

Не рекомендуется для активной базы данных.

1. Я отключил ограничения внешнего ключа, относящиеся к таблице, которую медленно удалять.
2. Я выполнил удаление
3. Включеноснова внешние ключи.

Answer 5

Используйте Enterprise Manager, чтобы создать отчет AWR и запустить его через statspack анализатор , который даст вам подробные инструкции о узких местах в вашей системе. Отчет AWR - это текстовый файл, содержащий все виды данных о том, что база данных сделала за определенное время и сколько времени это заняло ... Этот анализатор statspack - своего рода автоматический администратор баз данных, сообщающий вам, что делать.

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

Не думай об усечении. Это заставляет совершать ...

Кстати, я не связан с Statspack Analyzer, но я думаю, что это очень жизнеспособный подход к общей настройке для Oracle, особенно если вокруг нет DBA.