PL/SQL procedure successfully completed.

tkyte@TKYTE816> create or replace trigger before insert update delete

2 before insert or update or delete on T for each row

3 begin

4 null;

5 end;

Trigger created.

tkyte@TKYTE816> truncate table t; Table truncated.

tkyte@TKYTE816> exec do work(before trigger);

insert redo size = 465640 rows = 200 2,328.2 bytes/row

update redo size = 891628 rows = 200 4,458.1 bytes/row

delete redo size = 473520 rows = 200 2,367.6 bytes/row

PL/SQL procedure successfully completed.

tkyte@TKYTE816> drop trigger before insert update delete; Trigger dropped.

tkyte@TKYTE816> create or replace trigger after insert update delete

2 after insert or update or delete on T

3 for each row

4 begin

5 null;

6 end;

Trigger created.

tkyte@TKYTE816> truncate table t; Table truncated.

tkyte@TKYTE816> exec do work(after trigger);

insert redo size = 465600 rows = 200 2,328.0 bytes/row

update redo size = 854028 rows = 200 4,270.1 bytes/row

delete redo size = 473580 rows = 200 2,367.9 bytes/row

PL/SQL procedure successfully completed.

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

tkyte@TKYTE816> break on op skip 1 tkyte@TKYTE816> set numformat 999,999

tkyte@TKYTE816> select op, rowsize, no trig, before trig-no trig, after trig-no trig

2 from ( select op, rowsize,

3 sum(decode(what, no trigger, redo size/rowcnt,0))

no trig,

4 sum (decode(what, before trigger, redo size/rowcnt, 0))

before trig,

5 sum(decode(what, after trigger, redo size/rowcnt, 0))

after trig

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

Внутренний запрос сгенерировал результирующее множество, содержащее средний объем в байтах данных повторного выполнения для строки для каждого из трех тестов. Внешний запрос просто выдает среднее количество байтов для строки при отсутствии триггера, а последующие два столбца показывают отличие других случаев от тестов при отсутствии триггера. Итак, для тестов с операторами DELETE заметного различия в объеме генерируемых для каждой строки данных повторного выполнения нет. Для операторов INSERT, однако, можно обнаружить дополнительные расходы ресурсов - от 213 до 112 байтов на строку, независимо от типа использованного триггера (BEFORE или

AFTER). Чем больше строка, тем меньше почему-то эти дополнительные расходы (я не разбирался, почему это так, но именно так и получается). Наконец, для операторов UPDATE обнаруживается два факта. Во-первых, объем генерируемых данных повторного выполнения не зависит от размера строки - дополнительные расходы на выполнение операторов UPDATE постоянны. Во-втор1х, триггер AFTER оказывается намного эффективнее для операторов UPDATE, поскольку он вообще не влияет на генерацию данных повторного выполнения. Поэтому можно использовать эмпирическое правило: для операторов UPDATE по возможности используйте триггеры AFTER. Триггер BEFORE имеет смысл использовать, только если требуются его специфические функциональные возможности.

Итак, теперь вы знаете, как оценить объем данных повторного выполнения, что необходимо делать всем разработчикам. Для этого требуется:

оценить размер транзакции (сколько данных изменяется);

добавить от 10 до 20 процентов дополнительного пространства, в зависимости от

количества изменяемых строк (чем больше строк, тем меньше процент дополнительных расходов);

удвоить полученное значение для операторов UPDATE.

В большинстве случаев это дает вполне приемлемые результаты для оценки. Удвоение объема для операторов UPDATE - это упрощение; реальный объем зависит от способа изменения данных. Удвоение предполагает, что берется строка размером X байтов, и в результате изменения получится строка тоже размером X байтов. Если увеличивается маленькая строка, значение не удваивается (результат ближе к тому, который получается при выполнении оператора INSERT). Если уменьшается большая строка, значение тоже не удваивается (результат сходен с тем, который получается при выполнении оператора DELETE). Удвоение - худший случай , поскольку некоторые опции и средства влияют на объем генерируемых данных, например наличие (или отсутствие, как в моем случае) индексов. Объем работы, необходимой для поддержки индекса, для разных операторов UPDATE может отличаться. Побочные эффекты триггеров также необходимо учесть (помимо фиксированных затрат ресурсов, описанных выше). Некоторые операции, выполняемые от имени сеанса неявно, например при установке опции ON DELETE CASCADE, также необходимо учитывать. Это поможет оценить объем данных повторного выполнения для оценки требований к пространству/производительности. Только тестирование в реальных условиях даст гарантированный результат. На примере представленного выше сценария вы сможете понять, как определить этот объем для своих объектов и транзакций.

Можно ли отключить генерацию записей в журнал повторного выполнения?

Этот вопрос задают очень часто. Простой и короткий ответ - нет . Журнализация данных повторного выполнения принципиально важна для базы данных и расходы на нее нельзя считать потерей ресурсов. Журнализация действительно необходима, как бы