Решил этот же тест прогнать на рабочей машине, заодно поиграться с блокировками. На рабочей машине стоят SATA винты и процессор Intel P4 2,4 (HT - получается 2 процессора, оба разрешены для использования в ASA).
В итоге:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
// Обновляем миллион записей одной транзакцией в чистом виде
BEGIN
UPDATE table1
SET value = value + 1 ;
COMMIT;
END;
-- Execution time: 22.828 seconds
-- 1000000 record(s) affected
// Обновляем миллион записей одной транзакцией в чистом виде
// с блокировкой всей таблицы
BEGIN
LOCK TABLE table1 IN EXCLUSIVE MODE;
UPDATE table1
SET value = value + 1 ;
COMMIT;
END;
-- Execution time: 15.187 seconds
-- 1000000 record(s) affected
// Обновляем миллион записей одной транзакцией с триггером
BEGIN
UPDATE table1
SET value = value + 1 ;
COMMIT;
END;
-- Execution time: 60.985 seconds
-- 1000000 record(s) affected
// Обновляем миллион записей одной транзакцией с триггером
// и блокировкой таблицы
BEGIN
LOCK TABLE table1 IN EXCLUSIVE MODE;
UPDATE table1
SET value = value + 1 ;
COMMIT;
END;
-- Execution time: 54.265 seconds
-- 1000000 record(s) affected
// Меняем триггер, убирая из него изменение полей
ALTER TRIGGER init BEFORE UPDATE
ORDER 1 ON table1
REFERENCING NEW AS NewValue
FOR EACH ROW
BEGIN
IF NewValue.value IS NULL
THEN
RAISERROR 20000 'Гы';
RETURN;
END IF;
END;
-- Execution time: 0.016 seconds
// Обновляем миллион записей одной транзакцией с триггером
// и блокировкой таблицы
BEGIN
LOCK TABLE table1 IN EXCLUSIVE MODE;
UPDATE table1
SET value = value + 1 ;
COMMIT;
END;
-- Execution time: 50.625 seconds
-- 1000000 record(s) affected
Что можно по этому тесту сказать - если вешать эклюсивную блокировку на таблицу, то массовые обновления идут быстрее (кто бы в принципе и сомневался). Однако напрашивается еще один приятный вывод - позаписные блокировки в ASA реализованы достаточно граммотно, быстро и не кушают ресурсов, так как не такая уж большая разница во времени получилась на обновление между миллионом позаписных блокировок и одной табличной блокировкой (в среднем по всем тестам 5 сек).
Следующий вывод - BEFORE триггера, изменяющие записи, гораздо тяжелее, чем не делающие это. Кстати я тоже в этом не сомневался, так как могу точно сказать, что ASA крутит WatcomSQL c космической скоростью (взять хотя бы мой написанный на нем компилятор MacroSQL или на его основе написанный просмоторщик клипперных программ, загружающий их в БД, с преобразованием их скрипты в виде HTML веб-сервиса с подсветкой перехода на функции и таблицы для просмотра в браузере с целью снятия головной боли разбора чужих исходников на Clipper 5.0). Я думаю в данном случае при изменении записей в триггерах тормозит сама архитектура работы ASA, так как судя по всему порядок выполнения DML осуществляется в порядке для каждой записи:
1. DEFAULT
2. Блокировка
3. BEFORE FOR EACH ROW Триггера
4. CHECK
5. FOREIGN KEY
6. Физ.опер.записи в страницу, лог и индексы
7. SYSTEM CASCADE FOR EACH ROW Триггера
8. AFTER FOR EACH ROW Триггера
Схема приведена упрощенная, например, те же CASCADE могут вызываться по опции не как AFTER, а как BEFORE. С моей точки зрения кстати схема достаточно эффективная, так как любой BEFORE TRIGGER может вызвать исключение и произойдет откат изменений только всех успевших измениться записей (и блокировок тоже), а не всего массива записей, соотвествующе и откат произойдет быстрее. Тормоза же с триггерами думаю можно обьяснить не сколько замедлением выполнения из за выполнения WatcomSQL, сколько расширенным выделением ресурсов на выполнение триггеров, стоит помнить, что в ASA есть область видимости локальных временных таблиц, глобальных переменных и прочих фич, которые тоже напрягают сервер, да и выделение записных переменных или таблиц в REFERENCING тоже надо думать не прибавляет скорости.
Общий вывод - в FB2 триггеры работают гораздо шустрее, в ASA на массовые операции во многих случаях лучше вешать AFTER TRIGGER FOR EACH STATEMENT.
P.S. Кстати вопросик к dimitr - массовые вставки конечно же лучше проводить через специальные команды или утилиты (bcp, LOAD TABLE и т.д.). Как с этим обстоят дела у FB2 ? Например в ASA миллионы записей грузяться через LOAD TABLE достаточно шустро, эта команда не организует блокировок и работает на CHECKPOINT, как в принципе и REORGINIZE TABLE - кстати эти обе команды навевают на мысль, что CHECKPOINT в ASA (который позволяет БД работать и без лог-файла) подозрительно напоминает версионные принципы работы :)
