Каталог решений - Использование SQL Server Change Tracking для регистрации изменений данных объектов 1С:Предприятие 8

Любой обмен данными начинается с регистрации изменений. SQL Server предоставляет для этих целей следующие возможности:

1. DML триггеры (любые версии SQL Server). Имеется возможность асинхронной регистрации изменений, если дополнительно использовать SQL Server Service Broker.

2. Change tracking (SQL Server 2008 и выше). Синхронная регистрация изменений.

3. Change Data Capture (SQL Server 2008 и выше). Изменения читаются из логов транзакций.

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

В этой небольшой публикации я рассмотрю особенности использования change tracking на платформе 1С:Предприятие 8. Подробная информация о том, что такое change tracking можно прочитать здесь: https://blogs.msdn.microsoft.com/alexejs/2009/08/09/change-tracking-2/. Официальную документацию Microsoft по этому вопросу можно почитать здесь: https://technet.microsoft.com/ru-ru/library/cc280462(v=sql.105).aspx.

Что это такое.

Change tracking работает похожим на план обмена образом: SQL Server создаёт для каждой отслеживаемой таблицы ещё одну, служебную, для записи в неё изменений. Эта таблица, кроме ключа изменённой записи, включает в себя:

— версию изменения (одно изменение — одна запись);

— вид изменения (insert, update, delete);

— битовую маску изменённых полей (так можно отслеживать какие поля были изменены);

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

Следует отметить, что change tracking не фиксирует изменения в разрезе узлов обмена, не содержит логики нумерации сообщений и квитирования. Эта технология имеет только одну логику и выполняет только одну функцию — регистрацию изменений. Что с ними делать решает код прикладного приложения. Нет ничего лишнего. При этом выполнение регистрации изменений оптимизировано на уровне ядра SQL Server, чтобы выполняться максимально быстро и оказывать минимально возможную нагрузку на систему. Мне как-то попалось на глаза мнение, что change tracking работает до выполнения триггеров и выполняет регистрацию изменений в 4 раза быстрее, чем если бы делать это при помощи триггеров. Честно говоря, я эту информацию не проверял.

Как включить.

Функция change tracking включается на уровне базы данных. После этого необходимо включить отслеживание изменений для тех таблиц в этой базе данных, для которых это нужно. При этом следует иметь ввиду, что такая таблица обязательно должна иметь ограничение primary key. Таким образом в контексте 1С:Предприятие 8 это означает, что мы можем использовать change tracking для таблиц всех ссылочных объектов платформы без особых проблем, но для, например, регистров сведений это сделать сразу не получится. Для этого придётся сначала удалить уникальный кластерный индекс регистра, а затем создать точно такой же индекс, но уже как первичный ключ (primary key). В контексте SQL Server будет правильнее сказать: «наложить на таблицу ограничение первичного ключа». При этом нужно помнить, что SQL Server не допускает для полей, входящих в состав первичного ключа, NULL значения. Платформа 1С:Предприятие 8 переносит подобное изменение совершенно спокойно. Однако, нужно иметь ввиду, что на больших таблицах эта операция может выполняться продолжительное время, что сопоставимо с перестроением индекса.

Реструктуризация 1С.

Существенным нюансом при использовании change tracking является внесение изменений в структуру объектов конфигурации 1С, которые влекут за собой реструктуризацию. Дело в том, что при выполнении реструктуризации данных 1С делает это следующим образом (в сокращённом варианте):

1. Переименовывает основную рабочую таблицу (используется системная хранимая процедура sp_rename).

2. Создаёт новую таблицу с теми изменениями, которые сделаны в конфигураторе.

3. Копирует данные из старой рабочей таблицы в новую.

4. Удаляет бывшую рабочую таблицу !

5. Переименовывает новую таблицу (она становится рабочей).

При этом важно то, что DDL оператор DROP TABLE полностью удаляет все зарегистрированные на данный момент времени для этой таблицы изменения и выключает change tracking. Тоже самое касается пользовательских триггеров и индексов, если они были вами добавлены ранее. По большому счёту это не так страшно, но потеря регистрации изменений может быть неприятной.

Для защиты от непредвиденной потери регистрации изменений можно использовать DDL триггер RENAME (устанавливается на уровне базы данных). Эта возможность, так же как и change tracking, появилась в SQL Server 2008.

Вот и всё =)

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

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

Практический пример.

В качестве демонстрации практической возможности использования этой технологии совместно с платформой 1С:Предприятие 8 можно использовать следующее готовое решение: //sale.itcity.ru/public/557097/