Надежная регистрация изменений. Версионирование объектов. Аудит. Все средствами SQL Server

14.06.22

Администрирование - Информационная безопасность

Высший пилотаж с механизмом Change Data Capture от SQL Server в связке с платформой 1C.

Следи за рукой

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

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

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

И это нормально! Не нормально - это пытаться использовать один "универсальный" инструмент для решения всех этих задач, проблем.

Так давайте пойдем дальше и посмотрим на один из путей решения. Один из множества. А именно на механизм Change Data Capture из SQL Server. И путь его использования с платформой 1С.

 

Обычный ход

Прежде чем начать нужно сказать пару слов о том как это обычно делается в мире 1С. Примерно это выглядит так:

  • Планы обмена - объекты конфигурации 1С, задача которых предоставить инфраструктуру для регистрации изменений, формирования и обработки сообщений и возможность использования распределенной информационной базы (что не обязательно). При этом сам механизм имеет как плюсы, так и минусы. Подробно на этом останавливаться не будем, но в высоконагруженных системах использовать планы обмена дело последнее из-за узких мест в его работе. Подробнее смотрите статьи здесь, на Инфостарт.
  • Собственная таблица регистрации - обычно реализуется на регистрах сведений, но бывают и более извращенные случаи. Фактически создается отдельная таблица, где разработчик может более гибким образом управлять статусами объекта. В основном так решаются задачи регистрации изменений только для обмена со сторонними системами. Истории изменений самих данных как таковых нет.
  • Версионирование объектов - штатный механизм из БСП и его вариации в виде регистра сведений, в котором сохраняется сериализованная версия объекта на момент изменения. Вот его краткое описание на примере УТ 11. Относительно популярный подход хранения изменений объекта с детализацией до конкретных полей, но влияющий как на скорость записи в базу (обычно незначительно, относительно основного времени записи), так и на размер самой базы (а этот фактор уже очень сильный, иногда половину размера базы может занять история версий объектов, особенно если их не чистить).
    • Сам подход хранения версий был настолько популярен, что в итоге подобный же механизм включили на уровне самой платформы 1С в виде "Истории данных", который проще в использовании, но имеет меньше контроля над своей работой. И больше ошибок, хотя с ними сталкивался достаточно давно и в новых версиях может все работает намного лучше.
    • Механизм решает задачу хранения истории изменений, но работает относительно медленно при чтении данных версий, т.к. каждую из них нужно предварительно распаковать или нормализовать.
  • Журнал регистрации - еще один штатных механизм для логирования изменений, но на верхнем уровне. Больше подходит для задач аудита и то не всегда. Содержит информацию кто, что и когда изменил, а также большое количество других событий для анализа. В части отслеживания изменений может помочь увидеть только сам факт изменения и его инициатора, но на вопросы кто изменил и что точный ответ дать не сможет. Хотя есть умельцы, которые версии объектов в виде текста сохраняют в журнал регистрации. Без комментариев. В целом механизм медленный и не поддающийся нормальной интеграции с другими инструментами и системами, только через различные костыли.

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

 

Берем под контроль

Отбросим штатные средства и попытаемся использовать механизм регистрации изменений Change Data Capture из SQL Server. Главная причина, почему будем использовать именно его - доступность (SQL Server до сих пор самая популярная СУБД для систем на базе 1С), высокая производительность и детализация истории изменений. Хотя и для PostgreSQL подобные возможности есть, но мы их рассматривать не будем. Поехали!

 

Общая архитектура

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

Фоновый процесс сканирует записи в журнале транзакций и загружает их в таблицы регистрации изменений, которые механизм CDC создает автоматически на каждую отслеживаемую таблицу. Таким образом, регистрация изменений происходит асинхронно и не влияет явно на операции в базе данных.

При включении поддержки CDC для всей базы сначала создаются служебные таблицы в схеме "cdc", информацию о которых Вы можете узнать в официальной документации (в SSMS их можно найти в списке системных таблиц):

  • [cdc].[change_tables]
  • [cdc].[ddl_history]
  • [cdc].[lsn_time_mapping]
  • [cdc].[captured_columns]
  • [cdc].[index_columns]

