Триггер для обновления данных на другом сервере SQL

Question

Я использую два SQL Server, один - SQL Server 2000, а другой - SQL Server 2005.

Когда таблица1 в SQL Server 2000 обновляется / вставляется / удаляется, мне приходится обновлять другую таблицу в SQL Server 2005. Можно ли добиться этого в триггере? Если нет, какие будут возможные варианты?

Спасибо, хорошего дня!

Answer 1

Если вы хотите реплицировать данные, а не просто установить что-то по-другому, вам следует взглянуть на SQL Replication, поскольку он будет намного лучше управлять вещами. например, он будет выполнять обновления асинхронно.

Если вам нужно выполнять их синхронно, или вы просто решаете, что это проще, или вам нужна вся операция, заключенная в одну транзакцию, я бы включил логику в процедуру для обеспечения чистоты. Вы можете создать связанный сервер с 2000 по 2005 год и ссылаться на таблицу оттуда как SERVER.DATABASE.SCHEMA.TABLE. В качестве альтернативы вы можете выполнить хранимую процедуру на удаленном сервере, чтобы выполнить вставку / обновление / удаление.

Если вам не нужна репликация SQL, вы можете вместо этого записать вставку / обновление / удаление из 2000 в отдельную таблицу в той же базе данных через триггер. Затем создайте отдельное задание, которое записывает эти изменения в 2005 г., а затем удаляет их из таблицы. Это будет означать, что вы можете объединить изменения, а обновления исходной таблицы будут выполнены быстрее, лучше справиться с потерей связи между двумя серверами. Однако у вас меньше гарантий того, что обновления действительно будут применены к серверу 2005 года, и у вас есть дополнительная сложность задания sql, которое необходимо запустить. Так что это компромисс. И как только вы начинаете писать и поддерживать подобную логику, вы понимаете, что именно поэтому MS пишет репликацию, так что вам не нужно.

Answer 2

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

Почему бы не использовать триггеры?

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

Вам потребуется настроить MSDTC (координатор распределенных транзакций) между связанными серверами

СУБД не может вам сильно помочь со связанными серверами. гораздо сложнее отлаживать SQL. Плохие запросы обычно просто зависают и время ожидания при несовпадении типов и т. Д.

Транзакции с несколькими записями в триггере ИЛИ в запросе, запускающем триггер, легко вызывают взаимоблокировки . Я хотел бы использовать триггеры только для очень простых обновлений (один оператор INSERT / UPDATE / DELETE) и даже тогда убедиться, что взаимоблокировки не могут возникнуть. Я помню одну интеграцию, которую мне пришлось полностью переписать, когда устаревшее приложение вызывало взаимоблокировку с триггером.

Альтернатива

Есть как минимум два вопроса:

• Синхронизация между таблицами односторонняя или двусторонняя?
• Совпадают ли схемы двух таблиц?

Если схемы совпадают, репликация должна быть идеальной как для односторонней, так и для двусторонней синхронизации.

Если схемы отличаются, как обычно в случае интеграции приложений (EAI), вы можете рассмотреть следующие вопросы:

• Службы интеграции (SSIS) или даже пакет dtsx, созданный инструментом импорта / экспорта
• Какой-нибудь другой инструмент EAI, если таковой имеется (например, BizTalk)
• программирование пользовательского инструмента интеграции

У меня нет большого опыта работы с инструментами EAI, но я сравниваю SSIS с пользовательскими решениями .NET. Могу только сказать, что вы сэкономите много времени, если сможете выполнить работу с SSIS.

Только если SSIS не работает или недоступен (SQL Express), я бы попытался запрограммировать службу Windows, службу WCF и т. Д.

Answer 3

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

ТАК, что внутри вашего триггера вы бы сделали что-то вроде этого.

UPDATE linkedserver.Database1.dbo.myTable
SET ...
WHERE ---

с вашими значениями для набора и ГДЕ.

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