Выбор транспорта для интеграции (Oracle + SQL Server)

Question

У нас есть несколько систем с базами данных Oracle (A) и SQL Server (B) на сервере. Я должен консолидировать данные из этих систем в новую базу данных SQL Server.

Нечто подобное:

(A) =>|---------------| 
     | some software | => SQL Server 
(B) =>|---------------| 

где некоторое программное обеспечение является:

• транспорт (системы А и В, расположенных в сети)

• обработки бизнес-логики (пользовательские .NET)

Из-за первого пункта мне нужно некоторое программное обеспечение для очереди или что-то подобное (например, MSMQ, Service Broker или что-то еще). В другой руке я могу реализовать веб-сервис вместо очереди.

(A) =>|---------------|-------------| 
     | queue/service | custom code | => SQL Server 
(B) =>|---------------|-------------| 

Вопрос заключается в том: какая очередь/транспортная структура следует использовать с базами данных Oracle и SQL Server?

Было бы хорошо, если я могу отправлять сообщения в MSMQ в обеих процедурах Oracle и SQL Server хранятся (я могу?)

Было бы хорошо, если я могу назвать веб-сервис в обоих Oracle и хранимые процедуры SQL Server (можно?)

было бы хорошо, если я могу использовать что-то подобное в обеих процедурах Oracle и SQL Server хранится (что именно?)

какое программное обеспечение я должен предпочесть мой требования?

UPD: некоторые ТехСпец

Это будет обычный процесс синхронизации. Один раз в день я думаю.

Задержка не является критичной (> 0,5-1 час в порядке).

Количество данных: 1-50 МБ на синхронизацию каждой системы.

Шифрование требуется при передаче.

Answer 1

Я бы предложил создать пакет SSIS, который передает новые данные с сервера A, B на новый сервер при вызове. Вы должны запустить пакет SSIS по расписанию, скажем, каждые 30 минут, с нового сервера.

Если оба A и B будут SQL Server, то Service Broker имеет смысл, чтобы обеспечить очень низкую задержку. Но с одним из них, являющимся Oracle, и без требований в реальном времени, он теряет свою привлекательность. В качестве дополнительной заметки вы можете увидеть здесь пример использования Service Broker для High volume real time contiguous ETL.

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

Я бы посоветовал против использования MSMQ по нескольким причинам:

• при транзакционной надежности необходима вам придется задействовать все связанные MSMQ операции в распределенной транзакции (DTC между DEQUEUE MSSMQ и вставки SQL сервера/обновление на новом сервере), что значительно замедлит производительность обработки.
• Вам нужно будет создать довольно много строк кода для маршалинга/размаширования и измельчения сообщений дельтаграммы в целевой системе (я знаю, что codding весело, но SSIS просто лучше подходит для такого рода работ и проще в обслуживании)
• MSMQ ограничение 2 Гб в очереди довольно мал в реальном мире (заполняется быстро, если ваши движения увеличивается, и у вас есть время простоя обслуживания)

Реальная проблема, которую я бы беспокоиться о том, как обнаружить изменения на A и B: когда работа SSIS приходит каждые 30 минут, как она узнает, какие данные новые? Специально, как он обнаруживает удаления ...