чем же Update t set @a = a недокументированый ?
Да и можно вообще
Update t set a = a ...

ASCRUSА как это в пределах одной сессии можно дедлок вызвать или я чего то не понял ? В ASA к примеру этот код никаких проблем не вызовет, там придется не мало постараться, чтобы дедлок получить.

Никак. гонит он.

CripА че кстати в row level locking в ASE сделано лучше чем в MSSQL2000?
То что при уровне изоляции read committed не блокируется все записи до конца запроса? Может быть это и хорошо только в MSSQL любой запрос благодаря этому отдельно становится как бы repeatable read, а в ASE получается, что если уровень изоляции не поднять то можно получить несогласованные данные.
То, что ты реально можешь добиться блокировки ТОЛЬКО на уровне строк в какой-то таблице, если тебе это надо (правда, возможно, угрохав на это кучу ресурсов сервера (на время транзакции), но это уже другой вопрос - раз надо , значит надо). В MSSQL все решает сам сервер, настроек нет.

CripА че кстати в row level locking в ASE сделано лучше чем в MSSQL2000?
То что при уровне изоляции read committed не блокируется все записи до конца запроса?


Ты хоть понял, что сказал ? Все блокируется, транзакция не может не блокировать записи. Только блокируются СТРОКИ, и всегда (если настроить) Ну и соотв. дальнейшие твои расс. - ерунда полная, никаких несогласованных данных нет.

CripЧего это я гоню?

Не бывает DEADLOCK-а самого с собой. Если ты его видел - это значит, что тебе показалось.

Crip
Я говорил о том что в MSSQL на уровне изоляции read committed блокируется все строки учавствующие в запросе до конца соответствующего стейтмента, то есть как будто бы устанавливается изоляция repeatable read для отдельного стейтмента.


На сколько я помню, в MSSQL на read commited SHAREDLOCK-и на прочитанные данные снимаются по окончании чтения страницы (или записи), точно таким же образом, как это делается и в ASE, от которого и унаследован код сервера. Так было и в 6.0, и в 6.5. Может быть поманялось в 7. - 2000 - хотя вот цитата из BOL

BOL
The duration of share locks used to protect reads depends on the transaction isolation levels. At the default transaction isolation level of READ COMMITTED, a share lock is held only as long as it takes to read a page. In scans, the lock is held until a lock is acquired on the next page in a scan. If the HOLDLOCK hint is specified, or the transaction isolation level is set to either REPEATABLE READ or SERIALIZABLE, the locks are held to the end of the transaction.


Так что подозреваю что никакого блокирования до конца statement-а и никакого repeatable read на read commited не существует.

Crip
В Sybase ASE это не так, если дополнительно не настраивать

Что и как настраивать ?

Crip
то в запросе на уровне read committed происходит только защита от грязного чтения,


А интересно от чего еще нужно защищаться на уровне изоляции READ COMMITED, как ты полагаешь ?

Crip
в результате чего читатели(select в одной сессии) не блокируют писателей(update в другой сессии).


Нет, к сожалению, именно блокируют. И происходит это и в MSSQL, и в ASE. Если читатель читает например страницу данных, а в это же время писатель в другой сессии хочеть поменять эту страницу данных, то писатель будет ждать до тех пор, пока читатель не закончит чтение и не снимет Shared lock на страницу. Это может произойти по окончании чтения страницы (на read commited), или по окончании транзакции. Если ты посмотришь на таблицу совместимости блокировок, то увидешь, что SHARED не совместим с UPDLOCK.

Crip
Пожалуйста расскажите более подробно в чем я не прав, наверняка виновато мое так сказать "майкрософтовское" мышление.


Надеюсь, мне это удалось.

Напоследок могу сказать, что ASE действительно немного менее управляем в плане изоляции транзакций, чем MSSQL, но ... не там, где ты думаешь.

ASCRUS
Он имел ввиду, что SELECT и UPDATE в разных сессиях. То есть SELECT на чистом чтении блокирует только обрабатываемую на текущий момент запись и при переходе на следующую натыкается на эклюсивную блокировку UPDATE. В это время UPDATE пытается изменить запись, которая сейчас блокирована SELECT-ом, получается патовая ситуация (дедлок).


