|   |   | 
| 
 | Взаимосвязь управляемых блокировок 1С и эскалации блокировок СУБД | ☑ | ||
|---|---|---|---|---|
| 0
    
        yabes 27.04.20✎ 13:46 | 
        Подскажите, пожалуйста, нигде не смог найти ответа на свой вопрос. Может ли установка управляемых блокировок 1с повлиять на эскалацию блокировок СУБД? У меня при записи большого набора записей возникает эскалация блокировок СУБД. Существует мнение, что если установить по измерениям управляемую блокировку 1С, это поможет убрать эскалацию блокировок СУБД. У меня избавиться от эскалации таким образом не получилось и статью, в которой бы говорилось о такой взаимосвязи я тоже не нашел. Так можно ли избавится от эскалации блокировок СУБД с помощью управляемых блокировок 1С или нет?)     | |||
| 1
    
        fisher 27.04.20✎ 13:51 | 
        Можно. Или нельзя. Зависит от причины эскалации.
 Прямой взаимосвязи нет никакой. | |||
| 2
    
        fisher 27.04.20✎ 13:55 | 
        Вообще, если запись одним набором, то непонятно как помогут управляемые блокировки. СУБД видит тонны блокировок строк и вполне естественно делает эскалацию, чтобы оптимизировать блокировки. А нет вариантов более гранулярно писать?     | |||
| 3
    
        fisher 27.04.20✎ 13:59 | 
        Возможно, исходное мнение имело в виду, что при параллельной записи можно делать грануляцию по измерениям и использование управляемых блокировок при этом уменьшит количество блокировок СУБД в конфликтных ситуациях.     | |||
| 4
    
        fisher 27.04.20✎ 14:00 | 
        Потому что конфликт будет разрулен еще на уровне управляемых блокировок, не доводя его до СУБД.     | |||
| 5
    
        fisher 27.04.20✎ 14:02 | 
        Но если алгоритм параллелизации исключает конфликты, то что в лоб, что по лбу.     | |||
| 6
    
        H A D G E H O G s 27.04.20✎ 14:24 | ||||
| 7
    
        palsergeich 27.04.20✎ 14:30 | 
        (0) Нет это не так работает.     | |||
| 8
    
        palsergeich 27.04.20✎ 14:33 | 
        Грубо из коробки у MSSQL триггер эскаляции 5000, у управляемой блокировки 100000
 Если ты пишешь разом более 5000 записей то или юзай ключи трассировки или воспринимай это как неизбежное | |||
| 9
    
        palsergeich 27.04.20✎ 14:33 | ||||
| 10
    
        H A D G E H O G s 27.04.20✎ 14:40 | 
        (8) Откуда дровишки про 100000 строк от сервера 1С?     | |||
| 11
    
        H A D G E H O G s 27.04.20✎ 14:41 | 
        От сервера 1С есть еще охеренные неявные блокировки при записи НабораЗаписей РС в режиме перезаписи. Но там думать надо, не копать.     | |||
| 12
    
        yabes 27.04.20✎ 16:00 | 
        Т.е. получается, что если требуется провести документ, который записывает в регистр большой набор записей (> 10 000 строк), то нет никакой возможности избежать эскалации блокировок СУБД, кроме как отключить эскалацию MS SQL для таблицы? В нашем случае мы мучаемся с сохранением документов “Форма ввода бюджета”     | |||
| 13
    
        H A D G E H O G s 27.04.20✎ 16:22 | 
        (12) Включите флаг 1211 и перезагрузите сервак. Ну написано же.     | |||
| 14
    
        yabes 27.04.20✎ 16:27 | 
        (13) Так я и спрашиваю в сообщении (12), если другая возможность избавиться от эскалации блокировок СУБД, кроме как отключить эскалацию MS SQL для конкретной таблицы или всего сервера (с помощью флага трассировки 1211)?     | |||
| 15
    
        Вафель 27.04.20✎ 16:28 | 
        ну можно еще мин размер увеличить     | |||
| 16
    
        fisher 27.04.20✎ 16:31 | 
        (12) И что они блокируют? Или вы их параллельно проводите?     | |||
| 17
    
        H A D G E H O G s 27.04.20✎ 16:38 | 
        (14) Можно для таблицы SQL через Alter Table
 поставить LOCK_ESCALATION =disable Но зачем? | |||
| 18
    
        yabes 27.04.20✎ 16:39 | 
        (16) Возникает эскалация блокировок СУБД по регистру накопления, в котором хранятся данные по бюджету. В такие моменты другие документы, которые делают движение по этому регистру периодически вылетают с ошибками превышения ожидания на блокировках     | |||
| 19
    
        yabes 27.04.20✎ 16:40 | 
        (17) "Но зачем?" - вы имеете в виду зачем устанавливать на таблицу если можно установить на весь сервер или зачем вообще это нужно?     | |||
| 20
    
        fisher 27.04.20✎ 16:53 | 
        (18) Пытаюсь сообразить, какие еще документы могут двигать бюджет.     | |||
| 21
    
        H A D G E H O G s 27.04.20✎ 16:55 | 
        (19) Да, если можно установить на весь сервер.
 По опыту - никакого особого повышенного потребления памяти или CPU это не вызывает | |||
| 22
    
        yabes 27.04.20✎ 16:58 | 
        (20) Хотя бы другие Формы ввода бюджета, например     | |||
| 23
    
        fisher 27.04.20✎ 17:13 | 
        (22) Вот я и спрашивал - вы их параллельно проводите? Тогда ясно. Неясно только почему такая огромная детализация, если существует еще и дополнительная гранулярность (раз параллельно проводить надо).
 Если это какие-то распределения, то их можно попробовать делать отложенно. Таблицы не любят, когда в них пытаются параллельно писать громадными порциями :) Когда это реально надо - там специально заморачиваются. Секционирование таблиц делают или еще чего похлеще. | 
| Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |