Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Транзакции в триггерах  [new]
maximusend
Member

Откуда: Россия
Сообщений: 14
У таблицы есть триггер, который, при вносе новых данных в таблицу, обновляет данные в другой таблице (в другом SQL Server'е, в другой БД):
ALTER TRIGGER [dbo].[trigger_on_insert] 
   ON  [dbo].[Table1] 
   AFTER INSERT
AS 
BEGIN
	SET NOCOUNT ON;

	INSERT INTO [localhost\mssqlserver12_2].[db2].[dbo].[Table2]
	([Col1], [Col2])

	SELECT [dbo].[Table1].[Col1], [dbo].[Table1].[Col2]
	FROM [dbo].[Table1], inserted
	WHERE [dbo].[Table1].[Col1]= inserted.[Col1]
END

В случае отсутствия соединения с другим сервером, естественно, выдаётся сообдение об ошибке, и данные не вносятся в таблицу.
Вопрос: как сделать так, что бы данные в любом случае заносились в первую таблицу, даже если отсутствует соединение и триггер не может внести данные в другую базу данных?
19 май 12, 22:06    [12582851]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
maximusend
У таблицы есть триггер, который, при вносе новых данных в таблицу, обновляет данные в другой таблице (в другом SQL Server'е, в другой БД):
ALTER TRIGGER [dbo].[trigger_on_insert] 
   ON  [dbo].[Table1] 
   AFTER INSERT
AS 
BEGIN
	SET NOCOUNT ON;

	INSERT INTO [localhost\mssqlserver12_2].[db2].[dbo].[Table2]
	([Col1], [Col2])

	SELECT [dbo].[Table1].[Col1], [dbo].[Table1].[Col2]
	FROM [dbo].[Table1], inserted
	WHERE [dbo].[Table1].[Col1]= inserted.[Col1]
END

В случае отсутствия соединения с другим сервером, естественно, выдаётся сообдение об ошибке, и данные не вносятся в таблицу.
Вопрос: как сделать так, что бы данные в любом случае заносились в первую таблицу, даже если отсутствует соединение и триггер не может внести данные в другую базу данных?

Ответ: не вставляйте записи в другую баз данных из триггера.
19 май 12, 22:10    [12582877]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
maximusend
Member

Откуда: Россия
Сообщений: 14
Ну, возможно, вы и правы. Тогда как посоветуете реализовать автоматизированную синхронизацию двух баз данных?
19 май 12, 22:12    [12582882]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Репликация, Service Broker
19 май 12, 22:16    [12582902]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
aleonov
Member

Откуда:
Сообщений: 96
maximusend,

вариантов несколько, например, репликацией или создайте distributed view на удаленном сервере тогда не нужен ни триггер ни репликация
19 май 12, 22:19    [12582914]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
maximusend
Member

Откуда: Россия
Сообщений: 14
Mnior
Репликация, Service Broker

Тут есть ещё такое дело -- базы не полностью идентичны, точнее они даже совсем разные. И синхронизация должна быть только частичной, возможно ли это реализовать через Репликацию и Service Broker? [читаю документацию, пока что].
19 май 12, 22:20    [12582918]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
aleonov
Member

Откуда:
Сообщений: 96
maximusend
Mnior
Репликация, Service Broker

Тут есть ещё такое дело -- базы не полностью идентичны, точнее они даже совсем разные. И синхронизация должна быть только частичной, возможно ли это реализовать через Репликацию и Service Broker? [читаю документацию, пока что].


с сервис брокер не связывайтесь, посмотрите в сторону мердж репликация, можно реплицировать данные частично (по условию и заданным полям)
19 май 12, 22:22    [12582926]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
На 2005 нельзя в триггере работать с удаленным сервером. Только с другой базой на этом сервере.

Посвятите меня, что и когда поменялось.
19 май 12, 22:26    [12582945]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Deff
На 2005 нельзя в триггере работать с удаленным сервером. Только с другой базой на этом сервере.

Посвятите меня, что и когда поменялось.
Физически - можно. Но лучше не нужно.
19 май 12, 23:35    [12583273]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
aleonov
с сервис брокер не связывайтесь
maximusend, главное не воспринимайте буквально. Service Broker (SB) вещь отличная, знать полезно, но просто для данной задачи лучше использовать предназначенные средства.

Если базы совсем разные, т.е. никак не коррелируют, да и сами таблицы тоже, тогда да - репликация тут тоже не аленький цветочек, лучше уж SB.
Можно ещё и CHANGE TRACKING заюзать.
20 май 12, 00:47    [12583573]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
aleonov
Member

Откуда:
Сообщений: 96
Mnior
aleonov
с сервис брокер не связывайтесь
maximusend, главное не воспринимайте буквально. Service Broker (SB) вещь отличная, знать полезно, но просто для данной задачи лучше использовать предназначенные средства.

Если базы совсем разные, т.е. никак не коррелируют, да и сами таблицы тоже, тогда да - репликация тут тоже не аленький цветочек, лучше уж SB.
Можно ещё и CHANGE TRACKING заюзать.


change tracking требует написания дополнительного приложения и накладывает доп. ограничения на таблицы - не лучшая идея для синхронизации пары таблиц (имхо).

репликацию можно установить графич.средствами из менеджмент студии, даже новичку
20 май 12, 01:37    [12583747]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Клюёт рыбка.
aleonov
change tracking требует написания дополнительного приложения
ЩИТО?
20 май 12, 02:48    [12583830]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
2aleks: ок, убрал неполиткорректность. За разбаном ip - к джуджу, только он умеет, по-моему.

Сообщение было отредактировано: 20 май 12, 13:22
20 май 12, 13:22    [12584234]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
RubinDm
Member

Откуда:
Сообщений: 461
maximusend, Вы не с той стороны задачу решаете. первая база должна быть сама по себе, а синхронизация должна инициироваться из второй базы.
21 май 12, 14:26    [12588745]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
RubinDm
maximusend, Вы не с той стороны задачу решаете. первая база должна быть сама по себе, а синхронизация должна инициироваться из второй базы.
Только вторая база должна понимать, что ей надо синхронизировать.
А для этого на первой надо производить какие-то действия. И вот тут вариантов масса.
21 май 12, 15:29    [12589409]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
RubinDm
Member

Откуда:
Сообщений: 461
Deff
RubinDm
maximusend, Вы не с той стороны задачу решаете. первая база должна быть сама по себе, а синхронизация должна инициироваться из второй базы.
Только вторая база должна понимать, что ей надо синхронизировать.
А для этого на первой надо производить какие-то действия. И вот тут вариантов масса.

Вторая база легко может определить необходимость в синхронизации с первой базой сама. Никаких действий от первой базы для этого не требуется.
21 май 12, 16:00    [12589732]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
RubinDm
Deff
пропущено...
Только вторая база должна понимать, что ей надо синхронизировать.
А для этого на первой надо производить какие-то действия. И вот тут вариантов масса.

Вторая база легко может определить необходимость в синхронизации с первой базой сама. Никаких действий от первой базы для этого не требуется.
Совсем-совсем ничего? Это круто.
Вот задачка тогда. Дано: таблица 100 гигов, записи могут добавляться, изменяться, удаляться. Чужая разработка. Вам дали права только на чтение и канал на 2 мегабита.

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

Итак, справитесь с задачей?
21 май 12, 16:27    [12589973]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
defragmentator
Member

Откуда:
Сообщений: 20504
Делайте очередь, пусть триггер в неё пишет команды, которые нужно выполнить на другом сервере.
Запускаете job и поехали. Если связи нет, тогда, естественно, будем ждать.
Как-то так, близко к Service Broker, только доступнее:)
21 май 12, 17:54    [12590624]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
RubinDm
Member

Откуда:
Сообщений: 461
Deff
таблица 100 гигов, записи могут добавляться, изменяться, удаляться. Чужая разработка. Вам дали права только на чтение и канал на 2 мегабита. Итак ничего менять в той базе нельзя. Никакой подготовки под синхронизацию в первой базе нет. Но вы написали, что ничего и не надо. Вы сможете во второй базе легко определять изменения в первой базе и оперативно размещать их во второй базе. Итак, справитесь с задачей?

Загляните в начало - решается проблема триггера AFTER INSERT. Это означает, что мы НЕ решаем сейчас вопросы синхронизации результатов команд update и delete - это сильно упрощает задачу синхронизации, ибо найти новые записи на первом сервере совсем не так сложно, как найти изменившиеся или удаленные. Что касается оперативной синхронизации.. о какой оперативности может идти речь, если второй сервер имеет свойство выбывать из зоны уверенного приема? Значит речь идет скорее о синхронизации "по требованию" со стороны второго сервера, когда тот все-таки присутствует и может синхронизироваться. Оперативность, кстати, может быть в той или иной степени удовлетворена повышением частоты "требований" синхронизации со стороны второго сервера.

Что касается Вашей задачи - это совсем другой случай, требующий иных решений.
21 май 12, 18:18    [12590704]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
RubinDm
Member

Откуда:
Сообщений: 461
defragmentator
Делайте очередь, пусть триггер в неё пишет команды, которые нужно выполнить на другом сервере.
Запускаете job и поехали. Если связи нет, тогда, естественно, будем ждать.
Как-то так, близко к Service Broker, только доступнее:)


