Планы обмена. Скрестить ужа с ежом ... миссия выполнима =)

Опубликовал Дмитрий Жичкин (zhichkin) в раздел Программирование - Практика программирования

Небольшое исследование возможности улучшить работу планов обмена 1С средствами SQL Server: view and triggers. Результаты имеют больше теоретическое, чем практическое значение. Однако тем, кто ищет нестандартные решения, статья может понравиться =)

Я поставил цель: улучшить работу планов обмена таким образом, чтобы внешне работа с ними со стороны 1С ничем не отличалась бы, но поведение механизмов платформы было бы другим. В частности, я хотел решить пресловутую проблему блокировок, которой страдают планы обмена. Достигнуть этих целей мне удалось. В результате получился тюнинг-пакет для планов обмена ... в лучших традициях hard КОРа (костыль-ориентированной разработки) =) =) =)

Изучив то, каким образом работают планы обмена на уровне SQL Server, мне пришла в голову очень простая идея: а что если "подсунуть" 1С вместо таблицы регистрации изменений, например, _ReferenceChngR71, представление SQL Server (view). При этом поведение механизмов планов обмена 1С изменить при помощи INSTEAD OF триггеров этого VIEW ...

Общая схема такой идеи выглядит следующим образом:

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

Идею решения этой проблемы я решил заимствовать у технологии SQL Server Change Tracking. О применении этой технологии совместно с платформой 1С я писал в своей статье "Использование SQL Server Change Tracking для регистрации изменений данных объектов 1С:Предприятие 8". В ней можно найти ссылки на дополнительные материалы.

Идея заключается в том, что каждое изменение объекта данных рассматривается как изменение версии этого объекта. Регистрируется каждое такое изменение при помощи команды INSERT. Эта команда, в отличие от UPDATE, которую использует 1С, не создаёт никаких блокировок. Всё очень просто. Графически эта идея может выглядеть следующим образом:

Мы имеем вектор изменений объекта данных V. На рисунке показано 10 версий таких изменений. Каждое новое значение версии генерируется при помощи таблицы SEQUENCE (см. рисунок выше).

Каждой версии соответствует запись в таблице регистрации изменений. На рисунке выше она называется CHANGES. Эта таблица по факту дублирует функционал таблицы регистрации изменений _ReferenceChngR71 плана обмена 1С, добавляя к ней поле [version]. Теперь каждому объекту соответствует несколько записей по количеству актуальных на текущий момент времени версий. Таким образом мы решаем проблему блокировок, которая возникает при долгом UPDATE'е когда вызывается метод "ВыбратьИзменения" планов обмена. При помощи триггеров мы эту команду просто игнорируем =)

Когда объект находился в состоянии версии 4 мы выполнили оправку данных. Это событие наша КОР система региструет в таблице SESSIONS (см. рисунок выше). Эта таблица устанавливает соответствие между нашими версиями и значениями номеров сообщений, которые генерирует план обмена. Теперь все версии до 4 включительно нам не интересны, если мы используем гарантированную доставку. Специальное регламентное задание может спокойно удалить их из таблицы CHANGES при этом абсолютно никому не мешая. Опять же решаем проблему блокировок при долгих DELETE'ах.

Теперь немного о механизме отправки сообщений. На рисунке мы начали отправку сообщения обмена методом "ВыбратьИзменения" плана обмена когда объект имел версию 8. В этот же самый момент времени пользователи успели изменить объект два раза и его текущая версия стала равна 10. Замечу, что при этом никаких блокировок не возникает: каждый занят своим делом и никто не мешает друг другу. После отправки изменений и фиксации тразакции в таблице SESSIONS версия 8 перейдёт в остояние "Отправлено", как до этого было с версией 4.

Вот вкратце и всё. Для тех, кто любит всё "потрогать руками" самостоятельно, детали реализации и примеры кода 1С и T-SQL находятся во вложенном к публикации архиву. Вопросы приветствуются. Постараюсь удовлетворить любое ваше любопытство по мере моих скромных сил =)

