Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Добрый день, Заранее спасибо за любые предложения. Разбираюсь с дедлоками между параллельными вставками в таблицу. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Вставка происходит, только если вставляемых записей еще нет в таблице. Однако, при проверке наличия записи, блокировки на ключи поискового индекса IDX_TaskQueue_ReferenceId_UserId (ReferenceId, TaskQueueFunctionTypeId, TaskQueueTypeId, PlannedBeginDate, UserId, TaskQueueStateId) в разных потоках накладываются в разном порядке и возникают дедлоки. #TaskQueue_Sorted кластеризован по тем же полям, что и индекс IDX_TaskQueue_ReferenceId_UserId, но в плане он сканируется с Ordered = False. Можно ли как-то сделать скан #TaskQueue_Sorted сортированным, чтобы не было дедлоков? План запроса приложила. Если просто добавить в запросе Order by, то он в запросе добавляется слишком поздно, сразу после Nested Loops. Merge join, конечно, даст искомый ordered = true, но сканировать IDX_TaskQueue_ReferenceId_UserId - это слишком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 11:59 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Eleanor, а что вы этим добиваетесь? в EXISTS... особенно в контексте "вставок" авторFROM dbo.TaskQueue B WITH (UPDLOCK, ROWLOCK, HOLDLOCK) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 12:18 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
EleanorМожно ли как-то сделать скан #TaskQueue_Sorted сортированным Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Почему INSERT, а не MERGE? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 12:35 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
invm, Спасибо. C MERGE сложнее запись, потому что уже появилась бездумная привычка предварительно фильтровать целевую таблицу в CTE (иначе на некоторых условиях match, не помню каких, возникал scan). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 13:14 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
EleanorC MERGE сложнее запись, потому что уже появилась бездумная привычка предварительно фильтровать целевую таблицу в CTE Вопрос не по теме. Так стоит или не стоит предварительно фильтровать целевую таблицу в CTE при MERGE? Я так делаю даже без явной необходимости... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 13:33 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Андрей ЮниорEleanorC MERGE сложнее запись, потому что уже появилась бездумная привычка предварительно фильтровать целевую таблицу в CTE Вопрос не по теме. Так стоит или не стоит предварительно фильтровать целевую таблицу в CTE при MERGE? Я так делаю даже без явной необходимости... стоит, если например, нужно перезагружать таблицу полностью по фильтру Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 16:02 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
EleanorC MERGE сложнее записьКак по мне, то это дело вкуса. Зато у MERGE гибче OUTPUT и не нужно явно указывать updlock. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 17:04 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Руслан Дамировичстоит, если например, нужно перезагружать таблицу полностью по фильтру Когда по фильтру - да. У меня есть такие слияния: по месяцам, по кварталам с составными ключами. А в таком случае: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. это вредно? Смысл хоть какой-то есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 17:16 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Андрей ЮниорРуслан Дамировичстоит, если например, нужно перезагружать таблицу полностью по фильтру Когда по фильтру - да. У меня есть такие слияния: по месяцам, по кварталам с составными ключами. А в таком случае: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. это вредно? Смысл хоть какой-то есть? Сравните планы. Думаю, они будут идентичны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 17:21 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Eleanor, Д.Короткевич рекомендовал все таки не использовать MERGE (кроме удобства написания, все аналогично, только есть ряд покапотных глюков) вам точно (UPDLOCK, ROWLOCK, HOLDLOCK) внутри эксиста нужны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 18:02 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
StarikNavy, дык подкапотность возникает, если не читать справку, а делать "по аналогии". Что, в общем-то, недопустимо. Проблема у автора возникает из-за этого: INSERT INTO dbo.TaskQueue SELECT * FROM #TaskQueue_Sorted A WHERE NOT EXISTS ( SELECT 1 FROM dbo.TaskQueue B WITH (UPDLOCK, ROWLOCK, HOLDLOCK) Взаимоисключающие блокировки сами напрашиваются. Запрос надо разделить на две части - в первой произвести выборку пригодных для вставки строк, например, во временную таблицу или путем удаления из исходной таблицы, во второй части выполнить вставку этих строк. Даже при прочтении кода будет проще понять - что намеревался сделать автор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 18:13 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовЗапрос надо разделить на две части - в первой произвести выборку пригодных для вставки строк, например, во временную таблицу или путем удаления из исходной таблицы, во второй части выполнить вставку этих строк.А теперь расскажите нам, каким образом обеспечить сохранность пригодности для вставки в целевую таблицу строк, отобранных во временную таблицу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 18:46 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовПроблема у автора возникает из-за этого: В чем была проблема, invm уже помог исправить. Дедлоков на вставках больше нет. Очень приятно, что на форуме есть люди подобного уровня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2019, 23:28 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
invmВладислав КолосовЗапрос надо разделить на две части - в первой произвести выборку пригодных для вставки строк, например, во временную таблицу или путем удаления из исходной таблицы, во второй части выполнить вставку этих строк.А теперь расскажите нам, каким образом обеспечить сохранность пригодности для вставки в целевую таблицу строк, отобранных во временную таблицу? Точно так же как достигается повторяемость чтения в подзапросе с сортировкой, полагаю. Не вижу разницы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 12:09 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Eleanor, недостатком этого решения является то, что вы будете вынуждены заставлять" дуть ветер " в одну сторону при обновлениях этой таблицы из других процедур другими запросами. Т.е. равновесие, образно говоря, такого запроса будет неустойчивым, хорошо работать в частном случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 12:11 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Переписать эту дичь на LEFT JOIN и убрать WITH (UPDLOCK, ROWLOCK, HOLDLOCK) Сортировать это костыль ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 12:17 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовТочно так же как достигается повторяемость чтения в подзапросе с сортировкой, полагаю. Не вижу разницы.Т.е. в итоге получится исходный запрос, только заполняться будет временная таблица. Потом уже из этой временной переливаться в основную. И все это в явной транзакции. В чем профит? PS: Рекомендую поразмышлять - зачем нужны хинты updlock и holdlock. Подсказка: рассмотрите вариант, когда параллельные сессии обрабатывают одну и ту же строку, которой нет в целевой таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 12:39 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
invm, автор обрабатывают одну и ту же строку, которой нет в целевой таблице. целевая таблица TaskQueue , запрос на записей которых нет из TaskQueue - их не будет для всех сессий ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 12:50 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
TaPaKцелевая таблица TaskQueue , запрос на записей которых нет из TaskQueue - их не будет для всех сессийТеперь подумайте о последствиях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 12:55 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
TaPaKПереписать эту дичь на LEFT JOIN и убрать WITH (UPDLOCK, ROWLOCK, HOLDLOCK) Сортировать это костыль Интересный вариант. invm - хорошим будет тот способ, который не использует сортировки и хинты, т.к. они не являются обычной практикой. Костыль, как правильно подмечено. Т.е. другой разработчик ничего не зная о том, что при обращении к этой таблице требуется обязательная сортировка можно создать взаимоблокировки простым запросом. Для быстрого исправления, наверное, можно применить хинты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 13:00 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
invmTaPaKцелевая таблица TaskQueue , запрос на записей которых нет из TaskQueue - их не будет для всех сессийТеперь подумайте о последствиях. сдаюсь. До момента вставки первого их не будет ни для кого, что будет под (UPDLOCK, ROWLOCK, HOLDLOCK) ? всё? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 13:01 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовнедостатком этого решения является то, что вы будете вынуждены заставлять" дуть ветер " в одну сторону при обновлениях этой таблицы из других процедур другими запросами. Т.е. равновесие, образно говоря, такого запроса будет неустойчивым, хорошо работать в частном случае. В данной системе дедлоки на вставках относительно частые, а на обновлениях 1-2 раза в сутки. Связано с разными размерами пачек и разной частотой вызова разных ХП. Не ставлю целью на 100% избавиться от всех дедлоков. Все равно в случае ошибок идут повторные вызовы. Система в целом очень подвержена дедлокам, и часто приходится с ними разбираться, т.к. разработчики практически любое действие выполняют в 10 потоках на нескольких машинах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 13:09 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
TaPaKПереписать эту дичь на LEFT JOIN и убрать WITH (UPDLOCK, ROWLOCK, HOLDLOCK) Сортировать это костыль Можно и переписать, но подсказки убирать не надо. План запроса в итоге не изменяется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 13:18 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Eleanor, в моем случае наилучшим оказалось решение с раздельной подготовкой данных и выполнением обновления. Поэтому и предложил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 13:26 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
TaPaKinvmпропущено... Теперь подумайте о последствиях. сдаюсь. До момента вставки первого их не будет ни для кого, что будет под (UPDLOCK, ROWLOCK, HOLDLOCK) ? всё? под UPDLOCK + HOLDLOCK будут range локи, не дающие "завершить" exists по одним и тем же отсутствующим записям, т.е. вторая сессия будет ждать на range локи, пока первая не разберется, вставлять ли новую запись в справочник или нет. ЗЫ Range локи накладываются на предыдущую запись, что приводит к двум проблемам 1. При попытке вставить две разные отсутствующие записи в один пустой диапазон ключей (например, есть записи 1 и 5, а вставляются в разных коннектах 2 и 3), получим ожидание до конца 1-й транзакции 2. При попытке вставить две записи, одна из которых уже есть а другая стоит в пустом диапазоне справа от нее (например, есть запись 2 и 5 пытаемся вставить 2 и 3), получим ожидание до конца 1-й транзакции Если нет удалений, то со второй проблемой можно справиться "двухфазным" not exists Сначала без (UPDLOCK, ROWLOCK, HOLDLOCK) выбираем записи которых нет в отдельную # таблицу, а потом из # таблицы вставляем записи с повторной проверкой, но уже с (UPDLOCK, ROWLOCK, HOLDLOCK) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 13:29 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовinvm - хорошим будет тот способ, который не использует сортировки и хинты, т.к. они не являются обычной практикой.Хорошим будет способ, который обеспечивает наиболее эффективное решение, а не наиболее соответствующий догмам. И вы так и не ответили в чем профит перекладывания во временную таблицы в данном конкретном случае. TaPaKсдаюсь.При параллельной вставке updlock+holdlock гарантирует отсутствие дубликатов. Либо отсутствие ругани о нарушении уникальности, если есть уникальный индекс Либо отсутствие предупреждения, если есть уникальный индекс с IGNORE_DUP_KEY = ON msLexRange локи накладываются на предыдущую записьНа следующую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 13:58 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
invm msLexRange локи накладываются на предыдущую записьНа следующую. точно, все время путаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 14:03 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
invm, я же писал - в чем профит. Не нужна неочевидная стороннему разработчику сортировка в запросе и не требуется поддерживать сортировку в новых запросах. Кроме того, можно не перекладывать, а удалить лишнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 14:03 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
invmВладислав Колосовinvm - хорошим будет тот способ, который не использует сортировки и хинты, т.к. они не являются обычной практикой.Хорошим будет способ, который обеспечивает наиболее эффективное решение, а не наиболее соответствующий догмам. И вы так и не ответили в чем профит перекладывания во временную таблицы в данном конкретном случае. TaPaKсдаюсь.При параллельной вставке updlock+holdlock гарантирует отсутствие дубликатов. Либо отсутствие ругани о нарушении уникальности, если есть уникальный индекс Либо отсутствие предупреждения, если есть уникальный индекс с IGNORE_DUP_KEY = ON msLexRange локи накладываются на предыдущую записьНа следующую. почему не накладывать это на получатель? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 14:05 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовя же писал - в чем профит. Не нужна неочевидная стороннему разработчику сортировка в запросе и не требуется поддерживать сортировку в новых запросах. Кроме того, можно не перекладывать, а удалить лишнее. Слишком много слов, давайте вы на примере покажите как без not exists вы решаете следующую задачу есть таблица Код: sql 1. нужно реализовать процедуру Код: sql 1. принимающую на вход список id и добавляющую в dbo.dict, те что отсутствуют. процедура вызывается во много потоков, входящие id в разных потоках могут совпадать. для простоты (что бы не генерить дополнительных сущностей), список id будет # таблица Код: sql 1. создаваемая и заполняемая вне этой процедуры ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 14:12 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
TaPaKinvmпропущено... Хорошим будет способ, который обеспечивает наиболее эффективное решение, а не наиболее соответствующий догмам. И вы так и не ответили в чем профит перекладывания во временную таблицы в данном конкретном случае. пропущено... При параллельной вставке updlock+holdlock гарантирует отсутствие дубликатов. Либо отсутствие ругани о нарушении уникальности, если есть уникальный индекс Либо отсутствие предупреждения, если есть уникальный индекс с IGNORE_DUP_KEY = ON пропущено... На следующую. почему не накладывать это на получатель? потому что между exists (или left join) и insert проходит достаточно времени, чтобы другой поток вставил отсутствующие записи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 14:14 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLexTaPaKпропущено... почему не накладывать это на получатель? потому что между exists (или left join) и insert проходит достаточно времени, чтобы другой поток вставил отсутствующие записи т.е. две транзакции в serializable на получателе смогут вот в тот фокус про достаточно времени? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 14:37 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
TaPaKт.е. две транзакции в serializable на получателе смогут вот в тот фокус про достаточно времени? конечно, можете проверить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 14:41 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLexTaPaKт.е. две транзакции в serializable на получателе смогут вот в тот фокус про достаточно времени? конечно, можете проверить а разве не сразу получение всех блокировок, а потом выполнение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 14:50 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLexTaPaKт.е. две транзакции в serializable на получателе смогут вот в тот фокус про достаточно времени? конечно, можете проверить вот вам простой репро создаем таблицу справочник Код: sql 1. и в двух (уже достаточно) потоках запускаем конкурентную вставку с serializable на получателе Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. переносим хинты ниже и снова запускаем в двух сессиях Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 14:53 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
TaPaKа разве не сразу получение всех блокировок, а потом выполнение? нет, конечно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 14:59 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Если требуется исключить повторяющиеся - то почему бы не повесить уникальный констрейнт на таблицу ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:03 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Cristiano_Rivaldo, Ничего лочить не надо будет. И дублей гарантированно не будет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:04 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Cristiano_RivaldoЕсли требуется исключить повторяющиеся - то почему бы не повесить уникальный констрейнт на таблицу ? и откатывать всю транзакцию, при его нарушении? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:04 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLex, Нужно написать грамотный блок обработки ошибок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:05 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовя же писал - в чем профит. Не нужна неочевидная стороннему разработчику сортировка в запросеДля заботы о стронних разработчиках придумали комментарии. Владислав Колосовне требуется поддерживать сортировку в новых запросах.Зачем ее там поддерживать? Владислав КолосовКроме того, можно не перекладывать, а удалить лишнее.Задача - добавить из источника строки, отсутствующие в целевой таблице. Что тут лишнее, которое можно удалить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:06 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Cristiano_RivaldomsLex, Нужно написать грамотный блок обработки ошибок до блока ошибок, вставка в таблицу уже откатится если вставлять одну запись, вроде и не так жалко (хотя это уже двойная вставка в лог) а если за раз нужно вставить отсутствующие из 10000 входящих записей и вставка упадет из-за 1-й последней записи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:09 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLex, при многопоточности должны быть очереди в любом проявлении - блокировки страниц или блокировки уровня приложения. Позвольте мне воздержаться от написания примера, мозг и так взрывается :) Ищу решение для каскадного удаления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:13 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
invm, Зачем ее там поддерживать? Вот в этом и вопрос - разве одновременной выполнение другого запроса к этой же таблице не будет потенциальным источником взаимоблокировок? В нем ведь последовательность наложения блокировок не будет упорядоченной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:16 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLex, Да вы правы, спасибо. В последнее время на такое просто вешаем игнор и фиг с ним ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:16 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLex, Да - от ошибки нарушения уникальности никуда не денешься... Но есть практики,которые позволяют заинсертить большое количество данных в максимально короткое время. Чем быстрее завершится insert - тем меньше шансов на дубли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:16 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
invmЗадача - добавить из источника строки, отсутствующие в целевой таблице. Что тут лишнее, которое можно удалить? Поясню. Во временной таблице находится набор потенциально избыточных данных, это следует из запроса ниже, который фильтрует эти избыточные данные. Если избыточные данные удалить из временной таблице перед вставкой и исключить из запроса фильтр, то проблема взаимоблокировок не появится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:19 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовmsLex, при многопоточности должны быть очереди в любом проявлении - блокировки страниц или блокировки уровня приложения. т.е. блокировки уровня ключей вас не устраивают, а страницами пожалуйста Владислав КолосовПозвольте мне воздержаться от написания примера, мозг и так взрывается :) Я не в коем случае не заставляя вас, просто хотелось понять на примере простого кода о чем вы говорите. Мне до сих пор не понятно как вы решаете проблему многопоточной конкурентной вставки в уникальный ключ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:21 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Cristiano_RivaldomsLex, Да - от ошибки нарушения уникальности никуда не денешься... денешься. один из вариантов показан выше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:22 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
TaPaKmsLex, Да вы правы, спасибо. В последнее время на такое просто вешаем игнор и фиг с ним Если мы на такое повесили бы игнор, у нас бы ошибки уникальности падали бы раз в 5 минут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:25 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовinvmЗадача - добавить из источника строки, отсутствующие в целевой таблице. Что тут лишнее, которое можно удалить? Поясню. Во временной таблице находится набор потенциально избыточных данных, это следует из запроса ниже, который фильтрует эти избыточные данные. Если избыточные данные удалить из временной таблице перед вставкой и исключить из запроса фильтр, то проблема взаимоблокировок не появится. удаление избыточных данных не поможет в проблеме с уникальностью, отсутствующие в таблице данные по прежнему могут начать вставляться одновременно из двух параллельных потоков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:27 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLexTaPaKmsLex, Да вы правы, спасибо. В последнее время на такое просто вешаем игнор и фиг с ним Если мы на такое повесили бы игнор, у нас бы ошибки уникальности падали бы раз в 5 минут. ошибка? я про ignore dup key ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:28 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
TaPaKmsLexпропущено... Если мы на такое повесили бы игнор, у нас бы ошибки уникальности падали бы раз в 5 минут. ошибка? я про ignore dup key а, ясно. ну во-первых, он тоже вешает тот же holdlock во-вторых, работает медленнее (появляются какие-то дополнительные накладные расходы). плюс, как уже говорили, спамит варнингами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:33 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLexTaPaKпропущено... ошибка? я про ignore dup key а, ясно. ну во-первых, он тоже вешает тот же holdlock во-вторых, работает медленнее (появляются какие-то дополнительные накладные расходы). плюс, как уже говорили, спамит варнингами У меня получилось в разы быстрее при отказе от exists, особенно на больших объёмах на варнинги всё равно в общем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:35 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLex, Код: sql 1. Да, не подумал. конкуренции у меня нет на самом деле, т.к. включается sp_getapplock или выполнение по расписанию. Борьба происходила с deadlock, вызванными запросом внутри себя. Возможно у меня сортировкофобия, не знаю :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:35 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
TaPaKУ меня получилось в разы быстрее при отказе от exists, особенно на больших объёмах очень, очень странно физически он проделывает тоже самое, что и not exists может у вас not exists в скан сваливлся? у нас еще forceseek четвертым хинтом обязательно стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:37 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовmsLex, Код: sql 1. Да, не подумал. конкуренции у меня нет на самом деле, т.к. включается sp_getapplock или выполнение по расписанию. Борьба происходила с deadlock, вызванными запросом внутри себя. Возможно у меня сортировкофобия, не знаю :) если у вас допустима синхронизация на уровне sp_getapplock, то вам, конечно, не нужны все эти holdlock-и ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 15:40 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав КолосовПоясню. Во временной таблице находится набор потенциально избыточных данных, это следует из запроса ниже, который фильтрует эти избыточные данные. Если избыточные данные удалить из временной таблице перед вставкой и исключить из запроса фильтр, то проблема взаимоблокировок не появится.Чтобы избавиться от избыточных данных, нужно определить, что они избыточные. Для этого нужно проделать те же самые манипуляции с целевой таблицей, что и в стартовом посте. В результате получите те же дедлоки. Вы в своих решениях принципиально не хотите учитывать конкурентность выполнения запросов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 17:14 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
invm, я уже ответил, что дедлоки в моем случае были вызваны не конкурентностью между потоками, а конкурентностью внутри самого запроса. Поэтому, если ситуации с одновременным выполнением нет, то можно производить все действия, которые я описал. Для запросов вида update table1 where exists (select * from table1) можно получить дедлок единственным запросом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 18:52 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
msLexи откатывать всю транзакцию, при его нарушении? Вставляйте по строке за раз :) Для соблюдения уникальности в СУБД придуманы unique констрейнты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 18:58 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Ftt330msLexи откатывать всю транзакцию, при его нарушении? Вставляйте по строке за раз :) Для соблюдения уникальности в СУБД придуманы unique констрейнты.Ваш метод организации конкурентной вставки понятен, но далеко не у всех у базы один пользователь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 19:49 |
|
||
|
Принудительный ordered scan по временной таблице
|
|||
|---|---|---|---|
|
#18+
Владислав Колосовя уже ответил, что дедлоки в моем случае были вызваны не конкурентностью между потоками, а конкурентностью внутри самого запроса. Поэтому, если ситуации с одновременным выполнением нет, то можно производить все действия, которые я описал.Тогда непонятно зачем вообще предлагать решение заранее зная, что оно не подойдет? Что такое "конкурентностью внутри самого запроса"? Владислав КолосовДля запросов вида update table1 where exists (select * from table1) можно получить дедлок единственным запросом.Как это относится к запросу ТС? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2019, 19:57 |
|
||
|
|

start [/forum/topic.php?all=1&fid=46&tid=1687086]: |
0ms |
get settings: |
6ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
155ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
103ms |
get tp. blocked users: |
1ms |
| others: | 260ms |
| total: | 564ms |

| 0 / 0 |
