|
|
su.dbms- SU.DBMS ---------------------------------------------------------------------- From : Vadim Rumyantsev 2:5030/301 31 May 2001 13:28:34 To : Fedor 'Cruger' Tersin Subject : Hа: Informix ? -------------------------------------------------------------------------------- В сpеду, 30 мая 2001 18:56:29, Fedor 'Cruger' Tersin писал to Vadim Rumyantsev: VR>> Твой пример на самом деле показывает как минимум 3 недостатка VR>> MSSQL: отсутствие триггеров before, отсутствие триггеров for each VR>> row и наличие блокировок на индексах. Если бы не было хотя бы VR>> одного из трёх, всё бы срабатывало. FT> Hе факт, потому что трабл происходил при апдейте одной единственной FT> записи, а не выборки. Я внимательно перечитал твоё письмо и понял, что упустил из виду четвёртый недостаток: страничную блокировку индексов, про которую ты пишешь. Понятно, что проблема не возникает, если блокируется не больше одной записи, а вот то, что такая массовая блокировка может случаться не только из-за "общих" триггеров, но и из-за блокировки страницами -- я упустил из виду. VR>> С моей точки зрения, настоящий корень всех бед как раз в третьем VR>> недостатке. Более того, из-за этой... м-м... особенности MSSQL VR>> частенько незаслуженно страдает репутация и других блокировочных VR>> серверов, у которых в данном отношении всё в порядке ;) FT> Может быть дело в том, что MSSQL блокирует что то до изменения, а не FT> после? Как можно блокировать после изменения??? _Что_ блокировать? * * * Для сравнения, в DB2 индексные блокировки ставятся не на сам индекс, а на запись в таблице, к которой конкретный элемент индекса относится. За счёт этого deadlock'и между индексным и табличным доступом оказываются невозможны. Sincerely, Vadim. --- GoldED/2 3.0.1-GP * Origin: Electronic Kludge (2:5030/301) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms/22163b164705.html, оценка из 5, голосов 10
|