Как только Вы включаете регистрацию изменений для конкретной таблицы, например, для таблицы [dbo].[v8users], то сразу добавляется таблица для сохранения изменений [cdc].[dbo_v8users_CT] со структурой, аналогичной исходной таблице, но при этом с дополнительными служебными полями:

  • [__$start_lsn] - Регистрационный номер транзакции в журнале (LSN), связанный с фиксацией транзакции изменения.
  • [__$end_lsn] - Указано только в ознакомительных целях. Не поддерживается. Совместимость с будущими версиями не гарантируется.
  • [__$seqval] - Значение последовательности, используемое для упорядочивания изменений строк в пределах транзакции.
  • [__$operation] - Определяет операцию языка обработки данных (DML). 1 - удаление, 2 - вставка, 3 - обновление (старые значения), 4 - обновление (новые значения).
  • [__$command_id] - Отслеживает порядок операций в транзакции.

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

Кроме служебных таблиц в базе появляются также объекты:

  • Множество служебных хранимых процедур в схеме "cdc".
  • И функции для удобного получения истории изменений по таблицам.
  • Задания для загрузки изменений из журнала транзакций и очистки исторических данных.
  • И некоторые другие объекты.

И все было бы хорошо, но просто так CDC подружить с 1С не получится, т.к. появятся следующие проблемы:

  • При проведении реструктуризации базы данных механизм CDC для обновляемой таблицы будет отключен и нужно будет его вручную включить обратно.
  • В момент отключения механизма CDC из-за реструктуризации может появиться потеря информации об изменениях.
  • И, конечно, будет проблема в части использования информации об изменении данных из CDC, ведь официальной поддержки у платформы 1С для этого механизма нет.

Но не стоит отчаиваться, так как все эти проблемы можно решить. Этим мы и займемся дальше. В одной статье полноценно все рассказать нельзя, но направление работ определить точно можно.

 

Делаем настройку

Данный подход по настройке CDC подходит для любых приложений, которые используют SQL Server в качестве СУБД. Подробные шаги по настройке описаны здесь. Мы будем адаптировать подход к информационной базе 1С.

 

Подготовка

На первом шаге создадим в базе новую схему данных "yy", чтобы все новые объекты хранить там и не смешивать их с объектами платформы 1С.

 
 Новая схема

Первым объектом в новой схеме станет таблица настроек. В ней мы будем хранить следующую информацию:

  • Имя исходной таблицы в базе данных, для которой мы хотим поддерживать настройки CDC.
  • Флаг использования CDC.
  • Имя таблицы CDC, которая была создана системой автоматически. Вручную не заполняем (!!!).
  • Текущее имя таблицы, куда переадресуется сохранение регистрируемых данных. То есть данные в основной таблице CDC мы хранить не будем, они будут переадресованы в нашу собственную таблицу. Этот параметр вручную заполнять не нужно (!!!), все будет сделано автоматически.
  • И данные, по которым мы можем определить изменяли ли таблицу DDL-командами: идентификатор объекта и дата последнего изменения объекта.
 
 Таблица настроек CDC

Дополнительно создадим две функции, которые будут возвращать имена схем. Это просто для удобства.

 
 Небольшие служебные функции

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

  • Имя схемы исходной таблицы
  • Имя исходной таблицы
  • И флаг использования CDC

Вот как будет выглядеть эта процедура.

 
 Процедура обновления служебных полей в настройке

Все основные моменты описаны на листинге выше.

Теперь мы готовы перейти к следующему этапу.

 

Переопределяем поведение

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

Для решения этой проблемы предлагается такой вариант:

  • Изменить поток данных об изменениях, который формируется из файла логов транзакций, таким образом, чтобы изменения записывались не в служебную таблицу CDC (которая как-раз и удаляется при реструктуризации), а в нашу собственную таблицу. Тогда при реструктуризации никаких потерянных изменений не будет.
  • Ну а для включения CDC после реструктуризации сделаем некоторое задание (job), которое асинхронно обновит настройки CDC для новых таблиц максимально оперативно.

