Oracle SQL методика, позволяющая избежать заполнения журнала трансляций

Question

Новое в программировании Oracle (из Sybase и MS SQL Server). Что такое «способ Oracle», чтобы избежать переполнения журнала транзакций большими обновлениями?

В моем конкретном случае я делаю обновление потенциально очень большого числа строк. Вот мой подход:

UPDATE my_table
SET a_col = null
WHERE my_table_id IN 
(SELECT my_table_id FROM my_table WHERE some_col < some_val and rownum < 1000)

... где я выполняю это внутри цикла, пока обновленное число строк не станет равным нулю

Это лучший подход?

Спасибо

Answer 1

Количество обновлений журналов повторов и отмен вообще не будет уменьшаться, если вы разбиваете ОБНОВЛЕНИЕ в нескольких запусках, скажем, 1000 записей. Кроме того, общее время запроса, скорее всего, будет выше по сравнению с запуском одного большого SQL.

Нет реального способа решить проблему с журналом UNDO / REDO в ОБНОВЛЕНИЯХ. С INSERTs и CREATE TABLE вы можете использовать опцию DIRECT или APPEND, но я думаю, что это не так просто для вас.

Answer 2

Зависит от процента строк почти столько же, сколько от числа. И это также зависит от того, сделает ли обновление строку длиннее, чем раньше. т.е. от нуля до 200 байтов в каждом ряду. Это может повлиять на вашу производительность - цепочки строк.

В любом случае, вы можете попробовать это.

Создайте новую таблицу с исправленным столбцом как частью выбора вместо обновления. Вы можете создать эту новую таблицу с помощью CTAS (Создать таблицу как выбор), которая может избежать регистрации.

Брось оригинальный стол.

Переименуйте новую таблицу.

Переиндексация, повторное сопоставление, перестроение триггеров, перекомпиляция пакетов и т. Д.

таким образом вы можете избежать большого количества регистрации.

Answer 3

Любое ОБНОВЛЕНИЕ будет генерировать повтор. Реально, одно ОБНОВЛЕНИЕ, которое обновляет все строки, будет генерировать наименьшее общее количество повторов и запускаться в течение кратчайшего периода времени.

Предполагая, что вы обновляете подавляющее большинство строк в таблице, если есть какие-либо индексы, использующие A_COL, вам может быть лучше отключить эти индексы перед обновлением, а затем выполнить перестройку этих индексов, указав NOLOGGING после массивное ОБНОВЛЕНИЕ заявления. Кроме того, если есть какие-либо триггеры или внешние ключи, которые необходимо будет запустить / проверить в результате обновления, временное избавление от них может оказаться полезным.