Планы обмена. Управляемый режим блокировок

Публикация № 561460 28.11.16

Разработка - Обмен данными 1С - Распределенная БД (УРИБ, УРБД)

план обмена обмен данными интеграция регистрация изменений

Статья о том, как устроен объект конфигурации 1С:Предприятие 8 "План обмена", в том числе на уровне СУБД SQL Server. Анализируются особенности его использования при управляемом режиме блокировок.

Механизм обмена данными платформы 1С:Предприятие 8 основан на объектах конфигурации, которые называются "план обмена". Этот механизм является основным и призван решать следующие задачи: регистрация изменений объектов и обеспечение обмена сообщениями между узлами распределённой информационной системы. Данная статья предполагает, что читатель уже знаком с основными понятиями и имеет опыт использования планов обмена.

Работа с РИБ в рамках данной статьи рассмотрена не будет, так как РИБ полностью основан на описанных в статье механизмах.

Структуры данных.

План обмена на уровне СУБД это таблица, которая имеет название вида "_Node[N]", где N - это внутренний числовой код типа данных 1С:Предприятие 8. В данном случае этот код будет соответствовать плану обмена.

Создадим тестовый план обмена. В конфигураторе 1С (изображение слева) и в SQL Server Management Studio (изображение справа) это будет выглять следующим образом:

Как мы видим по структуре таблицы справа, план обмена очень похож на справочник. Это тоже ссылочный тип данных. Однако, от справочников его отличает то, что он не может иметь групп и быть иерархическим.

Структура таблицы "_Node69" плана обмена "Тестовый"

  Наименование поля      Имя реквизита   Описание поля
 _IDRRef  Ссылка  Ссылка на узел плана обмена
 _Version  Версия записи таблицы СУБД
 _Marked  ПометкаУдаления  Пометка удаления
 _Code  Код  Код узла
 _Description  Наименование  Наименование узла
 _SentNo  НомерОтправленного    Номер отправленного сообщения
 _ReceivedNo  НомерПринятого  Номер принятого сообщения
 _PredefinedID  Идентификатор предопределённого элемента  

Следует отметить, что при создании плана обмена, платформа автоматически создаёт предопределённый узел, соответствующий текущей информационной базе, в которой он создаётся. Реквизиты "Код" и "Наименование" по умолчанию имеют пустые значения, их необходимо заполнить самостоятельно. Для того, чтобы убедиться в этом, выполним следующий код в SQL Server Management Studio:

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

Структура таблицы "_ReferenceChngR71" справочника "Номенклатура".

Наименование поля Имя Реквизита Описание поля
 _NodeTRef  Узел  Код типа плана обмена, например, у плана обмена "Тестовый" этот код равен значению "69".
 _NodeRRef  Узел  Ссылка на узел плана обмена
 _MessageNo  НомерСообщения   Номер сообщения, в котором данное изменение было выгружено для соответствующего узла плана обмена
 _IDRRef  Ссылка  Ссылка на элемент справочника "Номенклатура", который изменился

Таким образом, таблица регистрации изменений состоит из трёх обязательных полей и одного и более полей, которые необходимы для поиска изменившихся данных в основной таблице объекта. Для ссылочных типов данных таких, как справочники или документы, достаточно одного поля - "Ссылка". Однако для табличных типов данных, как, например, регистры сведений или регистры накопления, этих полей может быть несколько. Это зависит от установленного для измерений таких объектов свойства "Основной отбор". Более подробно об этом можно прочитать в книге "Профессиональная разработка в системе 1С:Предприятие 8. Издание 2." на странице 484.

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

Индексы таблиц регистрации изменений.

Для полноты картины приведу здесь информацию об индексах, которые создаёт платформа для таблиц регистрации изменений. Комментировать ничего не буду, так как, по моему и так всё понятно. Их всего два:

1. Ключ + Узел (кластерный).

2. Узел + Номер сообщения + Ключ.

Момент выполнения регистрации изменений.

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

1. Начало транзакции записи документа.

2. ПередЗаписью.

3. ПередЗаписью (подписка на событие).

4. ПриЗаписи.

5. ПриЗаписи (подписка на событие).

6. ОбработкаПроведения.

7. ОбработкаПроведения (подписка на событие).

8. Регистрация изменения объекта во всех планах обмена, в состав которых он входит, а также для всех узлов этих планов обмена.

9. Фиксация транзакции записи документа.

Почему важно понимать в какой момент происходит регистрация изменений? И почему я привёл в пример именно документ? Дело в том, что регистрация изменений выполняется в одной транзакции с записью и проведением документа. Это обеспечивает согласованность этих двух операций: проведения и регистрации. Следовательно, любая логика регистрации изменений влияет на продолжительность этой транзакции, а также на момент выполнения запроса на блокировку записей таблицы регистрации изменений. В высоко нагруженных системах такой запрос часто приводит к ожиданию на блокировках, которые ранее уже наложила, например, процедура выгрузки изменений. Далее в статье я расскажу об этом более подробно.

Регистрация изменений.

Для регистрации изменения выполним следующий код 1С:

Если мы воспользуемся SQL Server Profiler и посмотрим, что происходит при вызове процедуры "ЗарегистрироватьИзменения", то мы увидим следующий код (для удобства восприятия код немного "причёсан"):

Как мы видим, на 2-ом шаге транзакции 1С сразу же пытается наложить эксклюзивную блокировку на запись регистрации изменения элемента справочника "Номенклатура" по соответствующему узлу плана обмена. Кроме этого, предпринимается попытка установить своеобразный флаг, сигнализирующий о том, что это изменение необходимо выгрузить в новом/следующем сообщении обмена. Этим флагом является реквизит "НомерСообщения" (поле "_MessageNo"), значение которого устанавливается равным NULL.