Первым пунктом и займемся. Схема будет такой:

  1. Есть штатная таблица CDC, куда SQL Server в реляционном формате сохраняет данные об изменениях. О них мы уже говорили выше. На скриншоте пример такой таблицы. Все они находятся в схеме "cdc".
  2. Мы автоматически по таблице настроек CDC "MaintenanceSettingsCDC" будем создавать в схеме "yy" служебную таблицу с именем формата "<ИмяТаблицыCDC>_<ДатаСозданияСоВременем>". При каждой реструктуризации будет создаваться такая таблица, что позволит сохранить работоспособность CDC при любых изменениях структуры таблицы. Фактически у нас будет история изменений таблицы DDL-командами. На скриншоте как-раз есть история из трех реструктуризаций.
  3. Чтобы новая, переопределенная таблица CDC была задействована, нужно для штатной таблицы CDC создать триггер вида "INSTEAD OF INSERT", чтобы все вставки перенаправлялись в нашу собственную таблицу.
  4. В момент переключения также переместим все накопившиеся изменения из штатной таблицы CDC в нашу собственную таблицу. Так никакие изменения не потеряются.

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

 
 Процедура перенаправления потока данных CDC

Процедура задокументирована в листинге. Основные шаги такие:

  1. Создается собственная таблица для хранения изменений.
  2. На штатную таблицу CDC создается триггер для перенаправления операций INSERT в нашу собственную, переопределенную таблицу.
  3. Из штатной таблицы переносятся накопившиеся изменения в переопределенную таблицу.

То есть на этом этапе у нас уже есть настройки и механизм переопределения потока данных об изменениях CDC. Осталось это как-то применить.

 

Применяем настройки

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

Для проверки доступности обновления настроек сделаем процедуру.

-- Процедура позволяет определить доступность применения настроек CDC в данный момент
CREATE PROCEDURE [yy].[ApplySettingsCDCAvailable]
	@availableResult int OUTPUT
AS
BEGIN
	SET NOCOUNT ON;
	-- Если в таблице сохраненной конфигуарции есть хоть одна запись,
	-- то считаем, что идет обновление и никаких настроек CDC применять не нужно
	SELECT
		@availableResult = CASE WHEN COUNT(1) > 0 THEN 0 ELSE 1 END
	FROM [dbo].[ConfigSave]
END
GO

Теперь при начале обновления информационной базы мы будем уверены, что CDC не будет включен для таблицы, пока реструктуризация перезаливает данные из старой версии таблицы.

Сама процедура применения настроек CDC будет выглядеть так.

 
 Применение настроек CDC

Общий алгоритм такой:

  1. Получаем настройки CDC из таблицы MaintenanceSettingsCDC и обходим каждую.
  2. Проверяем включен ли CDC для объекта.
    1. Если включен, то:
      1. Проверяем изменилась ли схема объекта или объект был полностью пересоздан
      2. Включаем CDC
      3. Обновляем служебные настройки
      4. Переопределяем поток данных
    2. Если выключен, то просто включаем:
      1. Включаем CDC
      2. Обновляем служебные настройки
      3. Переопределяем поток данных
  3. Отключаем настройку CDC у объектов, для которых нет активной записи в таблице MaintenanceSettingsCDC.

Для применения настроек достаточно вызвать:

EXECUTE [yy].[ApplySettingsCDC] 
GO

И дело сделано!

 

Сопровождать и остаться в живых

Инфраструктура готова, но не запускать же это каждый раз вручную? Правильно!

Проще всего создать задание (Job) и запускать актуализацию настроек CDC раз в 15 секунд, например. Это решит большинство кейсов в части включения CDC во время изменения структуры базы данных после обновления.

Скрипт создания задания смысла приводить нет. Главное сделайте расписание раз в 15 секунд и вызывайте процедуру:

EXECUTE [yy].[ApplySettingsCDC] 
GO

Вот и все сопровождение. Или не все?

Для мониторинга работы CDC можно использовать стандартный журнал логов SQL Server и историю работы заданий в SQL Server Agent. В остальном ничего особого не нужно.

 

Используем в своих целях

Мы все настроили, все работает. Но что это нам дает и как это использовать?

 

Шаг за шагом

Проведем небольшой тест. Например, у нас есть документ "Реализация товаров" из демобазы БСП. На стороне базы данных он представлен таблицами:

 

Включим для этих таблиц CDC через настройки.

 

Как видно, заполнили только 3 поля. Как только задание применения настроек CDC отработает, то картина изменится на следующую.

 

При этом в схеме "yy" добавлены переопределенные таблицы.

 

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

 

