Отслеживание изменений в таблице БД

@_katon_ · Регистрация: 03.10.2011

Студворк — интернет-сервис помощи студентам

Добрый день!

MS Sql Server 2012.

Есть две БД расположенные на одном сервере. В БД №1 данные храняться в ненормализованом виде, в одной плоской таблице. БД №2 по данным представляет собой ту же БД №1, но в нормализованном виде.
Сейчас БД №2 синхронизируется с БД №1 посредством триггера на плоской таблице в БД №1.

Вопрос следующий: Какая есть альтернатива триггеру с учетом того, что задержка в создании записей в БД №1 и №2 должна быть минимальной?

@invm · 29.05.2017, 12:09

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

задержка в создании записей в БД №1 и №2 должна быть минимальной

Не выйдет.
Чтобы минимизировать время вставки в БД1, придется пожертвовать оным в БД2.
Для начала попытайтесь оптимизировать сам триггер. Если результат не удовлетворит, определяйтесь до какой степени можно жертвовать БД2. От этого будет зависеть какие альтернативные варианты можно применить.

@_katon_ · 29.05.2017, 12:54 **[ТС]**

Производительность триггера устраивает

.
Я хотел бы от него отказаться, потому что даже при использовании try catch и именованных транзакций, возможны исключения ведущие к откату неявной транзакции на вставку в триггере.
Данные в БД №2 я могу восполнить при их потере, а вот Данные в БД №1 не востановимы.

@invm · 29.05.2017, 14:29

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

Производительность триггера устраивает.

Тогда зачем про нее спрашивать?

Настройте для таблицы в БД1 Common Data Capture - асинхронный механизм отслеживания изменений. Все что наотслеживалось, опять же асинхронно, переносить в БД2.

@_katon_ · 29.05.2017, 15:35 **[ТС]**

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

Тогда зачем про нее спрашивать?

а я и не спрашивал. Я спрашивал про альтернативу.

Про Common Data Capture сейчас погуглю, спасибо!

Добавлено через 22 минуты
Я понял о чем речь. Рассматривал уже вместе с Change Tracking. Не совсем понимаю как мне это поможет?
Если я все правильно понял, то в таком случае мне надо писать windows service, который будет следить за служебной таблицей с логом и в случае обнаржуения новых записей переносить их в БД №2. Я могу это сделать, но не знаю как такой сервис грамотно написать:
- какую технологию доступа к данным использовать?
- с какой периодичностью нужно организовывать проверку к таблице?
- возмжно обращение к логу это почти как обращение к исходной таблице (по времени) и тогда Common Data Capture в моем случае бесполезно.

Я чего-то не понимаю?

@invm · 29.05.2017, 15:57

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

в таком случае мне надо писать windows service, который будет следить за служебной таблицей с логом и в случае обнаржуения новых записей переносить их в БД №2

Не нужно из пушки по воробьям. Достаточно написать хранимую процедуру, которая будет выгребать изменения и переносить их в БД2. Процедуру вызывать с заданной периодичностью из джоба, либо через планировщик Windows.

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

возмжно обращение к логу это почти как обращение к исходной таблице (по времени) и тогда Common Data Capture в моем случае бесполезно.

Расшифруйте, что вы имели в виду?

@_katon_ · 29.05.2017, 16:28 **[ТС]**

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

Процедуру вызывать с заданной периодичностью из джоба, либо через планировщик Windows.

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

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

Расшифруйте, что вы имели в виду?

Я имел ввиду, что мне не очевидно преимущество Common Data Capture. Я могу получать добавленные записи из самой таблицы, а не из ее лога (храню первичный ключ в одной из таблиц БД №2 ). Думаю, что селект к таблице с получением добавленых в нее записей и к ее логу буду приблизительно равнозначны. Я конечно могу ошибаться, но что-то мне подсказывает, что Common Data Capture в данном случае будет лишним усложнением.

Добавлено через 12 минут
Я сильно не копал (Basic Task и Task) но планировщик вроде как минимум 30 с.

@invm · 29.05.2017, 17:01

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

По поводу джоба тут такое дело.. минимальное время вызова 10 с

В SQL Server Agent минимальный интервал - 1 с.

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

Я имел ввиду, что мне не очевидно преимущество Common Data Capture.

Преимущество в том, что изменения журналируются без дополнительной нагрузки (в виде триггера) на основную таблицу.

Есть, как мне думается, наилучший вариант при ваших условиях - Service Broker.
Триггер на таблице в БД1 просто отправляет сообщения в очередь. В сообщении либо значения ключей, либо, если нужно полностью развязаться с основной таблицей или обработчик сообщений будет в БД2, полный набор вставляемых данных.
Соответственно, обработчик сообщений (процедура активации) парсит сообщения и заносит данные в БД2.
Итого имеем ряд важных преимуществ:
- очередь может быть настроена на одновременную работу нескольких обработчиков одновременно;
- если очередь находится в БД2, то БД2 может быть совершенно прозрачно перенесена на другой сервер.

