Доброго времени суток. Подскажите плз сдедующее...

У меня есть хранимая процедура, которая делает следующее:

SET CURRENT ISOLATION = UR;
SEARCHABLE UPDATE данных в таблице Т1;
COMMIT;
MERGE данных в таблице Т1 (UPDATE и INSERT);
COMMIT;
SET CURRENT ISOLATION = RESET;

К таблице Т1 привязаны 2 триггера FOR EACH STATEMENT которые делают выборку из T1 и обновляют T2;

База версии 9.5 на AIX 64.

Эта хранимка вызывается из нескольких потоков, тоесть concurrently, при этом позникает взаимная блокировка при доступе к таблице Т1. Не могу понять почему.
Ход моих мыслей следующий:
1) Я устанавливаю уровень изоляции UR при входе в процедуру, следовательно, запрсы на выборку должны выполнять dirty read - тоесть не ждать пока запись в Т1 будет разлочена.
2)Первый UPDATE блокирует обновлённые записи эксклюзивно, но последующий COMMIT снимет эти блокировки.
3)MERGE делает то же самое - X блокировка изменённых и вставленных записей, потом COMMIT.
4)Триггеры наследуют уровень изоляции UR - тоесть не ждут чьих-то блокировок на Т1.

Как мне кажется, такая схема не должна приводить к дэдлокам, НО они есть.
Господа эксперты, подскажите где изьян в моих рассуждениях.
Заранее спасибо.

Здравствуйте, Mark Barinstein

1) да
2) Статический.

PowerEdgeЗдравствуйте, Mark Barinstein

1) да
2) Статический.

По поводу статического SQL. Небольшое уточнение во избежание путаницы.
Насколько я понимаю sql в хранимке типа

CREATE PROCEDURE dbo.do_work()
BEGIN
UPDATE T1 SET A=B WHERE A=1;
COMMIT;
END;

ясляется статическим?

т.е. если явно в команде не указано

1)Тоесть в UPDATE можно указать WITH UR - и это позволит выполнить его с dirty read, но при этом обновлённые записи всё-равно блокируются эксклюзивно. Затем блокировки снимаются COMMIT-ом. Верно?

2) Насколько я понимаю, для MERGE нечто подобное "WITH UR" указать нельзя? Тоесть, если хранимка скомпилирована с уровнем изоляции CS, то запрос, укзанный в после "USING" будет ждать разблокирования записей?

3) Если я скомпилирую данную процедуру с уровнем изоляции UR, будет ли этот эровень использоваться тригеррами, срабатываемими при работе хранимки?

Mark Barinstein
2. Вы, естественно, не разрулите дедлоки писателей уровнями изоляции.

Я исхожу из того, что если процедура будет выполнять чтение в режиме dirty read, а изменения коммитить немедленно, то это поможет избежать взаимных блокировок (имеется в виду чтение и изменение данных в одной таблице при многопоточном выполнении процедуры).
Так ли это?

Марк, спасибо за советы.
Mark Barinstein"Немедленно" ничего не происходит.
В документации по COMMIT сказанно: "All locks acquired by the unit of work subsequent to its initiation are released, except necessary locks for open cursors that are declared WITH HOLD." Насколько я понимаю, не всё так просто? Можно, плс, ссылку где почитать подробнее?

Ага, ясно, спасибо большое. Буду разбираться дальше.

Mark BarinsteinPowerEdge,

Про что почитать?
Я в том смысле про "немедленно" говорил, что в общем случае не надо думать о команде, что она блокировки на все требуемые ресурсы накладывает сразу.
Например, приложение 1 может выполнить update, который изменяет несколько строк. Он не делает это мгновенно и для всех строк стразу.
2-е приложение в это же самое время может успеть обновить строки, до которых ещё 1-ое приложение не добралось, а потом попытаться обновлять строки, которые 1-е уже обновило.
Т.е. вы вообще можете получить дедлок на 2-командах от разных приложений...

А в данном случае, не поможет ли выполнение SELECT .. FOR UPDATE перед обновлением этих же записей? Или блокировка набора записей тоже осуществляется одна-за-одной и дэдлок тоже возможен?