|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Practh 2:5020/400 09 Jun 2001 11:08:54
To : All
Subject : Hа: Informix ?
--------------------------------------------------------------------------------
Hi!
"Vladimir Pavlikov" <pvv@soil.msu.ru> сообщил/сообщила в новостях следующее:
news:9fq5ll$6m3$2@host.talk.ru...
> > Hе скогласен! Если мне до начала транзакции известен список записей,
> > которые будут модифицироватся (типичная ситуация: обновление значения
> > остатков на счетах в триггере), то откуда может быть эскалация
количества
> > блокировок в самой транзакции? Вместо того, что бы их блокировать по
мере
> > выполнения транзакции, я просто беру и блокирую их сразу все.
>
> Чем дольше период блокирования, чем выше вероятность остановки
параллельных
> транзакций и больше время "зависа".
И что, если вместо того, что бы заблокировать все записи, а по мере их
обновления/удаления, то время их блокировки сократится?
>
> > Время выполнения одиночного SELECT на порядок меньше, чем время
UPDATE
> > на таким же наором записей и на нгесколько порядков меньше времени
> > выполнения всей транзакции. Это означает, что я могу получить "замок"
только
> > в момент выполнения самого SELECT, а значит шанс возникновения "замка"
> > уменьшается в сотни-тысячи раз.
>
> Речь не о замке, а о времени блокирования. С порядками ты погорячился,
> и почему речь только о update _на том же самом наборе_? Очень частный
> случай. Про "на нгесколько порядков меньше времени выполнения всей
> транзакции" я уж умолчу. Hо все же рассмотри транзакцию, состоящую
Даныне взяты на основании анализ плана выполнения всей транзакции...
> из selecta по громадной таблице и одного insert'а с количеством
> записей, удовлетворяющих условию selecta :))
Извини Володя, но deadlock при вставке - это действительно уникальная
операция. Если только подразумевается только чистая вставка.
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: Solver Ltd. site #2 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