Как Вы думаете, сколько транзакций базы данных мы увидим? Ответ простой: 3:

  • Первая транзакция (идентификатор 0x000000AF0000AAA80008) - это добавление новых записей в таблицы. Документ в этот момент был записан без проведения. Данные в документе были только в шапке и в таб. части "Товары", поэтому таблица для счетов на оплату пустая. Вот такие записи в таблице логов изменений.
 
 Изменения в первой транзакции
  • Вторая транзакция (идентификатор 0x000000AF0000AB38000A) - это проведение документа. Фактически было изменено только поле "Проведен" (_Posted).
 
 Изменения во второй транзакции
  • Третья транзакция (идентификатор 0x000000AF0000AD500074) - обновление поля "Комментарий". В таблице изменений представлена также двумя записями UPDATE и с единственным измененным полем.
 
 Изменение в третьей транзакции

Таким образом, мы имеем детальную информацию об изменениях документа на каждом шаге, по каждому полю.

 

Кратко: где используется

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

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

Статья слишком маленький формат, чтобы сразу здесь описать как присоединять Kafka или как удобно из 1С читать таблицы изменений CDC. Но основной посыл должен быть ясен.

 

Зачем, если можно не использовать

Незачем! Если Вы не видите плюсов в применении механизма регистрации данных, то скорее всего вам это и не нужно. Аналогичный подход можно использовать и для баз PostgreSQL, но со своими нюансами. По этому поводу можно прочитать интересную статью.

Если же штатные инструменты регистрации и обмена Вас не устраивают, а построить DWH в связке с 1С - для Вас большая боль, то CDC может стать отличным стартом. Далее можно развивать использование этого механизма, добавить новые инструменты очередей и аналитики и вот появится новый уровень развития информационных систем.

P.S. Спасибо, что дочитали! Всем добра!

 

Другие ссылки

 

Авторские разработки

 
 Другие разработки (бесплатные и за $m)

CDC SQL Server Change Data Capture аудит регистрация изменения обмен DWH хранилище данных

См. также

Инструменты администратора БД Инструментарий разработчика Роли и права Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

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

10000 руб.

10.11.2023    7317    27    4    

51

Инструменты администратора БД Роли и права Системный администратор Программист Пользователь 8.3.14 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Документооборот 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)

Роли… Вы тратите много времени и сил на подбор ролей среди около 2400 в ERP или 1500 в Рознице 2, пытаясь понять какими правами они обладают? Вы все время смотрите права в конфигураторе или отчетах чтоб создать нормальные профили доступа? Вы хотите наглядно видеть какие права дает профиль и редактировать все в простом виде? А может хотите просто указать подсистему и дать права на просмотр и добавление на объекты и не лезть в дебри прав и чтоб обработка сама подобрала нужные роли? Все это теперь стало возможно! Обновление от 15.12.2023, версия 1.1.

14400 руб.

06.12.2023    5637    24    1    

54

SALE! %

Инструментарий разработчика Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Россия Платные (руб)

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

3600 2880 руб.

14.01.2013    181970    1104    0    

876

Архивирование (backup) Журнал регистрации Поиск данных Системный администратор Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

База данных «сама» меняет данные в документах/справочниках? Тогда данный журнал регистрации изменений документов в 1С для Вас! Практически не влияет на скорость записи объектов за счет быстрого алгоритма! Скорость работы почти в 2 раза выше типового механизма «История изменений». Позволяет следить за изменениями и удалением в любых ссылочных объектах конфигурации, с возможностью архивации по HTTP(!) или COM, и сверткой данных. А так же, может восстановить состояние реквизитов (значения) до момента изменения или удаления объекта из базы. Есть ДЕМО-база где можно самостоятельно протестировать часть функционала! Работает на любых платформах выше 8.3.14+ и любых конфигурациях! Версия 3.1 от 24.08.2023!

21600 руб.

15.05.2017    43107    12    24    

40

Журнал регистрации Мониторинг Системный администратор Программист Бизнес-аналитик Руководитель проекта Платформа 1С v8.3 Платные (руб)