Обратите внимание, что если мы изменим один и тот же объект несколько раз, то запись изменений для этого объекта будет только одна. Это ключевая особенность планов обмена! Фактически это делает такую запись дефицитным ресурсом, за захват которого конкурируют разные транзакции. Если быть более точным, то таким ресурсом является поле "_MessageNo" этой записи.

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

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

Кроме этого очень важно то, что изменение регистрируется для всех узлов плана обмена. То есть если бы в нашем плане обмена было 10 узлов, то изменение одного объекта потребовало бы создания 10 записей, 100 узлов - 100 записей и так далее. И это только для одного изменения. Этот факт тоже важно учитывать.

Просмотр изменений.

Теперь попробуем изменить что-нибудь в нашем справочнике "Номенклатура" и посмотрим как это отразится в таблице регистрации изменений. Для этого можно воспользоваться следующими запросами 1С или T-SQL:

Запрос = Новый Запрос();
Запрос.Текст = "ВЫБРАТЬ * ИЗ Справочник.Номенклатура.Изменения";
SELECT * FROM [_ReferenceChngR71]

Однако, мы ничего не увидим ... Дело в том, что регистрация изменений выполняется только в контексте узлов плана обмена. Это ещё одна ключевая особенность этого объекта конфигурации: все изменения регистрируются только в контексте какого-нибудь узла обмена. Поэтому добавляем новый узел в созданный ранее план обмена "Тестовый", и пытаемся изменить что-нибудь в справочнике "Номенклатура" снова. После этого проверяем таблицы изменений ещё раз и видим, что там появились записи.

Удаление регистрации изменений.

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

На этот раз 1С ограничивается одной командой SQL, пытаясь наложить всю ту же самую эксклюзивную блокировку по тому же самому ключу, что в общем-то ожидаемо и вполне нормально:

Запись изменений в сообщение обмена.

Для того, чтобы выгрузить изменения в другой узел распределённой информационной системы, необходимо эти изменения сначала прочитать, а затем записать в сообщение обмена. Механизм обмена сообщениями тесно интегрирован с планами обмена. В данном случае имеется в виду то, что запись сообщения обмена в файл сопровождается изменением реквизита "НомерСообщения" в таблице регистрации изменений объекта и ревизита "НомерОтправленного" в таблице плана обмена для соответствующего узла, для которого выполняется выгрузка данных. Чтобы реализовать всё это необходимо использовать объект "ЗаписьСообщенияОбмена". Именно этот объект позволяет нам управлять номером отправляемого сообщения: получать новый порядковый номер, записывать его в сообщение обмена, в таблицу регистрации изменений и реквизит узла плана обмена.

Чтобы исследовать код, который необходимо выполнить для записи сообщения обмена, я настроил технологический журнал 1С на регистрацию событий TLOCK, EXCP и TTIMEOUT. Эти события позволяют анализировать установление управляемых блокировок и ошибок, связанных с неудачными попытками установить их. Кроме этого я настроил SQL Server Profiler, чтобы посмотреть какие запросы платформа 1С генерирует на уровне СУБД.

Версия платформы 1С:Предприятие 8.3.7.2027. Управляемый режим блокировок.

// 0. Подготавливаем необходимые объекты.
ФайлСообщенияОбмена = "C:\export\message.xml";
ЗаписьXML = Новый ЗаписьXML();
ЗаписьXML.ОткрытьФайл(ФайлСообщенияОбмена);

УзелОбмена = ПланыОбмена.Тестовый.НайтиПоНаименованию("Тестовый узел", Истина);

// 1. Создаём объект "ЗаписьСообщенияОбмена".
ЗаписьСообщения = ПланыОбмена.СоздатьЗаписьСообщения();

// 2. Начинаем запись сообщения для выбранного узла в файл XML.
ЗаписьСообщения.НачатьЗапись(ЗаписьXML, УзелОбмена);

В книге "Профессиональная разработка в системе "1С:Предприятие 8" (издание 2) от 2012 года на странице 491 написано следующее:

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

Если посмотреть ТЖ 1С, то там мы не увидим установки блокировки. Значит управляемая блокировка не устанавливается. На уровне СУБД мы увидим обычный запрос, который характерен для вызова метода ссылки "ПолучитьОбъект":

SELECT
	T1._IDRRef,
	T1._Version,
	T1._Marked,
	T1._Code,
	T1._Description,
	T1._SentNo,
	T1._ReceivedNo,
	T1._PredefinedID
FROM
	dbo._Node69 T1 -- План обмена "Тестовый"
WHERE
	T1._IDRRef = 0x9BD9408D5C93CC8E11E6A9E8C5C37A96 -- Узел обмена "Тестовый узел"

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

Получается в данный момент мы пытаемся выгрузить сообщение, которое ранее уже выгружалось под номером 13. Повторная выгрузка. В данный момент первая сессия 1С остановлена в точке останова после выполнения метода "НачатьЗапись". Теперь откроем вторую сессию 1С и попробуем зарегистрировать изменение этого объекта ещё раз в тот момент как оно отправляется:

ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, СсылкаДляОбмена);

Теперь проверим, что изменилось:

Ошибок блокировки не было. Поле "_MessageNo" изменилось, сигнализируя нам, что его необходимо выгрузить. Так какая же блокировка имелась ввиду в книге? Неужели всё-таки ошибка? Ошибки никакой нет. Чтобы убедиться в этом выполним в сессии № 2 следующий код 1С:

Узел = ПланыОбмена.Тестовый.НайтиПоНаименованию("Тестовый узел", Истина);
Объект = Узел.ПолучитьОбъект();
Объект.Заблокировать();

В результате мы получим следующее сообщение об ошибке (эту же ошибку мы увидим в ТЖ, событие EXCP):

{ВнешняяОбработка.ИсследованиеПлановОбмена.МодульОбъекта(103)}: Ошибка при вызове метода контекста (Заблокировать): Не удалось заблокировать запись. Действие (изменение, удаление или блокировка записи) не выполнено.
Ошибка блокировки объекта. Объект уже заблокирован:
компьютер: Zhichkin, сеанс: 45, начат: 24.11.2016 в 1:00:46, приложение: Толстый клиент

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

// 3. Выбираем изменения для выгрузки
Выборка = ПланыОбмена.ВыбратьИзменения(УзелОбмена, ЗаписьСообщения.НомерСообщения);
BEGIN TRANSACTION

UPDATE
	[_ReferenceChngR71] -- Таблица регистрации изменений
SET
	[_MessageNo] = 26 -- Очередной номер отправленного сообщения
WHERE
	[_NodeTRef] = 0x00000045 -- План обмена "Тестовый"
	AND
	[_NodeRRef] = 0x9BD9408D5C93CC8E11E6A9E8C5C37A96 -- Узел "Тестовый узел"
	AND
	[_MessageNo] IS NULL -- Устанавливаем номер для ещё не отправленных сообщений

-- Выбираем все изменения, в том числе отправленные в других сообщениях
SELECT
	[_IDRRef]
FROM
	[_ReferenceChngR71]
WHERE
	[_NodeTRef] = 0x00000045
	AND
	[_NodeRRef] = 0x9BD9408D5C93CC8E11E6A9E8C5C37A96

COMMIT TRANSACTION

Этот код будет выполнен для всех типов объектов, которые включены в состав плана обмена. Каждый тип в своей собственной транзакции. На время транзакции будет установлена эксклюзивная транзакционная блокировка SQL Server на все записи узла, которые ещё не отправлялись. Это означает, что повторное изменение уже заблокированных объектов будет ожидать окончания этой транзакции, а, в случае превышения времени ожидания, будет сгенерировано сообщение об ошибке:

При этом если мы зарегистрируем по этому узлу и типу объекта новое изменение, то оно успешно запишется. Более того, если это произойдёт до команды SELECT, то в выборку изменений попадут и эти новые изменения. Что интересно номер отправленного у них будет равен NULL, хотя это совершенно не так.

Кроме этого если записей будет более 5000, то может произойти эскалация блокировок SQL Server. В таком случае может оказаться заблокированной вся таблица. Чтобы этого не происходило, администраторы баз данных часто отключают на уровне SQL возможность возникновения такой эскалации, однако это не запрещает эскалации до уровня страниц (имеют размер 8 Kb), что может приводить к избыточной блокировке записей не попадающих в условия отбора команды UPDATE, но находящихся на одной странице вместе с нужными записями.

Таким образом к негативным последствиям выполнения операции выборки изменений можно отнести следующие:

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

2. Избыточные блокировки при больших объёмах изменений из-за эскалации блокировок SQL Server. Усугубляет последствия первого пункта.

3. Рассогласованность нумерации сообщений для новых регистраций объектов, которые не попали в первоначальный UPDATE. Следствием этого может быть повторная выгрузка одних и тех же данных.

Все выбранные изменения обрабатываются в оперативной памяти. Это происходит в следующем цикле:

// 4. Обработка выбранных изменений
Пока Выборка.Следующий() Цикл
	Данные = Выборка.Получить();
	ЗаписатьXML(ЗаписьXML, Данные);
КонецЦикла;

На этом этапе на уровне SQLServer ничего интересного не происходит: выполнение метода Выборка.Получить() получает данные объекта по его ссылке так, как если бы мы вызвали метод Ссылка.ПолучитьОбъект() или Набор.Прочитать(). Единственным недостатком можно назвать то, что это выполняется в цикле для каждого объекта, что трудно назвать оптимальным решением. Каждый объект записывается в сообщение обмена в формате XML. Это самый длительный этап выгрузки данных. К сожалению его практически невозможно распараллелить, так как запись ведётся в один файл.

В случае успешной записи сообщения обмена, завершаем сеанс выгрузки данных:

// 5. Завершаем сеанс выгрузки данных
ЗаписьСообщения.ЗакончитьЗапись();
UPDATE
	[_Node69] -- План обмена "Тестовый"
SET
	[_Marked]       = 0x00,
	[_Code]         = N'1',
	[_Description]  = N'Тестовый узел',
	[_SentNo]       = 26, -- Номер только что отправленного сообщения обмена
	[_ReceivedNo]   = 0,
	[_PredefinedID] = 0x00000000000000000000000000000000
WHERE
	[_IDRRef] = 0x9BD9408D5C93CC8E11E6A9E8C5C37A96 -- Узел "Тестовый узел"
	AND
	[_Version] = 0x00000000000077E8

Завершение сеанса выгрузки заключается в том, что для соответствующего узла плана обмена записывается номер только что отправленного сообщения обмена и вызывается метод объекта "Записать". В результате этого на узел плана обмена устанавливается управляемая блокировка - в техническом журнале 1С фиксируется событие TLOCK. Это очень короткая транзакция.

Чтение изменений из сообщения обмена.

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