что делать с исполненными командами? удалять? кто должен удалять исполненные команды синхронизации?
если синхронизируемых серверов будет N-штук (где N > 1), то надо делать по команде для каждого сервера?
Как быть если кол-во серверов неизвестно заранее и может меняться в любую сторону?
Какого вида команду предлагается писать в очередь? Что-то типа insert'а одной строки?
А если это был пакетный insert сразу 10-ти строк, то в очередь попадут десять команд синхронизации?
21 май 12, 18:25    [12590743]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
Deff
Member

Откуда: Пермь
Сообщений: 18328
RubinDm
Deff
таблица 100 гигов, записи могут добавляться, изменяться, удаляться. Чужая разработка. Вам дали права только на чтение и канал на 2 мегабита. Итак ничего менять в той базе нельзя. Никакой подготовки под синхронизацию в первой базе нет. Но вы написали, что ничего и не надо. Вы сможете во второй базе легко определять изменения в первой базе и оперативно размещать их во второй базе. Итак, справитесь с задачей?

Загляните в начало - решается проблема триггера AFTER INSERT. Это означает, что мы НЕ решаем сейчас вопросы синхронизации результатов команд update и delete - это сильно упрощает задачу синхронизации, ибо найти новые записи на первом сервере совсем не так сложно, как найти изменившиеся или удаленные. Что касается оперативной синхронизации.. о какой оперативности может идти речь, если второй сервер имеет свойство выбывать из зоны уверенного приема? Значит речь идет скорее о синхронизации "по требованию" со стороны второго сервера, когда тот все-таки присутствует и может синхронизироваться. Оперативность, кстати, может быть в той или иной степени удовлетворена повышением частоты "требований" синхронизации со стороны второго сервера.

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