@_katon_ · 30.05.2017, 09:27 **[ТС]**

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

. invm, спасибо!

@_katon_ · 01.06.2017, 15:28 **[ТС]**

Первый взгляд оказался обсалютно верным.

Оказалось SB не так популярен как хотелось бы. Поэтому, раскопать статейку с популярным изложением практического применения не так уж и просто (как оказалось). Разбирался с помощью вот этого материальчика: https://blogs.msdn.microsoft.c... 08/15/183/. По идее можно еще разобраться с помощью msdn (там есть учебник), но меня он как-то когнитивно угнетает.

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

Ну и дополнительно возник вопрос. Как лучше отправлять сообщение с триггера? Если очередь в БД источнике то все понятно. Но если очередь в БД2? Мне на ум приходит только вызов хранимой процедуры из БД2 в триггере БД1. Это вообще как, нормальное решение или так себе?

@invm · 01.06.2017, 16:12

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

Но если очередь в БД2? Мне на ум приходит только вызов хранимой процедуры из БД2 в триггере БД1. Это вообще как, нормальное решение или так себе?

Это, как бы, совсем не решение

У вас, в любом случае, в БД-отправителе должен быть сервис-инициатор. Иначе вы диалог не откроете.
Если владеете английским, есть неплохая книга - http://www.apress.com/us/book/9781590599990
Думаю, вам не составит труда найти откуда скачать.

@_katon_ · 01.06.2017, 16:43 **[ТС]**

В моем примере сервисы на одной БД

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

Добавлено через 7 минут
Посмотрев синтаксис BEGIN DIALOG CONVERSATION я разобрался в чем дело. Спасибо, invm.

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Access VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

@_katon_ 414 / 265 / 25 Регистрация: 03.10.2011 Сообщений: 1,094

	Отслеживание изменений в таблице БД 29.05.2017, 11:00. Показов 4595. Ответов 11 Метки нет (Все метки) Добрый день! MS Sql Server 2012. Есть две БД расположенные на одном сервере. В БД №1 данные храняться в ненормализованом виде, в одной плоской таблице. БД №2 по данным представляет собой ту же БД №1, но в нормализованном виде. Сейчас БД №2 синхронизируется с БД №1 посредством триггера на плоской таблице в БД №1. Вопрос следующий: Какая есть альтернатива триггеру с учетом того, что задержка в создании записей в БД №1 и №2 должна быть минимальной? 0

@_katon_ 414 / 265 / 25 Регистрация: 03.10.2011 Сообщений: 1,094
	29.05.2017, 12:54 [ТС]
	Производительность триггера устраивает . Я хотел бы от него отказаться, потому что даже при использовании try catch и именованных транзакций, возможны исключения ведущие к откату неявной транзакции на вставку в триггере. Данные в БД №2 я могу восполнить при их потере, а вот Данные в БД №1 не востановимы. 0

@_katon_ 414 / 265 / 25 Регистрация: 03.10.2011 Сообщений: 1,094
	30.05.2017, 09:27 [ТС]
	Ознакомился немного с технологией (чтобы представлячть сферу решаемых задач). Видимо это действительно то, что мне надо. Пойду "курить" это все обстоятельно. Отпишусь что получилось в итоге . invm, спасибо! 0

@_katon_ 414 / 265 / 25 Регистрация: 03.10.2011 Сообщений: 1,094
	01.06.2017, 15:28 [ТС]
	Первый взгляд оказался обсалютно верным. Оказалось SB не так популярен как хотелось бы. Поэтому, раскопать статейку с популярным изложением практического применения не так уж и просто (как оказалось). Разбирался с помощью вот этого материальчика: https://blogs.msdn.microsoft.c... 08/15/183/. По идее можно еще разобраться с помощью msdn (там есть учебник), но меня он как-то когнитивно угнетает. Когда вернулся на форум и перечитал рекомендации, то понял, что нафейли: настроил SB на БД источнике, что заставит меня писать лишний код если нужно будет, либо переносить базу, либо разворачивать ее тестовый вариант. Скорее всего буду перенастраивать! Ну и дополнительно возник вопрос. Как лучше отправлять сообщение с триггера? Если очередь в БД источнике то все понятно. Но если очередь в БД2? Мне на ум приходит только вызов хранимой процедуры из БД2 в триггере БД1. Это вообще как, нормальное решение или так себе? 0

@_katon_ 414 / 265 / 25 Регистрация: 03.10.2011 Сообщений: 1,094
	01.06.2017, 16:43 [ТС]
	В моем примере сервисы на одной БД . И я как-то не задумывался о варианте когда сервис инициатор на одной БД, а получатель на другой. Подозреваю, что сервисы при создании надо немножко по другому конфигурировать. Есть на эту тему хорошие статьи или все таки лучше найти книгу? Добавлено через 7 минут Посмотрев синтаксис BEGIN DIALOG CONVERSATION я разобрался в чем дело. Спасибо, invm. 0

Отслеживание изменений в таблице БД

Решение