ЧтениеXML = Новый ЧтениеXML();
ЧтениеXML.ОткрытьФайл(ПолноеИмяФайла);
ЧтениеСообщения = ПланыОбмена.СоздатьЧтениеСообщения();
ЧтениеСообщения.НачатьЧтение(ЧтениеXML, ДопустимыйНомерСообщения.Больший);
Пока ВозможностьЧтенияXML(ЧтениеXML) Цикл
    Данные = ПрочитатьXML(ЧтениеXML);
    Данные.ОбменДанными.Отправитель = ЧтениеСообщения.Отправитель;
    Данные.ОбменДанными.Загрузка = Истина;
    Данные.Записать();
КонецЦикла;
//ПланыОбмена.УдалитьРегистрациюИзменений(ЧтениеСообщения.Отправитель, ЧтениеСообщения.НомерПринятого); 
ЧтениеСообщения.ЗакончитьЧтение();

Заключение.

Плюсы планов обмена:

    1. Простота программирования и настройки.

Минусы планов обмена:

    1. Избыточные блокировки данных.

    2. Конфликты блокировок транзакций.

    3. Регистрация одного изменения для каждого узла. На мой взгляд это избыточно, а кроме того интегрирует логику маршрутизации сообщений в подсистему регистрации изменений. Нарушается архитектурный принцип разделения ответственности между программными компонентами.

    4. Гранулярность обработки данных - узел обмена.

    5. Дублирование выгрузки данных.

    6. Плохие возможности для распараллеливания процессов.

    7. Тесная интеграция механизма регистрации изменений и инфраструктуры сообщений (их нумерация) диктует свои правила и ограничивает возможности реализации каких-то своих оптимизационных решений. См. также пункт 3.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Evil Beaver 7155 28.11.16 16:14 Сейчас в теме