Не так вас понял.

Для данной задачи, самое просто добавить инкрементный ключ, если еще нет, и тянуть со второго сервера новые записи.
21 май 12, 18:43    [12590801]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
RubinDm
Member

Откуда:
Сообщений: 461
Deff
Для данной задачи, самое просто добавить инкрементный ключ, если еще нет, и тянуть со второго сервера новые записи.
Именно.
21 май 12, 18:48    [12590812]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
defragmentator
Member

Откуда:
Сообщений: 20504
RubinDm
defragmentator
Делайте очередь, пусть триггер в неё пишет команды, которые нужно выполнить на другом сервере.
Запускаете job и поехали. Если связи нет, тогда, естественно, будем ждать.
Как-то так, близко к Service Broker, только доступнее:)


что делать с исполненными командами? удалять? кто должен удалять исполненные команды синхронизации?
если синхронизируемых серверов будет N-штук (где N > 1), то надо делать по команде для каждого сервера?
Как быть если кол-во серверов неизвестно заранее и может меняться в любую сторону?
Какого вида команду предлагается писать в очередь? Что-то типа insert'а одной строки?
А если это был пакетный insert сразу 10-ти строк, то в очередь попадут десять команд синхронизации?


Удалять, конечно. Job их будет исполнять по очереди и удалять или помечать как исполненные. Всего-то ещё одно поле типа bit.
Ну а если серверов N штук, то N полей соответственно.
Если у Вас изощрённая система из неизвестного количества серверов, то нужно иметь их справочник. Ну и строите журнал работы - номер команды и номер сервера, на котором она исполнена.
Как писать команды - без разницы как. Придумайте сами, если вариантов у Вас ограниченное количество любую систему обозначений, чтобы job её понимал.
А про пакетный insert - ну если Ваш триггер его сумеет обработать, то проблем с записью в очередь такой команды не будет.
22 май 12, 10:31    [12592463]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
RubinDm
Member

Откуда:
Сообщений: 461
defragmentator
RubinDm
что делать с исполненными командами? пропущено...

Удалять, конечно. Job их будет исполнять по очереди и удалять или помечать как исполненные. Всего-то ещё одно поле типа bit.
Ну а если серверов N штук, то N полей соответственно.
пропущено...

Теперь сравните кол-во телодвижений и поддавабельность масштабированию решения в Вашем и в моем варианте синхронизации.
22 май 12, 13:00    [12593865]     Ответить | Цитировать Сообщить модератору
 Re: Транзакции в триггерах  [new]
Gunduk
Member

Откуда: Москва-Воронеж
Сообщений: 22
Вариантов много, но только топикстартер знает критерии выбора среди них для своей задачи. Может быть у него табличка на несколько сот записей, актуальность которой в другой базе нужно поддерживать раз в сутки. А может действительно гигабайты со срочной актуальностью во множестве баз и нужны не только инсерты.

Еще вариант для т.н. "программной синхронизации": добавить поля date_add и date_edit.
22 май 12, 13:47    [12594360]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить