Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Помогите разобраться с причиной блокировки
|
|||
|---|---|---|---|
|
#18+
Всем привет. Практически безостановочно циклом загружается следующая таблица. Структура таблицы: Код: sql 1. 2. 3. 4. 5. 6. 7. Индексы: Код: sql 1. 2. 3. 4. 5. 6. 7. На протяжении X лет, данная таблица заполнялась следующим скриптом, который работает практически не останавливаясь: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Проблема была в том, что каждый шаг выполнялся очень долго (порядка 15-20 минут) и в последствии цикл был изменен на следующий: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Вот тут скорость замечательно выросла и вместо 15 минут один шаг стал выполняться около минуты. Параллельно этому циклу через сервис брокер заполняются порядка 40 таблиц на основе данных из таблицы DATA_LOG. Все таблички заполняются по одному принципу: Логика заполнения у всех одинаковая: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. итд 40 таблиц И проблема в том, что после изменения скрипта цикла который заполняет таблицу DATA_LOG , регулярно запросы по заполнению таблиц а1-а40 стали отваливаться из за дедлока. В вопросе блокировок я прям не силен и сколько не читал не могу осилить. Поэтому прошу помочь. Интуитивно кажется, что дело именно именно в цикле, потому что есть еще 3 процесса под копирку как этот, там цикл не был переписан и дедлока никогда не возникает и не возникало. Как можно переписать или добавить какие то хинты чтобы заполнение таблицы DATA_LOG не вызывало дедлоков у процедуры запускаемой через сервис брокер? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2019, 19:50 |
|
||
|
Помогите разобраться с причиной блокировки
|
|||
|---|---|---|---|
|
#18+
assmsk, хинты (nolock) добавить можно на DATA_LOG, вопрос в том, устроит ли тебя "грязное чтение" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2019, 21:11 |
|
||
|
Помогите разобраться с причиной блокировки
|
|||
|---|---|---|---|
|
#18+
defragmentator, имеется ввиду nolock в запросы которые выполняет сервисе брокер? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Проблем с грязным чтением возникнуть не должно, тк в таблице (select id from only_id where id > @Max and id <= @MAX + 500 ) лежат id которые уже закомичены в таблице DATA_LOG. Но в целом конечно непонятно как так получается, для меня как человека непросвещенного в блокировках кажется, что это если в какую то таблицу идет долгая вставка а я просто из нее селекчу, то когда вставка закончится я должен получить свой запрос в любом случае, а не дедлок( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2019, 21:28 |
|
||
|
Помогите разобраться с причиной блокировки
|
|||
|---|---|---|---|
|
#18+
assmskимеется ввиду nolock в запросы которые выполняет сервисе брокер? Ну да, сервис брокер их просто не увидит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2019, 21:35 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39884485&tid=1687021]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
81ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 255ms |
| total: | 417ms |

| 0 / 0 |