Я, может быть, не прав, но по-моему, транзакция начинается еще до момента вызова ПередЗаписью. Т.е. в обработчике ПередЗаписью транзакция уже открыта.
2. zhichkin 1114 28.11.16 17:35 Сейчас в теме
(1) Вы абсолютно правы! Спасибо за замечание. Поправил.
3. headMade 143 28.11.16 17:42 Сейчас в теме
Посмотрите - вроде часть скринов пропала. Например там где "выполнив код SQL:".
4. zhichkin 1114 28.11.16 17:44 Сейчас в теме
(3) Да, есть такое дело. Честно говоря, устал бороться с этим явлением =(
5. spezc 719 29.11.16 12:52 Сейчас в теме
Так как в итоге то? Какое лекарство, когда например 100 узлов решили обменяться информацией с центром?
EMelihoff; +1 Ответить
7. zhichkin 1114 04.12.16 16:59 Сейчас в теме
(5) Прошу прощения, но Вы бы не могли уточнить, что конкретно имеется ввиду? Например, я понял вопрос так: есть 100 входящих сообщений обмена для центральной базы. Вероятно это РИБ. Если каждое сообщение имеет по 1 объекту, то я не вижу в этом вообще никакой проблемы ... Дайте, пожалуйста, цифры.
8. zhichkin 1114 04.12.16 20:43 Сейчас в теме
(5) Если отвечать на Ваш вопрос глобально, то, при условии, что были исчерпаны все варианты оптимизации планов обмена, нужно использовать альтернативные варианты. Например, можно использовать свою реализацию регистрации изменений. Это как минимум. Некоторые размышления по этому поводу я зафиксировал здесь. Есть и другие публикации по этому поводу. Ссылки на них можно найти в моём профиле.

В ближайшее время я планирую сделать ещё пару публикаций на тему того как можно оптимизировать работу планов обмена. Если проблемы серьёзные и требуется частная консультация, то я готов оказать посильную помощь. Пишите в личку.
11. sommid 11.01.17 18:07 Сейчас в теме
(8)
В ближайшее время я планирую сделать ещё пару публикаций на тему того как можно оптимизировать работу планов обмена

- если не сложно, то отпишитесь в комментариях этой темы. Интересно будет почитать. Спасибо.
6. tormozit 6406 29.11.16 14:57 Сейчас в теме
9. kolya_tlt 66 11.01.17 13:53 Сейчас в теме
Добрый день.
было бы здорово добавить в статью информацию по автоматическому режиму или отличий с управляемым
10. zhichkin 1114 11.01.17 15:07 Сейчас в теме
(9) Тут не так много мест где будут отличия. Пожалуй это все те места, где выполняется команда SELECT. Если Вы хорошо понимаете разницу между READ COMMITED (автоматический режим) и READ COMMITED SNAPSHOT (управляемый режим), то без труда поймёте где и какая разница возникает.

Если отвечать упрощённо, то разница между этими двумя режимами такова, что:
1. При чтении данных:
в первом случае мы получаем версию записи после её изменения в другой транзакции. При этом мы ждём её завершения (нас блокируют - мы ждём, чтобы прочитать). А в случае со snapshot, мы получаем версию записи, которая была до начала второй транзакции. При этом мы ничего не ждём и допускаем "грязное чтение".
2. В процессе чтения данных:
в первом случае мы блокируем транзакции, которые желают изменить данные, которые мы читаем (мы блокируем - нас ждут, чтобы изменить). А в случае со snapshot мы никого не блокируем.

Некоторые могут подумать, что в первом случае прочитанные нами данные блокируются до конца транзакции, но это не так. Уточняю: речь идёт о первом случае (автоматический режим блокировок), когда опция read_commited_snapshot на уровне базы данных имеет значение OFF (выключено).
Это зависит от режима изоляции транзакции. В случае с планами обмена используется режим изоляции транзакции SQL Server по умолчанию, а он чаще всего равен READ COMMITED, то есть данные блокируются только на время их чтения.
То есть одна запись блокируется пока она читается в выборку, затем блокировка снимается, делается попытка получить разрешение на чтение следующей записи, устанавливается блокировка чтения и читается следующая запись. И так до тех пор, пока все, попавшие в условие отбора, записи не будут прочитаны.
13. kolya_tlt 66 12.01.17 09:26 Сейчас в теме
(10)
А в случае со snapshot, мы получаем версию записи, которая была до начала второй транзакции. При этом мы ничего не ждём и допускаем "грязное чтение".

хм, где про снэпшот такую информацию пишут ? мне казалось COMMTITED исключает грязное чтение
14. zhichkin 1114 12.01.17 14:01 Сейчас в теме
(13) Очень много информации по этим вопросам можно найти в сети Интернет, например:
https://msdn.microsoft.com/ru-ru/library/tcbchxcb(v=vs.110).aspx
https://habrahabr.ru/post/305600/
15. zhichkin 1114 12.01.17 14:06 Сейчас в теме
(13) Коротко отвечу всё же:
READ COMMITTED - это уровень изоляции транзакций, как правило, используемый SQL Server.
read_committed_snapshot - это опция уровня базы данных, которая может изменять поведение уровня изоляции READ COMMITTED, принятое по умолчанию. По умолчанию read_committed_snapshot = OFF. Однако при включении управляемого режима блокировок 1С переключает это значение в положение ON. Это меняет поведение уровня изоляции транзакций READ COMMITTED принятое по умолчанию.
1cprogr_nsk; +1 Ответить
16. VVi3ard 50 06.09.17 09:55 Сейчас в теме
Интересная статья, для полноты не хватает описания того как работает платформа при использовании: ЗаписатьИзменения, и особенно в части работы параметра "ЭлементовВТранзакции".
17. EvgeniyEY 15.06.20 18:01 Сейчас в теме
Полезная статья, спасибо.
18. Sirruf 139 28.01.21 11:19 Сейчас в теме
А кто-нибудь задумывался почему ВыбратьИзменения() выполняется в транзакции? Что произойдет (сломается), если гипотетически убрать транзакцию?
19. zhichkin 1114 28.01.21 11:58 Сейчас в теме
(18) Можно легко предположить что будет. При управляемых блокировках SEL ECT будет выполняться как READ COMMITTED SNAPSHOT, так как BEGIN TRANSACTION вызывается без параметров, а следовательно с уровнем изоляции транзакции используемой SQL Server по умолчанию. По умолчанию это READ COMMITTED. Так как 1С включает на своих базах данных параметр read_committed_snapshot равным значению 1 (включено), то имеем в итоге READ COMMITTED SNAPSHOT.
SELECT is_read_committed_snapshot_on FR OM sys.databases WHERE name = '1c_database_name';

Таким образом если вынести UPDATE и SELECT в разные транзакции, то от этого ничего не изменится. Если выполнить UPDATE без явного объявления транзакции BEGIN TRANSACTION, то в любом случае эта команда будет выполняться в неявной транзакции с уровнем изоляции по умолчанию.
Короче говоря, таким образом можно уменьшить время выполнения транзакции и удержания эксклюзивных блокировок, установленных командой UPDATE, на время выполнения SELECT. В некоторых случаях это может облегчить жизнь, но не думаю, что это принципиально менят ситуацию с блокировками на таблицах изменений планов обмена.
20. Sirruf 139 28.01.21 13:41 Сейчас в теме
(19) То есть вы согласны с моим мнением, что транзакция в данном случае избыточна?
22. zhichkin 1114 28.01.21 14:21 Сейчас в теме
(20) Да, это очевидно: SELECT нужно убирать из транзакции.
24. Sirruf 139 28.01.21 18:08 Сейчас в теме
(22) Хорошо, попробуем на партнерском форуме написать об этом разработчикам :)
21. Sirruf 139 28.01.21 13:46 Сейчас в теме
Таким образом, для решения проблемы с блокировками нам нужно выбирать изменения порциями, то есть передавать в качестве третьего параметра в функцию ВыбратьИзменения() предварительно подготовленный массив объектов, размер которого не приведет к длительным блокировкам и эскалациям.
23. zhichkin 1114 28.01.21 14:26 Сейчас в теме
(21) Косвенно пишу об этом в своей статье "Анализ блокировок СУБД: таблица изменений плана обмена 1С", пункт 4 "Анализ технологического журнала 1С":
Разница заключается в использовании временной таблицы для передачи фильтра в виде массива ссылок в метод менеджера планов обмена "ВыбратьИзменения". Это говорит о том, что в каких-то случаях 1С считает, что массив достаточно большой, чтобы начать использовать временную таблицу. Экспериментальным путём удалось выяснить, что количество ссылок в массиве, начиная с которого создаётся временная таблица, равно 129. Создание временной таблицы означает нагрузку на tempdb и дисковую систему сервера СУБД. Это может влиять на продолжительность выполнения всего метода "ВыбратьИзменения" (транзакции СУБД), особенно учитывая тот факт, что в нём выполняются последовательно сначала UPDATE, а только затем SELECT.

Для решения проблем блокировок мой совет: не используйте механизм планов обмена =)
Оставьте свое сообщение

См. также

РИБ 200 узлов. Середина пути Промо

Распределенная БД (УРИБ, УРБД) v8 Розница Россия Бесплатно (free)

Между настройкой и поддержкой РИБ на 2 узла и на 10 большой разницы нет, а вот когда число удаленных точек переваливает за сотню, приходится решать уже совсем другие вопросы

25.10.2016    41232    comol    215    

