В двух сеансах выполняется удаление операций: отдельно чистятся регистры с отбором по регистратору, отдельно проставляется пометка на удаление и выполняется импорт.
Операции грузятся в 2х сессиях за разный период.
В операциях может быть больше 1000 строк. При этом возникают блокировки. Как устранить проблему с блокировками.

(12) больше одной записи значит и больше 5  тыщ возможно да? Рукалицо

(11) когда запрос пытается применить к одному объекту (к таблице или индексу) более 5000 блокировок на уровне записи или страницы. Значение 5000 блокировок взято из документации, но на практике SQL Server иногда продолжает использовать блокировки уровня записи или страниц и при количестве в сотни тысяч таких блокировок. При этом SQL Server никогда не производит эскалацию с уровня записи до уровня страницы, а сразу пытается наложить блокировку на таблицу;

https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms184286(v=sql.105)

(13) А что нет?

(0) ну как-бы при удалении (пометке) штатными средствами помимо объекта и его ТЧ еще есть планы обмена, последовательности, журналы, критерии поиска.... обычно сабж возникает не из-за эсколации а из-за дедлоков на общих таблицах (обычно это последовательности)

с чего Вы решили, что у Вас блокировки именно из-за эскалации блокировок? для начала посмотрите статистику ожидания блокировок.....

(14) ссылка криво вставилась движком форума. Закрывающую скобку тоже надо в адресной строке поставить

(13) ТТы злой такой? У тебя проблемы в жизни?

(15) +

https://wiki.mista.ru/doku.php?id=it:analiz_sql_block

(15) Я буквально 2 недели назад столкнулся с похожей проблемой:
Много доков с ТЧ около 1000 записей.
И зараза постоянные эскалации на РБ Хозрасчетный. Именно эскалации. Не планы обмена, не последовательности, не ожидания.

(19) ну хозрасчетный то-же слабое место из-за второй таблицы с субконто, но автор написал, что движения он чистит отдельно по регистратору...

(18) Просто параллельно проводишь в 3 потока приходные накладные, и пошла красота.
С расходными такой беды нет.

(20) Эскалация на основной таблице, не на с субконто.

(21) просто приход надо тоже расходными делать, вид операции приход добавить, и проблем не будет

Записей в операциях может быть у меня и 1000, и 5000, максимум 500000.
Уровень изоляции на продуктивном сервере read comitted, на тестовом snapshot read comitted.Ошибка наблюдается на обоих.

(20) в одной сессии может записываться операция на 100000 и больше, в другой сессии чистится движения операции и возникает ошибка таймаута.

При выполнении удаления движений по регистратору ставятся какие либо блокировки? И чему равно количество блокировок, количеству удаляемых строк?

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

нет, не читаю: в одной сессии создаю набор записей по регистратору и записываю, в другой записываю пустые наборы по другим регистраторам

Отключить итоги у регистра может помочь

Текст ошибки то какой?

(30) Судя по (25) таймаут на упр.

(0) 2 подхода:
либо ты делишь документы так, чтобы в двух сессиях не пересекались измерения (для РБ + счет) в удаляемых движениях
либо (27) или его другой вариант отключение текущих итогов, период рассчитанных итогов меньше на месяц, чем периоды изменяемых движений (Смотря на какой таблице была эскалация может и не помочь, но откуда ты взял что у тебя эскалация? доказательства, что она происходит есть?)

(30) Конфликт блокировок при выполнении транзакции: превышено максимальное время ожидания предоставления блокировки

(32) у меня движения по регистру накопления

(32) пока нет.
Не получается настроить ТЖ. Не работает фильтрация на базу и каталоги создаются с непонятными числами: не соответсьвуют ни pid процессов , ни номерам соединений

При включении ТЖ получаются такие каталоги:
1cv8c_5900
1cv8c_11796
1cv8s_18316
mmc_3308
1cv8s_13096
1cv8_17588
и т.д.
Что означают числа?

Везде пишут что должны быть такие катлоги:
ragent_###, rmngr_####, rphost_###

М-да..

Так ты на клиенте включит ТЖ

*включил

А ты там кем?

(5) не хами!

(36) рп?

(39) при некоторых настройках события пишутся, но не TLOCK

(43) что рп?

(40) если три кластера серверов то с кем будет работать?

Сколько кластеров не имеет значения, ведь инфобаза всегда зарегистрирована должна быть только в одном кластере. А если у тебя это не так, то ты ССЗБ. А если ты кластерами называешь рабочие серверы кластера, то вдвойне :)

(46) кластер 1с ВСЕГДА имеет ОДИН мастер сервер, именно он разруливает 1с-шные блокировки на весь кластер (на все сервера кластера и все процессы их),

все-же я пока не услышал, ни одного подтверждения, что у тебя именно проблема эскалации
попробуй все-же (18)

(25) 100000 записей в ОДНОЙ транзакции? учти, что эта транзакция идет совсем не быстро (26) при записи пустого набора в регистр ставится блокировка по отбору, то есть если для регистров с регистратором получить лишнюю блокировку тяжело, там отбор только по регистратору, а вот с независимыми регистрами вполне реально получить блокировку на весь регистр целиком.
В дополнение тут уже говорили про пересчет итогов, при больших транзакциях однозначно итоги нужно отключать и потом их пересчитывать отдельно

