Oracle Как избежать записи в журнал UNDO / REDO - PullRequest
1 голос
/ 01 декабря 2009

У меня есть сценарий Oracle PL / SQL. Он обрабатывает около 51 млн. Регистров и записывает результаты в 5 различных таблиц.

Проблема в том, что я оставил процесс запущенным прошлой ночью, и, очевидно, в журналах UNDO было переполнение.

В частности, нас не интересует откат этого скрипта, если он не работает, мы можем запустить его снова.

Есть ли способ оптимизировать использование журналов отмены / восстановления? Избегать написания их или свести к минимуму эти записи?

Насколько я понимаю, установка атрибута NOLOGGING для таблиц вывода поможет, помимо использования вставки APPEND (как сказано здесь ).

Ответы [ 5 ]

2 голосов
/ 01 декабря 2009

Вы не должны обрабатывать 51 миллион регистров только в одной партии. Попробуйте разделить его на более мелкие куски, например, несколько тысяч. Если вы выполняете COMMIT после каждого меньшего пакета (что вы будете делать в любом случае, когда говорите, что не собираетесь откатывать), использование журналов повторов / отмен будет только для незафиксированных деталей, и вы избежите переполнения.

1 голос
/ 01 декабря 2009

Кроме того, отключение ограничений и индексов также может ускорить вставки. Вы можете перестроить индексы с помощью nologging.

1 голос
/ 01 декабря 2009

Это действительно вопрос или сокращение объема работы, которую вы делаете.

Таблица UNDO для прямой вставки пути всегда мала, поскольку система просто должна записать, что определенные диапазоны блоков должны быть удалены из сегмента. Индексы все еще потребуют существенной отмены все же. Привязка к прямой траектории минимизирует таблицу REDO.

0 голосов
/ 01 ноября 2016

Вы также можете использовать скрытый параметр _disable_logging = true, чтобы уменьшить повтор, но помните, что результирующий импорт будет невосстановим.

0 голосов
/ 02 декабря 2009

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

Один вопрос: нужно ли вам возвращаться к предыдущей резервной копии, чтобы снова запустить сценарий? То есть, если процесс завершится неудачно после 10 миллионов строк, просто повторный запуск скрипта приведет к вставке 61 миллиона строк, или 10 миллионов будут пропущены / проигнорированы, или у вас будет 10 миллионов обновленных и 41 миллион вставленных.

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

В зависимости от того, как вы написали скрипт PL / SQL, вы можете обнаружить, что использование больших SQL, а не построчная обработка, может уменьшить количество отмен (например, путем минимизации повторных проверок обработанных блоков).

Если вы по-настоящему не понимаете влияния уменьшения отмены или принятия решения о повторном использовании отмены, моей первой рекомендацией будет просто увеличить размер табличного пространства отмены. Конечно, у вас есть недостаток, заключающийся в том, что, если вы сгенерировали множество отмен, тогда сбой займет ОТЛИЧНОЕ время для отката.

...