РИБ. Падение сетевых папок при обмене обновлениями конфигурации

Распределенная БД (УРИБ, УРБД) v8 Розница Россия Бесплатно (free)

При обмене обновлениями в 1С: Розница РИБ 2.3 происходит сначала падение общих сетевых папок, а затем отваливаются диски с этими папками на сервере.

22.09.2021    338    platformit    2    

Распределенные алгоритмы РИБ 1С

Распределенная БД (УРИБ, УРБД) Математика и алгоритмы v8 Бесплатно (free)

Небольшое исследование на тему применимости классических распределённых алгоритмов репликации и синхронизации данных между узлами обмена РИБ 1С.

02.07.2021    1215    zhichkin    1    

Правила обмена больше не нужны

Внешние источники данных Обмен через XML Перенос данных из 1C8 в 1C8 Распределенная БД (УРИБ, УРБД) WEB v8 Бесплатно (free)

Есть несколько общепринятых подходов к написанию обмена между 1С-системами, каждый из которых упирается в длительное изучение технологии, мучительную отладку правил конвертации и написание большого количества сервисного кода, в котором потом тяжело разобраться. О принципах работы универсального фреймворка liteExchange, который реализует быстрые обмены между 1С и внешними системами, и берет на себя всю техническую обвязку по стандартному преобразованию данных, на INFOSTART MEETUP Saint Petersburg.Online рассказал Николай Крылов.

17.03.2021    11803    Nikola23    39    

Обмен по расписанию типовыми средствами. Промо

Распределенная БД (УРИБ, УРБД) Обмен через XML Перенос данных из 1C8 в 1C8 v8 1cv8.cf Россия Бесплатно (free)

Часто перед интеграторами стоит задача организовать автообмен (по расписанию или при наступлении какого-либо события) данными между различными конфигурациями. В этой статье я попробую изложить простую инструкцию, как это можно сделать средствами, заложенными в типовые конфигурации 1С (ЗУП, БП, УПП и т.д.). Для обмена используется подсистема "Обмен данными" из БСП

20.06.2012    105506    kser87    52    

R.I.P. РИБ

Обмен через XML Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

РИБ, спасибо и до свидания.

19.02.2021    8655    1c-intelligence    132    

Обнаружение и разрешение коллизий данных: альтернативная реализация типовой стратегии РИБ 1С

Практика программирования Распределенная БД (УРИБ, УРБД) v8 Бесплатно (free)

Отказ от использования механизма планов обмена в РИБ не означает отказа от необходимости решать проблему выявления и разрешения коллизий. Данная статья предлагает рассмотреть один из вариантов решения этой проблемы.

06.02.2021    1008    zhichkin    2    

Восстановление узла РИБ по магазинам на примере 1С:Розница 2.3.4

Распределенная БД (УРИБ, УРБД) v8 Розница Россия Бесплатно (free)

После очередного обновления узла РИБ столкнулся с ошибкой, РИБ перестал работать. Начитался много статей про восстановление РИБа, ни одна толково не помогла. Поэтому не мытьем, так катанием сам разобрался, как же быстро восстановить РИБ, чтобы он заработал.

15.06.2020    10893    maxon    10    

Особенности обмена данными с использованием "ручной" регистрации Промо

Распределенная БД (УРИБ, УРБД) Перенос данных из 1C8 в 1C8 v8 1cv8.cf Бесплатно (free)

Эта статья рассчитана на программистов, которые используют обмен данными с помощью метода "ВыбратьИзменения" и последующую их запись. Только для планов обменов, имеющих "ручную" регистрацию.

14.01.2013    36353    logarifm    6    

Восстановление данных 1С8 при помощи механизма РИБ

Распределенная БД (УРИБ, УРБД) Тестирование и исправление v8 Бесплатно (free)

Предлагаю сообществу способ восстановления утраченных данных из бэкапа используя механизм РИБ. Зачастую наличие бэкапа базы не позволяет просто взять и откатить состояние базы на утро или вечер предыдущего дня. Бывает так, что утерю важных данных заметили спустя 2 дня, и свежий бекап нам не поможет. Предлагаю относительно простой способ переноса определенных данных из резервной копии базы в рабочую. Не надо писать обработку по выгрузке, загрузке данных или по переносу через COM-соединение. Единственное условие: в базе должны работать обмены РИБ.

13.06.2020    1869    Vortigaunt    1    

Как мы РИБ на веб-сервисы переводили

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Россия Бесплатно (free)

Решение проблем обмена РИБ с 10+ баз с помощью веб-сервисов и базы обмена.

13.05.2020    5250    RSConsulting    22    

Установка расширений конфигурации, модифицирующих структуры данных, в фоновом задании запрещена

Распределенная БД (УРИБ, УРБД) v8 Бесплатно (free)

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

20.02.2020    4512    fristaller    4    

УНФ РИБ Промо

Распределенная БД (УРИБ, УРБД) Перенос данных из 1С7.7 в 1C8.X v8 УНФ Россия Бесплатно (free)

В типовой УНФ нет РИБа. Исправляем этот недостаток, используя УТ 11 и ИТС. Статья подойдет для настойки распределенки в любой конфе на базе БСП.

16.10.2012    40199    ptkrzy    23    

И снова "Конфигурация узла распределенной ИБ не соответствует ожидаемой"

Распределенная БД (УРИБ, УРБД) Обмен данными 1С v8 Бесплатно (free)

Конфигурация узла распределенной ИБ не соответствует ожидаемой. Приведен очередной способ устранения этой ошибки, возникший не в результате сбоев в работе оборудования или при обмене, а в результате обновления платформы 1С.

