Как отследить изменения во многих базах данных SQL Server из приложения.NET?
Проблема:
Существует много различных баз данных, которое заполняется многими различными приложениями непосредственно (без любого слоя распространенного приложения). К данным может получить доступ только через SP (политика)
Задача:
Приложение должно отследить изменения в этих базах данных и реагировать в минимальное время.
Возможные решения:
1) Создайте триггер для каждой таблицы в каждой базе данных, которая заполнит одну таблицу с событиями. Приложение будет наблюдать эту таблицу через SqlDependency.
2) Наблюдайте каждую таблицу в каждой базе данных через SqlDependency.
3) Создайте триггер для каждой таблицы в каждой базе данных, которая уведомит приложение с помощью организованного расширения.
Который является лучшим способом?
2 ответа
Это может быть обширная тема. Прежде всего: какая версия SQL Server используется?
если вы используете SQL 2008, Система отслеживания измененных данных - лучший инструмент Эта новая функция позволяет отслеживать КАЖДОЕ изменение, внесенное в базы данных в SQL 2008. Это включает изменений DDL , а также изменений данных . Ознакомьтесь с введением здесь .
Если вы используете старую версию SQL 2008 и вам разрешено изменять DDL базы данных, вариант 3 будет вариантом выбора (из тех случаев, когда вы описано). Я бы не рекомендовал это, поскольку есть другие вещи, которые следует учитывать, например, что происходит, когда транзакция откатывается или когда триггеры деактивируются при массовой вставке , например?
Это будет проблемой, чтобы ваше решение работало должным образом во всех этих случаях.
Другой способ - посмотреть файл журнала транзакций . Это, безусловно, лучший, но также наиболее сложный способ сделать это, поскольку документации по проприетарному формату журнала почти нет. Также он привязан к определенной версии SQL Server. Это приведет к отсутствию влияния мониторинга выбранных баз данных.
Еще один подход заключается в создании копии данных , которую необходимо отслеживать и периодически проверять, есть ли различия. Это дает то преимущество, что НЕТ изменений в источнике базы данных должны быть созданы.А также избавиться от проблем с транзакциями или массовой вставкой. Начиная с момента следующего запуска мониторинга, вы сможете обнаружить изменения.
Влияние на производительность минимально, поскольку для отслеживаемых таблиц потребуется только последовательное чтение первичного индекса. И это, безусловно, наиболее оптимизированный способ взаимодействия с базой данных. Однако этот подход потребует значительных усилий при разработке. Я должен знать, так как это мое основное внимание с последних лет. Отметьте здесь ;)
(Я надеюсь, что со ссылками все в порядке, в этом случае, поскольку они по теме, в противном случае я удалю их)
Вы не рассматриваете возможность использования профилировщика SQL. Используя фильтр, вы можете выбрать только операции обновления, а затем записать в журнал.