Здравствуйте, hugo, Вы писали:
H>Здравствуйте, _d_m_, Вы писали:
___>>Уровень изоляции транзакций до serializable в нескольких (менее 5) запросах — есть хинты. Вот таким образом и надо работать с блокировками.
H>И при этом все стоят и нервно курят, пока один человек выполнит свой запрос? А если они только почитать чего-нить хотят, причем совсем не из тех таблиц, которые изменяет работающая в данный момент транзакция?
RTFM уважаемый, RTFM.
Во первых. Уточняю: <5 запросов на все приложение — а оно не маленькое. Там где это действительно необходимо.
Во вторых. Я бы сказал выполнит: связку запрос+(апдейт|вставка|удаление). Иначе, а зачем тогда serizlizable?
Во третьих. Они и затянуться не успеют.
В четвертых. Вопрос курения встанет, только если им потребуются имено в заблокированный диапазон данных (зачастую много меньше таблицы):
— писать до момента комита блокирующей транзакции;
— читать после изменения данных блокирующей транзакцией и до ее комита.
Заметь: как слово "диапазон" отличается от "вся таблица".
В пятых. Что им может помешать читать из любых других таблиц?
Здравствуйте, BlackTigerAP, Вы писали:
DemAS>>> Как вообще может возникнуть deadlock при работе с одним (и только одним) ресурсом ?
BTA>Лёгко!!! Достаточно вспомнить, что для SQLServer является "блокируемым ресурсом". Для танкистов — запись.
Ок. А теперь приведи пример работы, когда два процесса работая с одной записью взаимноблокируют друг друга.
BTA>Они же (процессы) не с одной записью работают.
Посмотри изначальный вопрос:
вопрос 1: если бы в хранимке была лишь одна инструкция insert возник бы dead lock?
вопрос 2: если бы в хранимке была лишь одна инструкция update(причем каждый поток апдейтит уникальную запись) возник бы dead lock?
... << RSDN@Home 1.2.0 alpha rev. 643>>
Re[3]: многопоточность и deadlock в mssql2000
От:
Аноним
Дата:
05.05.06 11:07
Оценка:
2 _d_m_:
Ага, по таким вот "сериализаторавщикам" даже на Channel9 прошлись люди из МС. После таких деятелей и рождаются мифы о нежизнеспособности приложений на SQLServer, и заказчики плюются и проклинают тот день и час, когда связались с SQLServer и уходят на Oracle.
Здравствуйте, BlackTigerAP, Вы писали:
BTA>2 _d_m_:
BTA>Ага, по таким вот "сериализаторавщикам" даже на Channel9 прошлись люди из МС. После таких деятелей и рождаются мифы о нежизнеспособности приложений на SQLServer, и заказчики плюются и проклинают тот день и час, когда связались с SQLServer и уходят на Oracle.
По каким таким? Что ты вообще обо мне знаешь?
Нет, наоборот. Мифы о нежизнеспособности SQLServer рождаются, когда некомпетентные в этих вопросах люди советуют блокировать таблицами. Мои клиенты себя чуствуют комфортно в том числе благодаря грамотно поставленным уровням изоляции. 99.9% запросов курят read commited и лишь уровень некоторых единичных запросов, там где это действительно необходимо — повышен до serializable.
L>вопрос 1: если бы в хранимке была лишь одна инструкция insert возник бы dead lock?
Зависит от того что за инсерт. Если Insert/select — да, возможен.
L>вопрос 2: если бы в хранимке была лишь одна инструкция update(причем каждый поток апдейтит уникальную запись) возник бы dead lock?
Зависит от того что за запрос. В общем случае — да, взаимоблокировка в этом случае возможна.
Re[5]: многопоточность и deadlock в mssql2000
От:
Аноним
Дата:
15.06.06 18:37
Оценка:
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, BlackTigerAP, Вы писали:
BTA>>2 _d_m_:
BTA>>Ага, по таким вот "сериализаторавщикам" даже на Channel9 прошлись люди из МС. После таких деятелей и рождаются мифы о нежизнеспособности приложений на SQLServer, и заказчики плюются и проклинают тот день и час, когда связались с SQLServer и уходят на Oracle.
___>По каким таким? Что ты вообще обо мне знаешь? ___>Нет, наоборот. Мифы о нежизнеспособности SQLServer рождаются, когда некомпетентные в этих вопросах люди советуют блокировать таблицами. Мои клиенты себя чуствуют комфортно в том числе благодаря грамотно поставленным уровням изоляции. 99.9% запросов курят read commited и лишь уровень некоторых единичных запросов, там где это действительно необходимо — повышен до serializable.
А также некритичные отчеты на hint nolock (клиенты чувствуют себя комфортно в меру загруженности сервака).
Да и maxdop 1 в большинстве случаев повышает производительность. (не знаю, как на более, чем двух (чеырех с HS)).
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _d_m_, Вы писали:
___>>Здравствуйте, BlackTigerAP, Вы писали:
BTA>>>2 _d_m_:
BTA>>>Ага, по таким вот "сериализаторавщикам" даже на Channel9 прошлись люди из МС. После таких деятелей и рождаются мифы о нежизнеспособности приложений на SQLServer, и заказчики плюются и проклинают тот день и час, когда связались с SQLServer и уходят на Oracle.
___>>По каким таким? Что ты вообще обо мне знаешь? ___>>Нет, наоборот. Мифы о нежизнеспособности SQLServer рождаются, когда некомпетентные в этих вопросах люди советуют блокировать таблицами. Мои клиенты себя чуствуют комфортно в том числе благодаря грамотно поставленным уровням изоляции. 99.9% запросов курят read commited и лишь уровень некоторых единичных запросов, там где это действительно необходимо — повышен до serializable.
А>А также некритичные отчеты на hint nolock (клиенты чувствуют себя комфортно в меру загруженности сервака). А>Да и maxdop 1 в большинстве случаев повышает производительность. (не знаю, как на более, чем двух (чеырех с HS)).
А>Michail Chernobrovov.
hint nolock — спорно. А вот в 2005-ом появилась прикольная возможность — опция базы READ_COMMITTED_SNAPSHOT. Вот это весчь.
Здравствуйте, DemAS, Вы писали:
DemAS>>>> Как вообще может возникнуть deadlock при работе с одним (и только одним) ресурсом ?
BTA>>Лёгко!!! Достаточно вспомнить, что для SQLServer является "блокируемым ресурсом". Для танкистов — запись.
DAS> Ок. А теперь приведи пример работы, когда два процесса работая с одной записью взаимноблокируют друг друга.
Пример:
/*
CREATE TABLE Test (Id int)
INSERT Test VALUES (1)
*/BEGIN TRAN
SELECT Id FROM Test(HOLDLOCK) WHERE Id = 1
WAITFOR DELAY '00:00:10'
UPDATE Test
SET Id = 1
WHERE Id = 1
COMMIT
Работают с одной записью, дэдлок возникает, условие выполнено
Здравствуйте, MoZ, Вы писали:
MoZ>Здравствуйте, DemAS, Вы писали:
DemAS>>>>> Как вообще может возникнуть deadlock при работе с одним (и только одним) ресурсом ?
BTA>>>Лёгко!!! Достаточно вспомнить, что для SQLServer является "блокируемым ресурсом". Для танкистов — запись.
DAS>> Ок. А теперь приведи пример работы, когда два процесса работая с одной записью взаимноблокируют друг друга. MoZ>Пример: MoZ>
MoZ>/*
MoZ>CREATE TABLE Test (Id int)
MoZ>INSERT Test VALUES (1)
MoZ>*/
MoZ>BEGIN TRAN
MoZ>SELECT Id FROM Test(HOLDLOCK) WHERE Id = 1
MoZ>WAITFOR DELAY '00:00:10'
MoZ>UPDATE Test
MoZ> SET Id = 1
MoZ>WHERE Id = 1
MoZ>COMMIT
MoZ>
MoZ>Работают с одной записью, дэдлок возникает, условие выполнено
Здравствуйте, _d_m_, Вы писали:
MoZ>>Работают с одной записью, дэдлок возникает, условие выполнено
___>Дэдлок не возникает. Т.к. это не дэдлок.
А что же это?
Server: Msg 1205, Level 13, State 54, Line 1
Transaction (Process ID 53) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Каким образом проверяли? В условии было сказано —
два процесса работая с одной записью взаимноблокируют друг друга
Здравствуйте, MoZ, Вы писали:
MoZ>>>Работают с одной записью, дэдлок возникает, условие выполнено
___>>Дэдлок не возникает. Т.к. это не дэдлок.
MoZ>А что же это? MoZ> MoZ>Server: Msg 1205, Level 13, State 54, Line 1 MoZ>Transaction (Process ID 53) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. MoZ>
Взаимоблокировка, как можно понять из названия – это ситуация, когда транзакции блокируют друг друга таким образом, что дальнейшее выполнение невозможно. В силу протокола двухфазной блокировки ни одна из участвующих во взаимоблокировке транзакций не может отпустить уже захваченные ей ресурсы до того, как наложит блокировки на все, что ей необходимо. А получить все необходимые ресурсы мешают уже наложенные блокировки. Таким образом, получается замкнутый круг. Естественно, и транзакций, и объектов в общем случае может быть сколь угодно много. Разорвать такую блокировку без внешнего вмешательства невозможно, и если не предпринимать специальных усилий, то транзакции будут находиться в состоянии ожидания бесконечно долго. Разрешить подобную ситуацию можно лишь путем отмены хотя бы одной из транзакций.
MoZ>Каким образом проверяли? В условии было сказано —
два процесса работая с одной записью взаимноблокируют друг друга
— так и проверяли, запускали два процесса?
Для каждого соединения MS SQL создает процесс — не путать с процессами ОС.
из этой статьи — это практически тот же пример, что пивел MoZ. Так что он полностью прав это классический дедлок, причем один из самых распространенных случаев, как практика показывает.
из этой статьи — это практически тот же пример, что пивел MoZ. Так что он полностью прав это классический дедлок, причем один из самых распространенных случаев, как практика показывает.
Да, приношу извинения. Не заметил хинт holdlock в исходном посте.
Здравствуйте, SergPas, Вы писали:
SP>блокировки со строки до страницы и так до таблицы в целом. После чего вероятность deadlock возрастает.
Наоборот. Вероятность блокировки других транзакций возрастает, а deadlock — уменьшается.
Здравствуйте, GlebZ, Вы писали:
GZ>Наоборот. Вероятность блокировки других транзакций возрастает, а deadlock — уменьшается.
Тут вообще нельзя однозначно утверждать, все зависит от запросов, структуры таблиц и распределения данных — может как увеличить вероятность дедлока так и уменьшить.
Мы уже победили, просто это еще не так заметно...