05.11.2019    7059    Kobra_RU    11    

Cannot insert duplicate key. Кто виноват и что делать

Распределенная БД (УРИБ, УРБД) Тестирование и исправление v8 Бесплатно (free)

Ошибка "CANNOT INSERT DUPLICATE KEY" в базах 1С и связанная с ней "магия".

25.02.2019    26984    YPermitin    32    

Как отвязать информационную базу от РИБа

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Россия Бесплатно (free)

Краткая инструкция для новичков о том, как в 2 клика отвязать информационную базу от РИБа.

03.05.2018    20197    user861285    12    

Автоматическое обновление конфигурации в узлах РИБ Промо

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

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

14.07.2012    54271    fixin    75    

Расширения конфигурации и РИБ, друзья или враги? Или как мы передаем расширения подчиненным РИБ узлам

Распределенная БД (УРИБ, УРБД) v8 Бесплатно (free)

Читая комментарии к курсу касательно новых возможностей расширений конфигурации, которые привнес релиз 8.3.11, на одном из известных сайтов с курсами, я обратил внимание, что коллегам приходится отказываться от расширений из-за решения перейти на РИБ. Мы сами относительно недавно начали переходить на РИБ, и мы также активно пользуемся расширениями и в этой статье я хотел бы рассказать, как мы решили эту проблему.

24.11.2017    20988    markers    14    

Magic Updater. Система администрирования распределенной сети 1С:РИБ

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

Обновления 1С стали для Вас адом? Каждодневная "война" за получение данных из всех торговых точек? Обмены то проходят, то не проходят? Разрушилась база, а резервной копии нет и не было? Если у Вас тоже регулярно возникают данные вопросы - найдите пару минут прочитать статью ниже.

15.08.2017    18487    comol    22    

Восстановление обмена в РИБ. Запущенный случай

Распределенная БД (УРИБ, УРБД) v8 Россия Бесплатно (free)

Удачная попытка восстановить обмен в РИБ при большом количестве объектов обмена и ошибках при обмене.

03.04.2017    15893    peterxx    14    

Что делать, если параметр запуска /resetmasternode приводит к вылету с дампом

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

Для тех, кто столкнулся с проблемой отключения узловой базы от главного узла через параметр запуска /ResetMasterNode.

01.04.2017    18967    therva    4    

Проблема с обновлением типовой конфигурации УТП 1.2 (Украина) в дочернем узле

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Украина Бесплатно (free)

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

15.02.2017    13188    bulpi    4    

Конфигурация узла распределенной ИБ не соответствует ожидаемой

Распределенная БД (УРИБ, УРБД) v8 Россия Бесплатно (free)

Есть куча материалов, где описано решение возникающей ошибки при обмене с РИБ, но ни одно не помогло. Пришлось включить мозг, и, о чудо, было найдено простое решение.

26.01.2017    27613    virtmon    35    

Планы обмена 1С: решение проблемы блокировок при помощи средств SQL Server

Практика программирования Математика и алгоритмы v8 Абонемент ($m)

Небольшое исследование возможности улучшить работу планов обмена 1С средствами SQL Server: view + triggers (представление + триггеры). В статье описывается один из приёмов SQL программирования для решения проблем блокировок, когда основные структуры данных изменить нельзя.

1 стартмани

10.01.2017    13383    zhichkin    4    

Highload обмен данными: постановка задачи

Производительность и оптимизация (HighLoad) Распределенная БД (УРИБ, УРБД) v8 Бесплатно (free)

Цели статьи: определить, что такое "highload обмен", описать типовой сценарий обмена, сформулировать основные требования к обменам такого типа и предложить методику оценки производительности (пропускной способности).

04.11.2016    14502    zhichkin    3    

Корректное отключение от главного узла РИБ и создание самостоятельной БД. Быстрое создание/восстановление узла РИБ без выгрузки начального образа для конфигураций на основе БСП

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

В публикации описан один из способов создания тестовой БД для разработки с актуальными данными, быстрого восстановления работоспособности РИБ при "падении" одного из узлов, или "быстрого" создания/восстановления узла РИБ без выгрузки начального образа для конфигураций на основе БСП.

16.02.2016    103707    asg.aleks    13    

Автоматическое обновление конфигурации в узлах РИБ

Распределенная БД (УРИБ, УРБД) v8 Бесплатно (free)

Вариант автоматического обновления конфигурации (без участия пользователей) периферийной базы РИБ. Очень простой способ без необходимости внесения кода в конфигурацию 1С. В дополнение к публикации http://infostart.ru/public/143517/. Спасибо автору, навел на эту идею!

22.01.2016    25432    Kitri    4    

Отладка конвертации данных 2.1 в конфигурациях, построенных на БСП 2.1 (БП 3.0, УТ 11 etc.)

Практика программирования Распределенная БД (УРИБ, УРБД) Обмен через XML БСП (Библиотека стандартных подсистем) v8 1cv8.cf Бесплатно (free)

Отладка процесса выгрузки/загрузки данных при проведении синхронизации в новых конфигурациях 1С может вызвать (у меня вызвала) некоторые затруднения. О них и пойдёт речь.

29.10.2015    43198    NittenRenegade    24    

Как я восстанавливал разрушенную базу

Архивирование (backup) Распределенная БД (УРИБ, УРБД) Тестирование и исправление v8 1cv8.cf Бесплатно (free)

УТ10.3 на Платформе 8.2 на базе MSSQL была разрушена после попытки её восстановить после неудачного динамического обновления. Таблица Config целевой базы была заменена на содержимое таблицы Config от другой рабочей базы. Но на самом деле конфигурации у них существенно отличались, поэтому после таких действий целевая база рухнула окончательно. Что же делать?