Если это действительно имелось в виду, то я абсолютно согласен - это ситуация DEADLOCK-а. Но она характерна для обоих серверов (ASE и MSSQL), а выходить из нее путем повышения изоляции на SELECT как-то не очень хорошо. Да и все равно

Crip
решается с помощью хинта в селект with updlock.


не поможет - что SHARED, что UPDATE с другим UPDATE несовместимы, и , что самое главное, накладываются они в процессе транзакции последовательно, по мере нахождения нужных записей.

А бороться - известно как, путем указания других (возможно одинаковых) последовательностей сканирования таблиц.

Crip
Извините, но вы ведете себя как преподаватель, который уже решил какую оценку поставить студенту и пытается только доказать, что именно ее студент и заслуживает.
Наша задача не доказать друг другу кто умнее, тем более, что в уровне ваших знаний никто не сомневается, а выяснить истину. Быть может кому-то это еще пригодится, тем более, что людей разбирающихся в Sybase не так много.

Вот интересно. Я тебе привел кусок из MSSQL-евской буки, где черным по белому написано, что и в MSSQL Shared снимается тут же при окончании чтения страницы. Ты же опять :

Crip
В том то и проблема, что в Sybase ASE блокировки снимаются по мере того как страница будет считана (насколько я это понимаю, может ошибаюсь).
В MS SQL же насколько позволяют ресурсы происходит блокировка строк, причем она не снимается до того как все страницы не будут прочитаны.


Кому мне верить , официальной документации или тебе ?

Crip
Никто не выходит из нее повышением уровня изоляции.


Это кто писал ?
Crip
В MSSQL решается с помощью хинта в селект with updlock.

Это что не повышение ?

автор
Наоборот ситуация как раз возникает при повышение уровня изоляции выше read committed. В MSSQL есть специальный хинт updlock который говорит что при select нужно устанавливать не shared lock , а update lock, что позволяет избежать дедлока. В Sybase такого механизма я так понимаю нет, получается что нужно использовать предваряющий update.
автор


Механизма нет, но ситуацию с дэдлоком это не спасло бы все равно. Что одна, что другая блокировка несовместима (в ASE по крайней мере) c UPDLOCK. Так что deadlock все равно будет.

И еще ты мне так и не сказал , от чего еще нужно защищаться на уровне изоляции READ COMMITED, кроме грязного чтения.

Блин, надоело квотировать...

Ну не совсем... Для повышения уровня изоляции служит все-таки другой хинт.

Это именно оно и есть. Повышение. Только не в терминах ANSI isolation, а просто по жизни. Да и не вдруг ты сможешь сказать, какой это уровень в ANSI будет, там вообще такого нет, чтобы изоляция одной таблицы была бы выше других.

Предваряющий update однако помогает в ASE, по поводу MSSQL см. статью.

Да не помогает, причем ни там, ни там. То же самое будет, главное сканирование с разных концов таблицы обеспечить. Экслюзивная блокировка таблицы только помогает. Ну да ладно, не суть, от DEADLOCKов вообще говоря никогда полностью не избавишься.

А вот я могу сказать , чем ASE "хуже" MSSQL - на нем такого вот типа запрос для генерации следующего значения ключа в таблице

ну ни за что не засериализуешь - будут генерироваться одинаковые значения при интенсивных вставках.

Единственное я тогда не понимаю чем же row level locking в ASE лучше чем в MSSQL2000?

Завтра напишу.

Я тоже должен покаяться - я тут говорил про несовместимость SharedLock и UpdateLock. Так вот писал UpdateLock, а имел в виду на самом деле ExclusiveLock. Т.е не тот , который на фазе сканирования при UPDATE накладывается, а который на фазе изменения уже.

Да прочитал я статью - почти ничего нового для себя не почерпнул (т.е. мои знания MSSQL не так и устарели), окромя одной вещи - что для блокировки строки или страницы в кластерной таблице используется key lock. Вот это интересно, но им (MS-у) это ничего кроме разве что экономии lock-ов особенно не дает.