(47) настроил на сервере под пользователем 1С. Теперь пишет в ТЖ.

События tlock нет в журнале

В ТЖ попадаются такие строки:
38:06.577005-161148005,CONN,1,process=rphost,p:processName=bd,OSThread=2412,ClientID=293,Txt=Outgoing connection closed

Содержание файл настройки:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">;
    <log location="C:\Users\USR1CV8\AppData\Local\Temp\log_tj_823aefe5-8375-4dfa-ad58-7542f1189c7c" history="1">
        <event>
            <ne property="name" value=""/>
            <eq property="p:processName" value="bd"/>
        </event>
        <property name="all"/>
    </log>
</config>

(48) запрос в (18) что должно вернуть, какую то таблицу?

(53) коды причин ожидания блокировок,

там сразу будет видно это дедлок или что-то еще

(54) я моделирую ситуацию на тестовой базе: запускаю в 2х сессиях обработку. В какой момент нужно выполнять этот запрос? я не знаю когда возникнут блокировки.

(55) когда запускаешь, только в твоем случае параметры подкрути, а то 300 минут это для тебя долго...

поставь минут 20, например так

EXEC track_waitstats 20, 1

и сразу после запуска запускай свои обработки на нескольких сеасах

(56) Завтра попробую, спасибо

(56) в этом скрипте нельзя поставить фильтр на базу?

(58) я не знаю, скрипт использует штатный сбор статистики а есть-ли там возможность фильтрануть по базе - читать надо, я никогда не заморачивался

Занятно, у ТС конфликт на управляемых блокировках, но ему упорно продают идею анализировать ожидания на СУБД, а также то, что это может быть дэдлок на СУБД :)

(60) что вы предлагаете анализировать?

(60) получить конфликт на управляемых блокировках в автоматическом режиме может быть 2х типов

1. ожидание освобождения при очень длительной транзакции (напоминаем типовой таймаут 10 минут), на объемах автора транзакции должна быть 1..2 минуты.
2. дедлок, да на управляемых его получить очень сложно, но учитывая все-же довольно длительную транзакцию 1...2 мин, я предполагаю, что блокировка возникает в авто режиме на небольшое время с момента записи и до фиксации транзакции, то есть это наверно секунд 15 при фиксированым порядком таблиц для блокировки, но вот если в авто режим мы влезаем грязными ручками и явным образом меняем порядок блокировки таблиц для разных типов документов - то тут и будет дедлок...

(61) события TLOCK и TTIMEOUT в технологическом журнале

(62) откуда инфа, что у автора автоматический режим управления блокировками?

в автоматическом режиме конфликта на управляемых блокировках не может быть

Если случился конфликт на управляемых блокировках, то до блокировок на уровне СУБД дело не дошло, их не нужно анализировать от слова "совсем"

+(64) и еще момент, дэдлок или нет - понятно по тексту ошибки, у автора явный конфликт блокировок (не дэдлок)

у меня моделируется ситуация следующая:
1. Записывается операция по оборотному регистру накопления объемом примерно 500000 строк в одной сессии
2. В другой сессии улаляются движения и формируются операции примерно по 10-20 тыс строк в опер.
Т.к. регистр накопления оборотный то отключать итоги не имеет смысла.
Пока не рассматриваем вариант уменьшение строк в операциях.
Может быть конечно я неправильно записываю операции: 1. Записваю доеумент 2. Создаю набор 3. Ставлю отбор на регистратор 4. Заполняю 5. Записываю. Возможно при создании набора нужно ставить управляемую блокировку в транзакции на организацию и период?

(63) нет этих событий в ТЖ

(48)в кластере 8.3 может быть более 1 центрального сервера.

(66) операция №1 у вас выполняет установку блокировки на 500000 строк таблицы оборотного РН и по столько-же строк на каждый из регистров и на всякие доп. таблицы (итоги оборотов за каждый месяц и т.п.). Вполне резонно что на большом наборе записей сервер СУБД решает что экономичнее и быстрее повысить гранулярность блокировки до таблицы.
Как писали флаг 1224 отключит эскалацию по числу записей, а 1211 по числу записей+памяти, но 1211 может криво отрабатывать.

>Возможно при создании набора нужно ставить управляемую блокировку в транзакции на организацию и период?
управляемые блокировки ставить нужно!!! примеры: http://catalog.mista.ru/public/144750/

>Пока не рассматриваем вариант уменьшение строк в операциях.
не зная все подробности нельзя точно сказать правильно ли вы делаете. Как вариант делать допроведение документов ночью. Не подходит?

(62) ну и бред

(67) есть, просто у тебя криво ТЖ настроен

(69) да нет там блокировок на СУБД, см (33)

(69) не нашел по ссылке способа как поставить блокировку на Период (месяц) это вообще возможно?

(71) как настроить: не ставить фильтр на базу?

(73) для чего тебе блокировка? Ты читаешь остатки перед формированием движений и контролируешь их?