21.08.2015    30511    METAL    25    

"Распил" базы "БП 3.0 ПРОФ" с дальнейшим переносом в "БП 3.0 Базовая" ОДНОЙ организации

Распределенная БД (УРИБ, УРБД) v8 Россия Бесплатно (free)

Условия: Есть "БП 3.0 ПРОФ", в которой ведется учет по трем (неважно, скольким) Организациям. Необходимо оставить учет только по одной (к примеру) организации, и при этом перенести все данные по ней в "БП 3.0. Базовая"

14.08.2015    17637    Viktor_Ermakov    10    

РИБ Бухгалтерия 3.0.39, файловый вариант базы

Распределенная БД (УРИБ, УРБД) v8 БП2.0 Россия Бесплатно (free)

Настройка обмена данных РИБ в файловом варианте базы, через планировщик задач.

18.05.2015    12636    maikl007    2    

Автоматическое обновление конфигурации периферийного узла РИБ при обмене

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

При большом количестве периферийных узлов в РИБ достаточно проблематично производить обновление конфигурации. В данной статье опишу свой опыт решения данной проблемы.

24.03.2015    30021    kondrat1C    20    

Выделение одной организации из Бухгалтерии редакция 3 через РИБ

Распределенная БД (УРИБ, УРБД) v8 БП2.0 Россия Бесплатно (free)

Выделение одной организации из Бухгалтерии редакция 3 через РИБ (например, 3.0.36.16) может привести к большим проблемам с последующими обновлением.

16.02.2015    16413    shevelyov    4    

Обмен с помощью WMI

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

Полный контроль над процессом, осуществляемый из единого центра.

10.11.2014    10652    loekyn    7    

Обмены данными и РИБ с использованием облачных сервисов

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

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

22.10.2014    21600    rarename    14    

Реализация обмена по организации в УТ

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

В связи с открытием филиала в другом городе возникла необходимость организации учета в конфигурации "Управление торговлей для Казахстана, ред. 3" (адаптированный аналог "Управление торговлей, ред. 11"). Как оказалось встроенного обмена по организации не оказалось, есть только "Полный". Пришлось реализовывать самому. Конечно был вариант работы через терминальное подключение и тонкий клиент, но в связи во-первых неустойчивыми каналами связи и с заделкой на будущее (большие объемы данных) решил сделать РИБ. И вот об этом моя первая статья, может поможет кому нибудь.

05.06.2014    15792    Bajo    5    

РИБ для УНФ

Распределенная БД (УРИБ, УРБД) v8 УНФ Россия Бесплатно (free)

Штатного механизма типового полного обмена (РИБ) нет. Добавляем этот функционал. Данный способ подойдет для типового релиза УНФ начиная с версии 1.4.7.37 или для конфигураций на основе БСП.

10.01.2014    31770    ZhAmAn    28    

Интерактивный счетчик объектов обмена

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

При обменах на периферийных базах счетчик обмена сделан не очень красиво – он зависает на 10% и вся загрузка не отображается на счетчике. Предлагаю методику, чтобы визуализировать прогресс загрузки/выгрузки.

16.08.2013    17452    fixin    3    

Параллельность выгрузок

Распределенная БД (УРИБ, УРБД) v8 1cv8.cf Бесплатно (free)

Рассказываю свой опыт, как добился параллельности выгрузки из центральной базы РИБ сразу в 70 узлов.

15.08.2013    25365    fixin    41    

Из главного узла не загружены изменения справочника "Идентификаторы объектов метаданных"

Распределенная БД (УРИБ, УРБД) Администрирование данных 1С v8 1cv8.cf Бесплатно (free)

Данная проблема появляется регулярно на Периферийной Базе, после проведения обновления релиза ЦБ. Всем кому данная проблема неожиданно обновила вкус жизни, посвящается. Пошаговая инструкция, 100 % гарантия, никакого программирования.

09.05.2013    42170    motorkuzbassa.it    40    

МиниКейс "Закрытие месяца в УПП без остановки работы системы (Партионный учёт)"

Распределенная БД (УРИБ, УРБД) Закрытие периода Закрытие периода v8 1cv8.cf БУ Бесплатно (free)

Предлагается схема закрытия месяца на предприятии с круглосуточной работой в 1С. Используются обработки, которые доступны на infostart.ru.

24.02.2013    24616    axxell    7    

Настройка филиальных баз данных

Распределенная БД (УРИБ, УРБД) Перенос данных из 1C8 в 1C8 v8 БП2.0 ЗУП2.5 УТ10 Россия Бесплатно (free)

Клиент поставил задачу реализации работы филиалов в конфигурациях "Бухгалтерия предприятия" и "Зарплата и Управление Персоналом", в которых уже давно работает центральное отделение. Главная загвоздка в том, что, несмотря на автономную работу филиалов, отчетность нужно было продолжать сдавать от юридического лица в центральном филиале. Начали продумывать варианты реализации...

29.01.2013    18152    evgant    6    

Обмен данными в распределенной базе через e-mail.

Распределенная БД (УРИБ, УРБД) WEB v8 1cv8.cf Бесплатно (free)

Если у вас нет финансов для покупки отдельного сервера под 1С или вы просто не хотите пока вкладывать денежные средства для развития этого программного продукта, но у вас есть острая необходимость в обмене данными между двумя удаленно расположенными пользователями, то в данной статье я расскажу как настроить обмен данными без финансовых вложений по средствам e-mail.

13.01.2013    50321    Klim Bassenger    34