Прошу помощи знатоков. Абсолютный профан в вопросе блокировок. История такая: при проведении заказов покупаля выполняются запросы опять же к заказам покупателя для некоторых проверок. И вот когда все начинают активно колотить эти заказы получается конфликт блокировок - база встает на выполении этих запросов. Режим управления блокировкой данных у заказов покупателя у нас управляемый, но кроме того что переключили свойство больше по сути ничего не сделано. Подскажите, как происходит блокировка таблиц в случае если режим блокировки - управляемый, но в коде блокировка данных не описана?

(0) Никак. Не факт что у вас управляемые блокировки. В свойствах конфигурации должна стоять режим Автоматический-Управляемый.

(1) Так и стоит

Первым первым первым делом смотрим на текст сообщения.
Если текст сообщения - содержит англицкие буковски и exception всякий с примесью SQL - у вас превышения на ожиданиях блокировок СУБД. Управляемые блокировки еще даже не сработали.

Если же сообщение - отечественное, то - это уже блокировки сервера 1С, наши, родные.

интересует: при записи блокируется вся таблица заказов или конкретная запись? при чтении запросом как блокируется таблица заказов?

(3) Иностранщина)

(3) поможет ли при этом описание блокировок в конфигурации?

(5) Попадайте в индекс, че.

Попробуйте блокировки вручную прописать с реквизитами шапок этих заказов.

(6) нет.

(7) не понял)

(9) Почему нет?
Режим управляемый, блокировки не описаны, СУБД и не может их корректно разрулить... Разве нет?

Хотя, о чем я.

Соседняя транзакция установила X блокировку по записи ЗаказПокупателя №01.

Текущая транзакция пытается поставить S блокировку по записи ЗаказПокупателя №01. И целует веник.

Переходите на 8.3, там это реализовано.

(12) А чем же так отличается в этом вопросе 8.3 от 8.2?

Кстати сейчас у нас 1С:Предприятие 8.2 (8.2.19.106)

(13) 8.3 не ставит S блокировку СУБД при чтении в транзакции.

(15) Это если грубо говорить.

Если научно точно - она переводить базу ms sql в режим Read_Commited_Snapshot. Только "режим сомвестимость" нужен выше 8.2.

(16) а описание блокировки таблицы заказов перед записью как предлагают (11) не поможет в этом случае?

(16) У меня почему то ощущение что блокируется целиком таблица заказов, т.к. я сомневаюсь что по одному и тому же контрагенту одновременно проводят заказы

(18) СУБД не знает, что вы только по одному контрагенту хотите...

(18) Может и "вся таблица", вернее все "дерево кластерного индекса", если вы своим запросом в индекс не попали и был clustered index scan.

(18) А может быть и только запись ЗаказПокупателя №1, который проводится в соседней транзакции (на соседнем ПК).

(19) а при чтении данных запросом с отбором по контрагенту блокируется таблица?

(22) Если там нет ДЛЯ ИЗМЕНЕНИЯ, то не должно блокироваться.

(23) Рекомендую подробнее изучить материалы.

(24) расскажи пожалуйста как это все происходит! чет нигде не могу найти почитать

Та он сам не знает, похоже )
Я бы блокировки прописал вручную.

(26) Расскажи, что делает ПРИ ИЗМЕНЕНИИ

(27) Что такое ПРИ ИЗМЕНЕНИИ?

Столько всяхой хрени наговорили, словесный понос просто. А настоящее сообщение об ошибке ТС так и не показал.

(28) Для Изменения , пардон.

(30) http://its.1c.ru/db/metod8dev/content/2651/hdoc

(29) там куча английских букв Microsoft SQL Server. Точнее к сожалению сейчас взять негде. Повторится это только завтра к вечеру...

(29) хотелось бы понять общую логику работы программы и далее уже решать как исправлять

(29) Че на него смотреть

http://4.bp.blogspot.com/-tu5UsWVDq7g/UPpO-bA8XFI/AAAAAAAABEA/pVY49LZCHEQ/s1600/Ошибка+SQL.png


хотя, может, маловероятно, но взаимоблокировки.

(31) Блаблабла. Своими словами. Там всего 4 слова.

прям по пунктам, к примеру:
1. началось проведение
2. выполение запроса на чтение - таблица заказов заблокирована (целиком или только то что выбираем?)
3. началась запись - таблица заблокирована (целиком?) Ну как то так

(34) что то типо такого

(36)
1. началось.
2. либо целиком, либо то, что выбираем.
3. только та запись, которая записывается. Именно для таблицы ДОКУМЕНТА заказ.

(38) а что определяет во втором пункте - целиком или то что выбираем?

Одной какой-то галочки, чтобы включить и заработало, нет. Тут анализ и оптимизаяйца нужны. Главная задача оптимизации:
1. Сократить время транзакций
2. Убрать лишние запросы и лишние поля из выборки

(39) Попали вы в индекс или нет. Если не попали - выполняется чтение всего индекса - его ПОПЫТКА S блокировки, но она не получится, так как часть индекса блокирована пишущей транзакцией.

(33) Логика работы прописана в ТВОЕМ КОДЕ. Нам ее откуда знать?

Для начала нужно понять какая именно ошибка и локализовать в коде запрос, который ее вызывает.

(40) к этому мнению я сам пришел))) думал вот только может поможет чудо обьект блокировка данных))

(42) запрос локализовал пока его удалением, но надо возвращать...

(44) покажи хоть запрос то

Напряженное ожидание расшифровки "Для Изменения" продолжается.

(46) Так в (31) все разжевано.

