Управляемые блокировки и план обмена #655893

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

нет

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

что именно?

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

что блокировки

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

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

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

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

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

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

о_О

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

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

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

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

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

обязательно

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

тогда почему ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ясно спс

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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