В сферу обязанностей при работе с клиентами входит контроль работы баз данных и серверов 1С. Нужно понимать что происходит в базах, есть ли ошибки, зависания у пользователей и фоновых задач, блокировки или какое-то необычное поведение системы, получение информации о причинах возникновения проблем и их оперативное устранение и т.д. В качестве источников информации использую консоль кластеров 1С, технологический журнал 1С, журналы регистрации базы 1С. Для автоматизации части операций мониторинга и анализа создал инструмент на основе 1С.

9000 руб.

28.08.2019    32261    18    21    

70

Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтер Пользователь Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).

14400 руб.

29.04.2020    30060    88    151    

63

Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Брандмауэр для сервера 1С включает в себя управление возможностью начала и возобновления сеансов пользователей по различным условиям, ограничение общего числа возможных сеансов для работы с информационной базой, резервирование возможности работы с информационной базой определенных польззователей, запрет запуска нескольких сеансов для пользователя, журнализация событий начала (возобновления) и завершения (гибернации) сеансов, ведение списка активных сеансов для информационных баз кластера серверов

3600 руб.

06.02.2017    31547    32    18    

48

Журнал регистрации Системный администратор Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Конфигурация LogiCH эффективно решает проблему хранения и анализа записей журналов регистрации. Разработка использует столбцовую СУБД ClickHouse, одну из самых быстрых Big Data OLAP СУБД. Любой анализ журнала можно выполнить в одном отчете, в котором доступны все возможности СКД с учетом ограничений RLS. Количество подключаемых баз не ограничено и не влияет на скорость построения анализа.

5000 руб.

28.11.2018    20087    14    6    

37
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. mkalimulin 1208 15.06.22 08:31 Сейчас в теме
Журнал транзакций журнала транзакций. Это же прекрасно!
20. NiGMa 18.06.22 13:11 Сейчас в теме
(1) Уж скорее дайджест журнала транзакций.
И это действительно прекрасно.
2. Silenser 610 15.06.22 08:33 Сейчас в теме
Спасибо, не был в курсе этого механизма. Интересненько. А что по сравнению с платформенными средствами (Планы обмена и платформенное версионирование) с точки зрения быстродействия?
Так же не очень понял по реструктуризации: если я правильно помню, то при обновлении платформа создает копии таблиц с суффиксами, которые при принятии изменений, переименовываются, а старые удаляются, имена же не меняются, в чем подвох?
3. пользователь 15.06.22 08:39
(2) по быстродействию все индивидуально. Но в целом это значительно производительнее 1Сных механизмов.
Смотрите по своим мощностям, железу и так далее. Давай маркетинговые цифры в процентах не очень хочется :)

>> переименовываются, а старые удаляются, имена же не меняются
То, что это уже другой объект, никак не связанный со старыми настройками CDC.
4. Torin 783 15.06.22 08:45 Сейчас в теме
(3) Что будет с базой если раз 10 сделать перепроведение 1000 документов?
5. пользователь 15.06.22 08:47
(4) развергнутся небеса и пойдет дождь из 8 килобайтных страниц :)
6. Torin 783 15.06.22 08:58 Сейчас в теме
(5) :) не слабый такой "прирост" ИБ :)
7. пользователь 15.06.22 09:00
(6) :))))

На самом деле не все так страшно, потому что для этих таблиц можно без проблем включить сжатие уровня PAGE.
Плюс исторические данные хранить долго там смысла нет.
Можно ежедневно отправлять их в ClickHouse через Kafka и так далее, а в самой базе вычищать.
Или даже раз в неделю. Так что это мелочи.

Хранить историю изменений в OLTP-базе в любом случае дело такое.
NiGMa; Torin; +2 Ответить
8. kalyaka 1085 15.06.22 09:52 Сейчас в теме
Очень технологично!

В дополнение к статье пара ссылок, заодно и расшифровка CDC:
What is change data capture (CDC)?
Change Data Capture(CDC) in PostgreSQL
9. Virikus 62 15.06.22 10:24 Сейчас в теме
В типовой УТ 11 объект храниться в виде xml и можно вернуться на нужную версию документа очень легко.

Тут же мы видим историю изменений и чтобы вернуться на нужную версию придется последовательно накатывать в обратную сторону все версии. Что не совсем удобно. Для сравнения версий нужно будет аналогично применять танцы с бубном.

На самом деле CDC достаточно мощный механизм и он больше подходит для интеграции и биг даты, чем для версионирования.
10. пользователь 15.06.22 10:27
(9) Зачем "накатывать" последовательно все версии?

