Не уверен, как таблица изменяется после оператора вставки.
Представьте себе простую таблицу:
create table x(
x int,
my_sum int
);
и триггер AFTER INSERT FOR EACH ROW,аналогично вашему, который вычисляет сумму всех значений в таблице и обновляет столбец my_sum
.
Теперь представьте себе этот оператор вставки:
insert into x( x )
select 1 as x from dual
connect by level <= 1000;
Этот единственный оператор в основном вставляет 1000 записей, каждая со значением 1
, см. Эту демонстрацию: http://sqlfiddle.com/#!4/0f211/7
Поскольку в SQL каждый отдельный оператор должен быть ATOMIC (подробнее об этом здесь: Согласованность чтения на уровне оператора , Oracle может выполнить этот запрос любым способом, пока конечный результат верен (непротиворечиво)Он может сохранять записи в порядке выполнения, может быть в обратном порядке, он может разделять пакет на 10 потоков и делать это параллельно.
Поскольку триггер срабатывает индивидуально после вставки каждой строки, и он не может знать заранее «конечный» результат, тогда, учитывая вышеизложенное, возможны все нижеприведенные результаты в зависимости от «внутреннего» метода, выбранного Oracle для выполнения этого запроса. Как видите, эти результаты не соответствуют определению согласованностиИ Oracle предотвращает эту ошибку выдачи мутирующей таблицы.
Другими словами - ваши предположения неверны, а вашиesign имеет недостатки, вам нужно изменить его.
| X | MY_SUM |
|---|--------|
| 1 | 1 |
| 1 | 2 |
| 1 | 3 |
| 1 | 4 |
...
...
или, может быть:
| X | MY_SUM |
|---|--------|
| 1 | 1000 |
| 1 | 1000 |
| 1 | 1000 |
| 1 | 1000 |
| 1 | 1000 |
| 1 | 1000 |
| 1 | 1000 |
...
или, может быть:
| X | MY_SUM |
|---|--------|
| 1 | 4 |
| 1 | 8 |
| 1 | 12 |
| 1 | 16 |
| 1 | 20 |
| 1 | 24 |
| 1 | 28 |
...
...