Есть центральная база и куча переферийных баз, настроен обмен между ними через план обмена. Обмен осуществляется в ручную. При выгрузке данных все пользователи испытывают трудности в работе (конфликты блокировок).
Хочу попробовать прикрутить управляемые блокировки к обмену. Возможно ли такое?
Если да, то раскажите куда копать?

нет

вообще странно

(2) что именно?

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

(3) что блокировки

(4)+ типа
Центр  - 5 перифериек - 5 * 5 перифериек (по 5 к каждой периферийке 1го уровня)

(5) что странного? косяк обменов 1с в том, что блокируются таблицы изменений, полностью, а не по записям

(7) только на 1 момент "прочитать изменения"

и на второй - когда меняется номер сообщения

оба этих действия почти мгновенны

(10) прочитать изменения мгновенны? чо?) если зарегистрировано 400 тыщ объектов - он и читает минуты 2-3

(11) о_О

ну не 2-3 конечно, но чувствуется

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

+ (13) Тем более чем больше база тем больше времени

(15) эээ.... а ответы загружаешь, чтобы с регистрации снималось?

(16) это стандартный механизм жеж

(16) обязательно

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

(18) тогда почему (15)?

Разве остались еще конфы не на управляемом режиме? План обмена полный, или идёт фильтр при выгрузке?

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

(22) Рассматриваем случай выгрузки

(21) блокировки таблиц изменений живут своей жизнью, влиять на них ты не можешь своими управляемыми режимами

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

например на УПП, где много таблиц впринципе - даже ПрочитатьИзменения - не мгновенно, достаточно ощутимо

(26)->(19), выбирай по метаданым

(27) мы про типовой Полный обменн, не? там всё сделано просто, что ведёт к траблам блокировок

(21) с фильтром, он в процедуре ПриОтправкеДанныхПодчиненному

(29) хреновый фильтр кстати

(29) Действенный способ - переписать фильтр на регистрацию изменений.

(31) при записи документов?

(32) да, на подписках обычно делают, снимая авторегистрацию

(33) получается, спимаю авто регистрацию и при записи регистрирую в нужном плане обмена?

(33) объясни, что это даст.

(35) ну например 1000 документов, а отправить нужно 5 из них. Ты отправляешь всю тысячу, она у тебя нереально где-то лопатится и лопатится, потом наступает только событие ПриОтправкеПодчиненному и ты выясняешь, что нужно отправлять не 1000, а только 5. А он сразу на первом этапе регистрирует 5 документов. Выигрыш у него в 200 раз.

(36) ясно спс

(36) вопрос: 1000 документов по 20 в каждую переферийку, он же всё равно лопатит всю 1000, даже если регистрацию переписать?

На мой взгляд выход только один
Основная база -> Копия базы для обмена (через полный обмен) -> Переферийки
где полный обмен делается автоматически через каждые 15-30 минут

(38) смотри, если ты зарегистрируешь 1000 доков в 10 узлов - на каждый документ будет 10 записей в таблицах изменений.
а если документ надо всего в 5 узлов - записей будет 5. Не будет лишних записей

(40) я понял, но на переферийки уходят только документы "Перемещение товаров", а эти документы только для них и делаются, за исключением 2-3 документов в месяц из  примерно 5000 которые делаются между складами в центре.

+(41) поэтому прирост скорости минимален и не существенен.

(42) ну это зависит конечно от того, много ли на самом деле деления данных по узлам, если основнаяя масса данных ходит по всем узлам - то да, прироста мало.

Вот интересно у 1С есть в планах реализация управляемых блокировок на таблицу регистраций.

(44) Регистрация изменений работает в управляемом режиме, т.е. на уровне изоляции read committed. Просто ты через менеджер блокировок не может туда наставить блокировку, т.к. это просто не нужно (на таблицу субконто в регистре бухгалтерии ты отдельно тоже блокировку ставить не можешь, и что?)

ТС, попробуй отделить мух от котлет :) Вариант для "подумать": в сети центрального узла создать ещё один подчиненный узел... Зачем спросите вы? Для пользователей центрального узла.

И блокировки таблиц при выгрузке как бы тоже не происходит, кстати.

(45) чот я не догоняю смысла заявления. Блокируется целиком таблица, а не записи, в этом случае пофиг какой режим

(45) было бы удобней просто

(47) происходит, даже на чтение. зачем - я хз

(0) прикрутить можно, но объем работ будет большой.
для начала как вариант отключить текущие итоги у всех регистров и включить разделение итогов.