Скачать файлы

Наименование Файл Версия Размер
ТюнингПлановОбмена.epf
.zip 24,81Kb
09.01.17
2
.zip 24,81Kb 2 Скачать

См. также

Комментарии
1. Jem j (jem) 84 10.01.17 18:45 Сейчас в теме
К уже имеющимся зарегистрированным объектам плана обмена тяжело примостить чтобы попробовать.
Если правильно понимаю, происходит удаление таблиц, а потом создание новых в SQL.
При следующем обновлении конфигурации 1С, таблицы перезапишутся.
Я больше не о самом механизме, а о его практическом применении. Хотел на тестовой базе проверить.
2. Дмитрий Жичкин (zhichkin) 201 10.01.17 23:56 Сейчас в теме
(1) На самом деле нет никаких проблем.

Оригинальная таблица регистрации изменений 1С выглядит так:

CRE ATE   TABLE [_ReferenceChngR71]
(
	[_NodeTRef]  binary(4) NOT NULL,
	[_NodeRRef]  binary(16) NOT NULL,
	[_IDRRef]    binary(16) NOT NULL,
	[_MessageNo] numeric(10,0) NULL
)
...Показать Скрыть

Я её просто переименовываю, а вместо неё создаю вьюху на основании следующей ниже таблицы (все скрипты есть в скачиваемом архиве):

CRE ATE   TABLE [_ReferenceChngR71_Changes]
(
	[version] bigint NOT NULL,
	[_NodeTRef]  binary(4) NOT NULL,
	[_NodeRRef]  binary(16) NOT NULL,
	[_IDRRef] binary(16) NOT NULL,
	[_MessageNo] numeric(10,0) NULL
)
...Показать Скрыть

Как видите отличаются они только одним полем [version]. То есть данные из основной таблицы 1С можно просто скопировать в новую таблицу, по дороге заполнив поле [version]. Это сделать не сложно. Обратное превращение кареты в тыкву так же возможно.

При обновлении конфигурации 1С с таблицами вообще ничего не произойдёт. Они точно не будут удалены, так как в самом худшем варианте 1С будет делать DR OP TABLE, а там VIEW ... Будет ошибка.

Если честно, то изменять структуру справочника с последующим обновлением конфигурации я не пробовал. Думаю, что в случае со справочником, таблица регистрации изменений не будет затронута, так как, как бы мы не меняли структуру справочника, таблицу регистрации изменений интересует только первичный ключ [_IDRRef], а он всегда будет неизменен. 1С достаточно умна, чтобы это понять и не трогать свои служебные таблицы лишний раз.

С регистрами сведений и теми объектами, которые регистрируют свои изменения по составным ключам, состав которых можно изменять в конфигураторе, проблемы точно будут. Тут можно сделать следующее:
1. Скопировать текущие изменения из таблицы CHANGES в ранее переименованную таблицу регистрации изменений 1С.
2. Переименовать вьюху (в данный момент она имеет название таблицы 1С).
3. Переименовать таблицу 1С из пункта 1 в своё оригинальное имя, которое она имела до создания вместо себя вьюхи.
4. Выполнить обновление конфигурации и её реструктуризацию.
5. Накатить тюнинг-пакет на новую структуру.

Могу помочь с написанием необходимых скриптов или отвечу на дополнительные вопросы.
3. Jem j (jem) 84 11.01.17 10:50 Сейчас в теме
Спасибо за разъяснение! Попробую. 1С у не предлагали такую реализацию? ) Что-то у них в этой области совсем подвижек не наблюдается.
4. Дмитрий Жичкин (zhichkin) 201 11.01.17 11:47 Сейчас в теме
(3) Нет, не предлагал. Там умные люди работают. Знают что делают. Думаю из-за необходимости поддержания обратной совместимости планы обмена ещё долго трогать не будут.
Было бы интересно узнать о практических результатах Ваших испытаний ... Поделитесь ?