"делать допроведение документов ночью"
сложилас ситуация , что обработку впервые запусттли в 2 сессии, вообще всегда в одну сессию грузили. Поэтому такого больше не будет.

(74) да, попробуй не ставить фильтр на базу

вот кусок рабочих настроек для разбора проблем с упр. блокировками:
<log location="E:\LOGS\TLOCK" history="8">
               <event>
                               <eq property="Name" value="TLOCK"/>
               </event>
               <event>
                               <eq property="Name" value="TTIMEOUT"/>
               </event>
               <event>
                               <eq property="Name" value="TDEADLOCK"/>
               </event>
           <property name="all"/>
</log>

(75) нет не читаю. Блокировка для того чтобы гранулярность была меньше чем сейчас, чтобы 1я сессия могла создать движения в оборотном регистре по своей оргагизации +периоду, а во второй сессии по своей паре и они не мешали друг другу.

+(75) вдумайся немного, у тебя конфликт блокировок и решать эту проблему ты пытаешься с помощью наложения дополнительных блокировок. Кажется это немного бессмысленно :)

ну так из за чего конфликт, у меня пишутся разные наборы по разным организациям, значит программа сама неоптимально ставит блокировки

если я явно не указываю упр. блокировки, значит блокировки наложит какие то другие субд и 1с?

(78) тебе это ничем не поможет.

если я правильно понял, то ты пишешь в один регистр слишком много (500к) записей в одной транзакции, из-за этого возникает эскалация на упр. блокировках (блокируется весь регистр, так работает платформа), что не дает другим транзакциям писать в этот регистр до завершения твоей огромной транзакции.

Поэтому выход для тебя - разделить запись в регистр на порции, не превышающие 100к (если у тебя 8.3, для 8.2 и того меньше) записей для того, чтобы не возникала эскалация.

При этом нужно будет как-то контролировать целостность записи всего огромного набора записей, но это кажется решаемо

(81) ты запор пытаешься лечить закрепляющими средствами, а это плохой путь :)

если ты явно не накладываешь блокировки, то СУБД и платформа сами наложат необходимые им блокировки (независимо от тебя, как бы ты ни старался)

Ну уровне субд я уже отключил эскалацию ылагами трассировки. Кроме этого уровень изоляции snaoshot вообще вряд ли приводит к блокировкам в субд. По крайней мере обработка по просмотру блокировок в sql на этой базе их вообще не покаЗывает.
Осталось увидеть блокировки 1с в ТЖ.

(83) я не собираюсь ничего лечить, просто хочу видеть блокировки в ТЖ как подтверждение того что это из-за записи большого количества строк в регистр накопления по регистратору

Интересно, будет ли разница если записывать операции по-другому минуя набор записей:
1. Получать объект
2. Записывать движения
3. записывать объект

Давно бы запустил хотя бы обработку Бурмистрова по отображению блокировок, либо через какие-нибудь ИР настроил и собрал ТЖ.
А этот ручной онанизм с настройкой ТЖ и разглядыванием текстовых файликов в каталогах разве что на экзамене у Морозова пригодится )

(79) " решать эту проблему ты пытаешься с помощью наложения дополнительных блокировок" - это имеет смысл при борьбе с дедлоками. Тогда разные транзакции культурно будут ждать друг друга в очереди.

(86) Покажи какие именно упр.блокировки накладываешь и перечисли отдельно все измерения регистров, которые записываешь.

(87) именно ее и запускал, в тестовой базе вообще ничего не показывает

(89) сейчас никакие упр. блокировки не накладываю

(91) это ты так думаешь.
Это за тебя щедро платформа делает.
Смотри пространства имен события Tlock

(92) посмотрю когда получу tlock  в тж

(90) "в тестовой базе вообще ничего не показывает" // Не настроил значит как надо, не читал требований

в рабочей показывает в тестлвлй нет: не считая списка пользователей.
Уровни изоляций в базах разные

(90) очевидно же, что она показывает блокировки на СУБД, а у тебя таймаут на управляемых :)

(96) она показывает и блокировки 1с по данным ТЖ, там есть отдельный флаг

вообще тот файл настроек тж который я редактировал и создала на сервере обработка Бурмистрова

(96) Не, та показывает и упр.

(98) включи руками полный ТЖ, проверь, что есть нужные события

(100) В рабочем кластере есть и рабочие и тестовые базы, полный журнал включать нет возможности

Ты там фикси что ли?

(91) Поэтому и будут вылезать дедлоки.

(91) На всякий случай тогда спрошу - "автоматическое удаление движений" не стоит в документах?

(102) да, саообучаюсь

(104) документ операция, какое удаление движений

(100) ну проверил по рабочим базам пишутся события TLOCK. Но нет ни одной папки с PID процессов балансирующего сервера. Должны ли они складывать в этот же каталог главного сервера кластера или нужно настраивать на обоих серверах?

короче надоело разбираться, всем спасибо)

(103) они и так будут вылезать, упр. блокировку все равно не поставить на период

(85)если есть твердая уверенность что это не эскалация блокировок СУБД, то собирай события TLOCK

(102) это не недостаток.

(111) ?