этом разделе мы рассмотрим только один вопрос: как работают временные таблицы с точки зрения журнализации?

Для блоков временных таблиц данные повторного выполнения не генерируются. Поэтому действия с временной таблицей невосстановимы . При изменении блока во временной таблице запись этих изменений в файлы журнала повторного выполнения не выполняется. Однако при работе с временными таблицами генерируется данные отмены, и эти изменения в сегменте отката журнализируются. Поэтому при работе с временными таблицами генерируется некоторый объем данных повторного выполнения. На первый взгляд это кажется абсолютно бессмысленным: зачем генерировать данные отката? Потому, что в транзакции можно откатиться до точки сохранения. Можно удалить последних 50 вставленных во временную таблицу строк, но не первых 50. Для временных таблиц можно задавать ограничения и все прочие конструкции, доступные для обычных таблиц. Может произойти сбой на 500 строке оператора вставки 500 строк, т.е. потребуется откат оператора. Поскольку временные таблицы ведут себя так же, как обычные , при работе с ними обязательно должны генерироваться данные отката. Поскольку данные в сегменте отката должны журнализироваться, при генерировании данных отката будет генерироваться и некоторый объем данных повторного выполнения.

Все не так страшно, как кажется. С временными таблицами используются в основном SQL-операторы INSERT и SELECT. К счастью, операторы INSERT генерируют немного данных отмены (блок необходимо восстановить в состояние ничего , а для хранения ничего надо не так уж много места), а операторы SELECT данные отмены вообще не генерируют. Поэтому, если временные таблицы используются исключительно для вставки и запросов, этот раздел вполне можно проигнорировать. Учитывать генерирование данных отмены надо только при использовании операторов UPDATE или DELETE.

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

tkyte@TKYTE816> create table perm

2 (x char(2000) default x,

3 у char(2000) default y,

4 z char(2000) default z)

Table created.

tkyte@TKYTE816> tkyte@TKYTE816>

tkyte@TKYTE816> create global temporary table temp

2 (x char(2000) default x,

3 у char(2000) default y.

4 z char(2000) default z)

5 on commit preserve rows

Table created.

Затем, я создал небольшую хранимую процедуру для применения указанного SQL-оператора к таблице и выдачи отчета о результатах:

tkyte@TKYTE816> create or replace procedure do sql(p sql in varchar2)

2 3 4

6 7 8 9 10 11 12 13 14 15 16 17

l start redo

l redo

begin

select value into

number;

number;

execute immediate commit;

l start redo from redo size; p sql;

select value-l start redo into l redo from redo size;

dbms output.put line

(to char(l redo, 9,999,999) bytes substr(replace(p sql, chr(10), ) ,

of redo generated 1, 25) ...);

end;

Procedure created.

Затем я применил к таблицам одинаковые операторы INSERT, UPDATE и DELETE:

tkyte@TKYTE816> set serveroutput tkyte@TKYTE816> begin

on format wrapped

2 3 4 5 6 7 8 9 10

12 13 14 15 16 17 18

do sql ( insert into perm

select 1,1,1

from all objects

where rownum <= 500);

do sql(insert into temp

select 1,1,1

from all objects

where rownum <= 500);

do sql( update perm set x = do sql( update temp set x =

do sql (delete from perm); do sql (delete from temp),;

2) ;

end;

3,238,688 bytes of redo generated

72,572 bytes of redo generated

2,166,376 bytes of redo generated

for for for

insert into perm ... insert into temp ... update perm set x = 2 ...

1,090,336 bytes of redo generated for update temp set x = 2 ... 3,320,244 bytes of redo generated for delete from perm ... 3,198,236 bytes of redo generated for delete from temp ...

PL/SQL procedure successfully completed.

Этот пример демонстрирует следующее.

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

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

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

Поэтому при работе с временными таблицами можно использовать следующие простые правила:

оператор INSERT генерирует мало или вообще не генерирует данные отмены/ повторного выполнения;

оператор DELETE генерирует тот же объем данных повторного выполнения, что и для обычной таблицы;

оператор UPDATE генерирует примерно вдвое меньше данных повторного выполнения, чем для обычной таблицы.

Из этого правила есть исключения. Например, при замене пустого (NULL) столбца 2000 байт данных оператор UPDATE сгенерирует очень мало данных для отката. Такое изменение подобно вставке. С другой стороны, если столбец с 2000 байт данных становится пустым (NULL), такое изменение подобно удалению с точки зрения объема генерируемых данных повторного выполнения. В среднем можно ожидать, что при изменении временной таблицы генерируется примерно 50 процентов данных отмены/ повторного выполнения от объема для обычной таблицы.

При определении объема создаваемых данных повторного выполнения можно руководствоваться здравым смыслом. Если выполняемая операция приводит к созданию данных отмены, подумайте, насколько легко или сложно будет восстановить (отменить) результат операции. Вставку 2000 байт отменить просто. Надо вернуть ситуацию, когда было 0 байт. Если удалено 2000 байт, для восстановления придется 2000 байт вставить. В этом случае генерируется значительный объем данных повторного выполнения.