Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
output параметры влияют только на мое понимание кода :) P.S> Ответьте хоть - заработал мой первый вариант или нет? Или на чем вы остановились? Надеюсь не на nolock?:) PPS> read commited я написал просто я ясности (так как в первом варианте был repeatable read) PPPS> Если при соединении с сервером уровень изоляции выставляется в SERIALIZABLE - значит таковы настройки соединения - их, конечно же, можно изменить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2004, 09:44 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
COM или COM+ используется? Если COM+ то да, там выставляется Serialazable. Для COM-компонентов, про которые тут было написано - это надо смотреть компоненты, что они делают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2004, 10:00 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Народ, на несколько дней в отпуск ушел :) COM объект не сидит в COM+. А сам я не открываю транзакцию, поскольку транзакция в процедуре. Через пару дней проверю! Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2004, 11:42 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Ну вот на самом интересном месте, а на время отпуска твой хинт тебя и подведет, тьфу.., тьфу конечно. А клиент должен быть ни при чем, все делать надо в ХП, как советуют тут многоуважемые funikovyuri и Magnus ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2004, 12:05 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Действительно облом. :) Глядишь ветку вообще на ГФ перекинут и нам ничего не достанется, т.к. то что мы тут мучимся, для Глори - полпинка. :) Я вообще не понимаю откуда у него локи на одной транзакции. Порядок операторов тот же. И Если стоит Read Commited то никаких локов и близко быть не должно... Значит все таки уровень изоляции другой. Или он не все говорит :), может кто другой лочит? Первый селект по идее не должен выставлять wide lock на всю таблицу, макцимум row lock, можно для проверки и хинт поставить. А вообще не мешало бы и на планы взглянуть :). Magnus ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2004, 16:50 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Magnus23 Еще как может -> Например первый поток выполнил 1й select - зделал на выборке shared lock 2й поток выполнил 1й select - зделал тоже самое первый поток пытается выполнить update но на нем уже есть shared lock от второго потока - так что X получить не удаеться - т.е. он начинает ждать 2й поток второй поток пытаеться сделать update - и тоже ждет - но теперь уже 1й поток ТОГО: deadlock :( P.S> Эта процедура в том виде в котором ее нам показали - прямой кандидат в readtable read - так как он при первом же select'е воспользуется X блокировкой - вот так... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2004, 17:34 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Хм. Да. Если у обоих шаред, то но один не сможет конверануть. Но в таком варианте как у него , транзакция быстрая и дедлоки должны быть событием редким. Апдейтится то только отдельные строки. В таком случае на первом селекте ставим UPDLOCK. А? :) или RID Magnus ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2004, 18:08 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Off: >А вообще не мешало бы и на планы взглянуть :). А с этого обычно он (глори) и начинает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.03.2004, 18:13 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Magnus23 В таком случае на первом селекте ставим UPDLOCK Можно - но я на хинты смотрю как на workaround - когда необходимое либо не возможно стандартными средствами, либо нужна косметическая доводка кода - а так я за все стандартное - в данном случае за repeatable read - который сделает тоже самое, но imho - красивше... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2004, 09:33 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
так - каюсь.... нужно использовать либо UPDLOCK, либо менять логику работы процедуры... PS> мда... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2004, 09:50 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
А вообще еще интересно расмотреть вариант с автоматической транзакцией (COM+), а из процедуры все хинты и явное объявление транзакций повыкидывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2004, 10:07 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Зачем нужен подзапрос в Update? Почему бы не записывать значения столбцов в переменные прямо в Update? Возможно всё-таки удастся обойтись без транзакций. Следующее написано на основе первого варианта процедуры: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.03.2004, 14:30 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Привет, народ! Вариант процедуры с READ COMMITTED - работает, собака! :) По-моему самое лучшее решение! Значит по умолчанию транзакция открывается в режиме Serialize! Спасибо всем за помощь!!!!! До связи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 11:28 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
угу - только не всегда правильно - ну да это не важно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 13:55 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
О! Обьявился :). Значит таки Serializable. Зашибись :), будет рид коммитед. Magnus ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 17:36 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Привет еще разок! Все равно, мне кажется, что есть какaя-то проблем с новым .NET провайдером(SqlClient). Делаю параллельные тесты Суть теста воспроизвести значительную нагрузку на аппликацию. Стер все триггеры с таблиц. 1. БЕЗ всякой транзакции запускаю select, связывающий несколько таблиц по LEFT OUTER JOIN(не знаю, важно ли это). Ключ для последующих update выбираю рандомально из select-a. Select приносит каждый раз один и тот же результат. 2. В одной транзакции делаю updates на пару таблиц из вышеприведенного select-a. Транзакцию открываю ReadCommited - глючит с тем же "...victim deadlock... bla bla...". Причем локируется select. И это на симуляции 5-ти одновременных юзеров! Может у кого есть идеи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 18:22 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Тут надо смотреть почему ключ возвращет тот же, потому и локи. Начнем сначала. :) 1.Тексты в студию. 2.Результаты тоже. 3.Планы! Планы! :) Magnus ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2004, 18:52 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
То что селект приносит одни и те же данные - это я так хочу :). Из этих данных выбираю рандомальную строчку, а из нее беру значение ключа и с этим ключем иду апдэйт делать. А как я планы покажу? Тут же приэттачить картинку нельзя.... Завтра пришлю queries на суд :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2004, 00:31 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
SET SHOWPLAN_TEXT ON и потом этот план в сорс теге на ковер. Блин, чуйствую дойдем мы таки до UPDLOCK, кстати ничего крамольного в этом не вижу :) Magnus ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2004, 15:53 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Привет, народ! Вот он, план! . Что-то есть нездоровое? :) Запрос: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. План: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2004, 10:32 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Погоди. В начале то вроде другой запрос был. А теперь уже этот? Ну да ладно. Гляжу я на него и с многим не согласен. Вот эта часть Код: plaintext 1. 2. 3. левый джойн и констатнта. А смысл? Ничего ведь не изменится. Вообще, там у тебя одни Left Join'ы , они там действительно нужны? Далее, вот это Код: plaintext 1. 2. чесно говоря, вообще ниче не понял. order_line.node_id in ('') or 1=1 - для меня бесмысленно. Если уж нужно проверить на пустую строку то order_line.node_id='' 1=1 - лишние телодвижения. По плану. Индексы давно проверял? У тебя кластерный индекс сканируется, чего быть не должно. Сделай апдейт индексов или дропани и создай заново. Код: plaintext 1=1 убрать а остальное вынести наверх в джойн. Там тоже должень быть Merge. Пошустрее должно быть. Кстати, обьясни все таки, каким боком участвует данный запрос в обсуждаемой ранее проблеме ? :) Magnus ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2004, 19:19 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
> Что-то есть нездоровое? :) Есть предлагаю в начале вынести этот запрос, в месте с планами на форум MS SQL, а потом сюда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2004, 09:32 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Привет, народ! 1. Маг, это уже несколько другая проблема. Я писал пару дней назад: ---------------------------- "И снова deadlock....но в другой ситуации." : Все равно, мне кажется, что есть какaя-то проблем с новым .NET провайдером(SqlClient). Делаю параллельные тесты Суть теста воспроизвести значительную нагрузку на аппликацию. Стер все триггеры с таблиц. 1. БЕЗ всякой транзакции запускаю select, связывающий несколько таблиц по LEFT OUTER JOIN(не знаю, важно ли это). Ключ для последующих update выбираю рандомально из select-a. Select приносит каждый раз один и тот же результат. 2. В одной транзакции делаю updates на пару таблиц из вышеприведенного select-a. Транзакцию открываю ReadCommited - глючит с тем же "...victim deadlock... bla bla...". Причем локируется select. И это на симуляции 5-ти одновременных юзеров! Может у кого есть идеи? ---------------------------- 2. По поводу непонятных параметров: этот запрос из аппликации строится динамически. В данном случае нет никаких дополнительных параметров и поэтому видим непонятные (in ' ') или 1=1, избавиться от которых на данном этапе не могу :(. Спасибо за советы по быстродействию и оптимизации. Попробую. Но, мне кажется это не связано с lock... 3. SA - укажи, пожалуйста, на нездоровое :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2004, 12:54 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
Дык я на темы кроме первого пста почти никогда не смотрю, вот и до их пор думал что воз и ныне там :) ОК. На счет непонятностей, лучше уж устроить так чтобы при отсутствии внятных условий вообще ничего не писать. Как видно из плана, те самые "лишние телодвижения" в любом случае не учитываются но парсятся. А это время. ну да ладно, это мелочи. Индексы все таки ни к черту. Если при поиске на range of values в кластерном индексе, где все должно летать, делается scan, лто это и есть нездорово. Почему локи? Честно говоря, непонятно. 2 селекта, оба делают shared, ну и далее? На ком локи? Больше никто не участвует? А вообще у тебя действительно 2 варианта: 1.Продолжать колупаться с нами. Вероятнее всего решим, но когда? :) 2. Таки вымнести на иквельный форум. Там Glory, pkarklin,АГ и иже с ними расколупают с пол-пинка и нам ничего не достанется ;( :) Но если тебе важнее скорость, то однозначно - туда. Magnus ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2004, 15:39 |
|
||
|
MSS и дедлок при запуске stored procedure...
|
|||
|---|---|---|---|
|
#18+
И только один человек заметил что в апдейте глупость написана. Из-за нее и блокировка идет, т.к. Сначала делается селект записи, а потом ее же пытаются изменить Код: plaintext 1. 2. 3. писать нужно так: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2004, 18:37 |
|
||
|
|

start [/forum/topic.php?fid=20&msg=32450840&tid=1439369]: |
0ms |
get settings: |
10ms |
get forum list: |
22ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
69ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
87ms |
get tp. blocked users: |
2ms |
| others: | 269ms |
| total: | 484ms |

| 0 / 0 |
