Каморка

Есть, вероятно, кривые апликации. Один и тотже PID блокирует сам себя (select), иногда другой PID (другого юзера и проиложения). Как селект может блокровать другой селект?

vg писал(а):Есть, вероятно, кривые апликации. Один и тотже PID блокирует сам себя (select), иногда другой PID (другого юзера и проиложения). Как селект может блокровать другой селект?

Я не особый спец, но у меня так было:
Одна и таже SP запускалась многократно практически одновременно. Влетал непредсказуемо в дедлоки.
Насколько разобрался, сервер сначала ставит как бы промежуточную блокировку, которую потом переводит в номальную, на запись. Несколько промежуточных блокировок + одна на запись, которая не идет из-а других промежуточных одновременно и вызывают дедлок.
Борюсь с этим, выставляя сразу эксклюзивный лок на таблицу до конца транзакции, что и подразумевалось неяно.

vg писал(а):Есть, вероятно, кривые апликации. Один и тотже PID блокирует сам себя (select), иногда другой PID (другого юзера и проиложения). Как селект может блокровать другой селект?

пример того как селект блокирует сам себя в студию!

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

Leo Gan писал(а):

vg писал(а):Есть, вероятно, кривые апликации. Один и тотже PID блокирует сам себя (select), иногда другой PID (другого юзера и проиложения). Как селект может блокровать другой селект?

Я не особый спец, но у меня так было:
Одна и таже SP запускалась многократно практически одновременно. Влетал непредсказуемо в дедлоки.
Насколько разобрался, сервер сначала ставит как бы промежуточную блокировку, которую потом переводит в номальную, на запись. Несколько промежуточных блокировок + одна на запись, которая не идет из-а других промежуточных одновременно и вызывают дедлок.
Борюсь с этим, выставляя сразу эксклюзивный лок на таблицу до конца транзакции, что и подразумевалось неяно.

код надо грамотно писАть и дедлоки будут очень и очень редко....

СП например делает селект, апдейт примерно тогоже сета.... если хинт правильно на первом селекте не выставил пто вот тебе и дедлок. эксклюзивный лок ставить не не стОит... пришли мне код СПшки в ЛС, посмотрю может без него обойдешься

папа Карло писал(а):

vg писал(а):Есть, вероятно, кривые апликации. Один и тотже PID блокирует сам себя (select), иногда другой PID (другого юзера и проиложения). Как селект может блокровать другой селект?

пример того как селект блокирует сам себя в студию!

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

проблема в том, что SP запускается практически одновременно во многих экземплярах (BizTalk сообщения свои параллельно обрабатывает, вот он эту SP мне и запускает). Код пришлю на экспертизу, спасибо заранее. С меня причитается

папа Карло писал(а): пример того как селект блокирует сам себя в студию!

http://support.microsoft.com/default.aspx/kb/906344
http://support.microsoft.com/kb/821740

Stranger писал(а):

папа Карло писал(а): пример того как селект блокирует сам себя в студию!

http://support.microsoft.com/default.aspx/kb/906344
http://support.microsoft.com/kb/821740

это известная фишка 2000. вопрос в том что оно отваливается из-за этого.

Stranger писал(а):

папа Карло писал(а): пример того как селект блокирует сам себя в студию!

http://support.microsoft.com/default.aspx/kb/906344
http://support.microsoft.com/kb/821740

Спасибо.

Уважаемыи vg. К сожалению полностью блокировок не избежать, однако их можно/нужно минимизировать.SELECT держут Locks только пока считыватеся дата, а не на протяжение всеи трансакции.

Возьми этот SELECT и попытаися его оптимизировать, посмотри или оптимазер использует индехы , какие параметры в WHERE условии и т.д

Yuri Dimant писал(а):Уважаемыи vg. К сожалению полностью блокировок не избежать, однако их можно/нужно минимизировать.SELECT держут Locks только пока считыватеся дата, а не на протяжение всеи трансакции.

Возьми этот SELECT и попытаися его оптимизировать, посмотри или оптимазер использует индехы , какие параметры в WHERE условии и т.д

Это ясно. Побочный эффект - другие юзеры пости не могут с базой работать. Загрузка СПЮ - 0. Просто всё колом становится. Если так буде продолжаться, скорее начальство попросит ту апликацию посмотреть (там писано на ВБА для экселя 2003).

папа Карло писал(а):

Leo Gan писал(а):

vg писал(а):Есть, вероятно, кривые апликации. Один и тотже PID блокирует сам себя (select), иногда другой PID (другого юзера и проиложения). Как селект может блокровать другой селект?

Я не особый спец, но у меня так было:
Одна и таже SP запускалась многократно практически одновременно. Влетал непредсказуемо в дедлоки.
Насколько разобрался, сервер сначала ставит как бы промежуточную блокировку, которую потом переводит в номальную, на запись. Несколько промежуточных блокировок + одна на запись, которая не идет из-а других промежуточных одновременно и вызывают дедлок.
Борюсь с этим, выставляя сразу эксклюзивный лок на таблицу до конца транзакции, что и подразумевалось неяно.

код надо грамотно писАть и дедлоки будут очень и очень редко....

СП например делает селект, апдейт примерно тогоже сета.... если хинт правильно на первом селекте не выставил пто вот тебе и дедлок. эксклюзивный лок ставить не не стОит... пришли мне код СПшки в ЛС, посмотрю может без него обойдешься

папа, спасибо за помощь!!! Респект!

Уважаемыи vg, будьте pro-active и быстренько лезьте в аппликацию оптимизировать код