(47) Выполняется запрос update на таблицы регистрации по условию "где не стоит номер сообщения выгрузки, надо его поставить". Так как у нас изменение данных, происходит блокировка этих строк или страниц на чтение. Таблицы блокируются по обычным правилам - согласно настройкам эскалации (когда тратится много памяти на блокировки строк). Можно избежать ожидания на блокировке, если проставить для ms sql read_comitted_snapshot, или использовать версионники: postgres, oracle

(50) ЗаписатьИзменения - блокирует всё намертво, там в транзакции идёт запись, пока она активна - блокировка даже на чтение таблиц изменений

(53) да не, она блокирует все таблицы изменений на определенный период и все.

(53) Неправда, там идёт апдейт по условию.
(54) Какой нафик период?

(55) на период замены null на число в таблицах изменений в колонке номер сообщения.

(52)(55) в общем случае там нигде не стоит номер сообщения. Это сильное допущение, что он там есть, отсюда по факту блокировка всей таблицы. При нормально настроеных обменах - откуда там проставленные номера возьмутся?
По условию - это методом выбрать изменения, когда проставляется номер сообщения.
А ЗаписатьИзменения - в СП посмотри, там накладываются дополнительные блокировки в т.ч. и на данные, чтобы избежать их изменения в процессе выгрузки.
РИБ 1с застрахован создателями от неоднозначных ситуаций, способом в их духе - блокируем всё, чтоб вдруг ничо не случилось

(57) ЗаписатьИзменения там специально есть второй параметр количество в транзакции, чтобы не зависала вся база на этот период

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

(57) Блин, пассаж про номер сообщения - он для того, чтобы ты понял, что таблица не блокируется, блокируются записи. Ключевая разница - мы можем новые объекты добавлять, которые не выгружаются, без конфликта блокировок. На данные никаких блокировок уж тем более не накладывается - read committed всегда в любом случае обеспечит блокировки на любые изменения данных. Никакого там "блокируем всё, лишь бы ниче не случилось" нет.

(59) Происходит блокировка конкретных записей.

(61) пусть так, не буду спорить, надо лезть вглубь.
>>Происходит блокировка конкретных записей
а не кажется ли тебе что эти конкретные и есть ВСЕ? смысл блокировать часть? выгружается/загружается/выбирается Всё, последовательно, не кусками

(62) В справочнике номенклатура 15000 позиций, в очередном сообщении мы выгружаем 100 позиций, которые присутствуют в таблице регистрации без номера выгруженного сообщения,все они блокируются в таблице изменений, остальные 14900 доступны для работы. Поэтому нет, мне не кажется, что это и есть все.

(63) на блокировку не номенклатуры, а таблицы изменений смотри, в момент проставления номеров/выгрузки ты не сможешь всё равно эти 14900 других записать, в момент загрузки - тоже. Или сможешь?

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

(59) типовой РИБ достается почти всегда бесплатно, чтобы сделать хороший РИБ и при его работе не было таких проблем, которые туту описаны, нужно самостоятельно делать реализацию обмена по РИБ. Делать нужно через два плана обмена. В первом плане обмена идет регистрация изменений конфигурации и все, во втором плане идет регистрация изменений объектов. Все, теперь ты может работать с упр блокировками при выгрузке, с блокировками объектов в транзакции, но уже как тебе надо, а не через топорный счетчик. Блокировать таблицы изменений так как тебе надо и на сколько надо. Но! Все это нужно написать, а большинство здесь только языком может мести.

(64) Никакой блокировки номенклатуры нет, есть блокировка записей в таблице регистрации изменений. Все эти 14900 можно записать в момент выгрузки-загрузки.
(65) Ты просто не понимаешь, что такое управляемый режим. Повторю еще раз - обмен данными и работа с таблицей регистрации идёт на read committed.

(66) Замес с двумя планами обмена вообще не понял - причем тут это. Блокировка записей таблицы регистрации изменений идёт только при их изменении, а не при чтении, т.е. в соответствии с тем, как работает управляемый режим блокировок и со всеми остальными объектами.

(68) рано еще такие вещи понимать

(69) Аргументацию понял, бессильно сливаюсь.

(70) все правильно понял, разжевывать никто тебе не собирается.

(67) Чего не понятного я написал? Перевод в управляемый поможет, так как снизится уровень изоляции до твоего так часто упоминаемого read commited. Что дает что? При проведении нового документа снятия блокировки в таблице изменения после выполнения запроса, соответственно так как запрос там простой по условию где номер пакета=null, запрос выполнился быстро, блокировка снялась, пользователь провел документ без таймаута.

(72) А, ты на тему перевода всей конфигурации? Ну автор не написал, что за конфа у него, типовые то на управляемом режиме все в принципе. Я просто думал ты задвигаешь мифы про неуправляемую работу плана обмена в управляемом режиме.

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