Отслеживание изменений данных в ERP. История возвращения журнала базы данных

[mazzy]

Цитата:

Сообщение от raz

1. Цена?
2. Как получить?

imir, Прежде всего, спасибо что делаете.

Цитата:

Сообщение от imir

пишем периодическую процедуру, которая в фоновом режиме обрабатывает записи стандартного журнала базы данных и превращает их в записи «Журнала изменений».

э-э-э-э?!

Вопрос:
рассматривали ли фичу MS SQL, которая называется Change Tracknig?
эта фича вроде и в MS SQL Azure есть.
https://social.technet.microsoft.com...-tracking.aspx
https://docs.microsoft.com/ru-RU/sql...ql-server-2016
https://habr.com/ru/post/111207/

что не устроило в штатном Change Tracknig?

Change Tracknig используется в ax2012, ax7+ в модуле Retail.

[imir]

Цитата:

Сообщение от mazzy

рассматривали ли фичу MS SQL, которая называется Change Tracknig?
эта фича вроде и в MS SQL Azure есть.
https://social.technet.microsoft.com...-tracking.aspx
https://docs.microsoft.com/ru-RU/sql...ql-server-2016
https://habr.com/ru/post/111207/

что не устроило в штатном Change Tracknig?

Change Tracknig используется в ax2012, ax7+ в модуле Retail.

UDP. Немного запоздало, но я потратил некоторое время на изучение вопроса.

В принципе ссылка с хабра - как всегда самая полезная )

1) CT (Change Tracking) - тут не подходит по смыслу, потому что не логирует версии данных, а только факт того, что они менялись, т.е. список ключей, например, recid.

Забавно кстати, что стандартный export в BYOD может конфликтовать по таблицам с модулями, которые так же пользуются CT. И на яммере посоветовали это "проверить", а что делать - не посоветовали.

2) CDC (Change Data Capture) - не работает в Azure, я не углублялся почему, пока это так.

3) SQL Server Audit - как я понял, потребует средств чтения + в Azure, что более важно, понадобится отдельный azure BLOB storage для журнала со всеми вытекающими подписками и настройками.

Общая проблема у последних двух подходов, как и пишут на Хабре - это "зафиксировать автора изменений". Если посмотреть в текст триггера, то там для расшифровки кода пользователя дергают самописную функцию DBO.SysGetUserIdFromContextInfo().

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

Зато, пока разбирался, понял, что Change Tracking + BYOD - отлично подходят для анализа журнала БД через PowerBI. Это уже инструмент администратора, поскольку настройки прав тут не применяются, зато в нем можно проводить расследования за большие периоды, смотреть тренды и т.д.

В выложил само решение в комплекте с PowerBI-BYOD экспериментами в общий доступ.

Это не мой первый опыт с BI по жизни, но первый - с Entity -> CT -> BYOD -> PowerBI, достаточно позитивный с точки зрения затраченного времени и полученного результата.

В принципе, даже получилось реализовать аналог формы DAX с гридами и т.п. Пока что нехватает возможности использовать графики - как слайсеры, поэтому при нажатии на строку таблицы с них слетают фильтры (либо держать зажатым ctrl). На сайте ideas уже есть пост на эту тему.

[vmoskalenko]

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

Цитата:

Сообщение от imir

1) CT (Change Tracking) - тут не подходит по смыслу, потому что не логирует версии данных, а только факт того, что они менялись, т.е. список ключей, например, recid.

Тут у нас есть опыт. Делали именно на CT триггер для отправки данных в 3rd-party application из Data Entity.

Очень много багов. Так как делать надо было быстро, то все делали сами, т.е. практически переписывали стандартный X++ код работы с CT.
Например, в версии 10.0.4 Майкрософт совсем сломал CT, но быстро выпустил обновление для 10.0.4.

Вобщем, то что сделали получилось лучше и стабильней. Но исправлять ошибки в самом SQL уже не стали и пришлось придумывать "Монитор".

Так вот, Монитор.
Потом мы его немного допилили по своему усмотрению. И добавили запись в таблицу логов. За основу интерфейса взяли стандартный Database Log. За улучшением UI/UX не гнались, т.к. это внутренняя тулза, для разборов полётов. Но с ссылочными полями получилось хорошо. Потому что мы сохраняем Data Entity запись на каждое изменение в ней.

Ой, не правду говорю... Не на каждое изменение, а на каждое сканирование CT по изменениям. Так как клиент хотел быстрее, то сканирование проходило с частотой 1 раз в минуту. И для целей логирования это хорошая частота дискретизации. (60Гц? ;-) )

Итого, для CT есть две проблемы

• не всегда стабильно. Нужны костыли
• имеет дискретность (минимум 1 раз в минуту)

Но имеет приемущество, так как суть Data Entity - плоская репрезентация данных, то данные для конечного пользователя выглядят красиво и понятно.