Было 3 изменения, есть 3 записи, которые отражают состояние на момент изменения.
Берите нужную запись.

Или я Вас не так понял?
11. Virikus 62 15.06.22 10:42 Сейчас в теме
(10) тут скорее я не правильно понял, ага, был не прав.
12. zhichkin 1507 15.06.22 15:31 Сейчас в теме
1. Насколько я понимаю, при реструктуризации с пересозданием таблиц данных 1С проблема заключается в том, что платформа 1С выполняет DDL команды DR OP TABLE с последующим RENAME, что, соответственно, удаляет связанный с исходной таблицей объект отслеживания изменений, в том числе таблицу регистрации изменений CDC.

В связи с этим вопрос: может быть имеет смысл восстанавливать CDC для таких таблиц, используя DDL триггеры уровня базы данных DR OP TABLE и RENAME, чтобы не зависеть от агента сервера SQL Server ? Агент может же быть остановлен...

2. В случае реструктуризации без удаления таблицы данных 1С CDC регистрирует DDL изменения и пересоздание объектов отслеживания изменений не происходит. Интересно как триггер на таблице регистрации изменений CDC выполняет перенос записей в таком случае ? По идее структура полей может не совпасть. Ещё одна проблема в таком случае, если я правильно помню, новые поля будут заполняться подсистемой CDC значениями по умолчанию, а не реальными значениями изменений.

3. Как будет реагировать CDC на так называемое "Обновление 2.0" от 1С ? Там механизм реструктуризации работает несколько иначе. Не проверяли ?
13. пользователь 15.06.22 15:39
(12)

1. Я бы не стал. Нужно поминимуму вмешваться в реструктуризацию фирмы 1С, чтобы не сломать штатные механизмы. Триггеры разве что можно использовать, если проблемы с обновлением не критичны и база не 24 на 7.

2. В этом механизме CDC будет пересоздан полностью, в условиях есть эти проверки.

3. Я не хочу трогать этот способ и длинной плакой :)
14. zhichkin 1507 15.06.22 15:45 Сейчас в теме
(13) 1. Триггеры DDL могли бы, например, просто фиксировать записи аудита в отдельную табличку. Эту табличку мог бы обрабатывать Ваш Job - меньше работы. Для механизмов 1С это абсолютно безопасно. Как вариант оптимизации...
15. пользователь 15.06.22 15:48
(14) Триггеры DDL могли бы, например, просто фиксировать записи аудита в отдельную табличку

В смысле без CDC? Опишите подробнее мысль. Потому что сейчас триггеры записи аудита CDC тоже перенаправляет в отдельную таблицу.
16. zhichkin 1507 15.06.22 16:00 Сейчас в теме
(15) Я имею ввиду триггеры DDL на базе данных. В данном случае интересует только триггер RENAME, так как он фактически указывает на завершение реструктуризации таблицы данных 1С. Ну да без CDC. Административный Job у Вас раз в 15 секунд запускается и проверяет все настройки, а мог бы проверять только реально изменённые таблицы. Это как вариант.

Другая занятная идея: триггер DDL RENAME может отправлять сообщение в очередь Service Broker, а на этой очереди можно зарегистрировать активацию (Service Broker activation) хранимой процедуры, которая пересоздавала бы CDC. Активируемая процедура выполняется в отдельной транзакции - гарантированно после завершения транзакции DDL. В таком случае пересоздание CDC происходило бы в отдельной транзакции и фактически в режиме реального времени. Ну это так на подумать...
YPermitin; +1 Ответить
17. пользователь 15.06.22 16:41
(16) все сделано для того, чтобы не вмешиваться в процесс реструктуризации, какой бы он не был.

А то что агент выключен, ну такая себе причина. На то есть мониторинг, чтобы этого случайно не случилось. Да и CDC без агента не будет работать.

Поэтому вариант с триггерами мне не очень нравится.
18. German 413 16.06.22 21:49 Сейчас в теме
Редуцент. Для систем с сервером приложений (3 уровневых) смысла в данном аудите примерно 0.
Но о механизме не знал, спасибо
19. пользователь 16.06.22 21:50
(18) радикальное, бескомпромиссное утверждение)
Оставьте свое сообщение