Режим удаления движений какой стоит?

Обращайтесь к регистрам, а не документам

Кстати в (0) ТС писал, что поставили упр. режим только у документа. Как насчет регистров?
Так может быть все таки у вас авт. режим блокировки?
Текст запроса в студию.

(47) нет. Там полная неясность.

(50) У ТС блокировки СУБД.

Всё плохо. 1Снеги по прежднему плавают в блокировках :-)

В (50) ерунду написал, система ошибку должна выдать.

(47) Не знаю, мне все понятно. Но если в 4 слова, то оно транслируется в HOLDLOCK.

(55) -> (51)

Тогда это управляемый режим. Read Commited. S блокировка на время запроса. X до конца транзакции.

(55) Нет. Repeatable Read устанавливает S блокировку до конца транзакции по дефолту.

Для Изменения устанавливает X блокировку вместо S. Только и всего.

Автор написал бы какое точно сообщение выдает и запрос. А то сферический конь в вакууме.

(58) для изменения устанавливает U блокировку.

(58) Да, прошу прощения, не HOLDLOCK, а XLOCK.

(60) Точно не скажу. Автоматические - уже история. Главное, что несовместную.

(62) ты сдал спеца то? а то я чтото пропустил

Подправьте, если что:
Управляемый режим.
Режим - Автоматическое удаление движений.
Перепроводим документ.
0. Начинается транзакция
1. Накладывается неявная упр. эксклюзивная блокировка на движения данного документа и на остатки по измерениям, используемые в движениях. Х блокировка на уровне СУБД на те же объекты.
2. Запрос к таблице заказов (что тут имеется ввиду? Таблица табл. части документа, к регистру заказов?). S блокировка на СУБД на время запроса. Блокируется или все таблица, или по ключу + запись сверху и снизу. Надо смотреть план запроса.
3. Запись движений. Тоже, что и в 1 по новым движениям.
4. Фиксация транзакции.
5. Снятие всех блокировок.

Режим - Удалять автоматически при отмене проведения
То же, но без пункта 1.

(64) все верно.

Скорее всего автор имеет ввиду запрос к шапке документа.

(50) У регистров по которым проводится заказ тоже естественно стоит управляемый режим блокировки

(59) Что выдает запрос пока скопировать не могу - ошибка воспроизводится только при большой нагрузке. Сегодня вечером буду ловить

текст запроса:
ВЫБРАТЬ
    МаршрутыАгентов.Контрагент
ПОМЕСТИТЬ ВТКонтрагентыПоМаршруту
ИЗ
    РегистрСведений.МаршрутыАгентов КАК МаршрутыАгентов
ГДЕ
    МаршрутыАгентов.ДеньНедели = ДЕНЬНЕДЕЛИ(&Дата)
    И МаршрутыАгентов.Агент.Подразделение = &Подразделение
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВТКонтрагентыПоМаршруту.Контрагент
ИЗ
    ВТКонтрагентыПоМаршруту КАК ВТКонтрагентыПоМаршруту
ГДЕ
    ВТКонтрагентыПоМаршруту.Контрагент = &Контрагент
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    КОЛИЧЕСТВО(РАЗЛИЧНЫЕ ЗаказПокупателя.Контрагент) КАК КолВоНеПомаршруту
ИЗ
    Документ.ЗаказПокупателя КАК ЗаказПокупателя
ГДЕ
    НАЧАЛОПЕРИОДА(ЗаказПокупателя.Дата, ДЕНЬ) = &Дата
    И ЗаказПокупателя.Проведен
    И НЕ ЗаказПокупателя.Ссылка = &Ссылка
    И НЕ ЗаказПокупателя.Контрагент В
                (ВЫБРАТЬ
                    ВТКонтрагентыПоМаршруту.Контрагент
                ИЗ
                    ВТКонтрагентыПоМаршруту КАК ВТКонтрагентыПоМаршруту)
    И ЗаказПокупателя.Подразделение = &Подразделение
    И НЕ ЗаказПокупателя.Контрагент = &Контрагент

(65) Кстати только сейчас подумал - запросы к табличной части не вызывают подобной блокировки

Что насчет режима удаления движений в документе? Чем позже начинаешь блокировать данные, тем лучше.

Похоже при обращении к осн. таблице документа заказы ты блокируешь ее всю. План запроса в профайлере умеешь делать?

Лучше сделать отдельный регистр сведений, подчиненный регистратору, и в нем сохранять контрагента при проведении. Запрос переписать.

В регистре сведений поставить индексацию по полям поиска запроса: подразделение, контрагент, дата.
Конструкцию не в (выбрать...) переписать на левое соединение и условие есть NULL.

(72) левое соединение лучше чем не в?

(73) оптимизатор SQL не знает сколько вернется значений и не может использовать индекс. В результат сканирование и перебор всей таблицы. На самом деле и  с "не" та же история.

(74) спасибо за совет, попробую с соединением

Регистр сведений нужен. Иначе, что мертвому припарка.

Как насчет (70)?

(77) удалять автоматически - но движений там всего 2 регистра

(78) значит они весят заблокированными с начала проведения и никто не может к ним обратиться, пока документ не будет проведен. Лучше переделать на "Удалять автоматически при отмене проведения". Очистку движений делать как можно позже.

Имеет смысл прикрутить анализ ожиданий на блокировках  гилева, благо он бесплатный. http://www.gilev.ru/setuplatch/. Правда ему нужен режим совместимости выше 8.2.13. Ну или ЦУП :). Там четко видно кто блокирует, что блокирует и сколько по времени блокирует.