集成傳輸選擇（Oracle + SQL Server）

Question

我們有幾個系統，在後端有Oracle（A）和SQL Server（B）數據庫。我必須將這些系統中的數據整合到新的SQL Server數據庫中。

類似的東西：

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

其中一些軟件是：

• 傳輸（位於網絡中的A和B系統）

• 處理業務邏輯（自定義.NET代碼）

由於第一點，我需要一些隊列軟件或類似的東西（如MSMQ，Service Broker或其他）。另一方面，我可以實現一個Web服務而不是隊列。

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

問題是：我應該在Oracle和SQL Server數據庫中使用哪個隊列/傳輸框架？

這將是很好，如果我可以張貼在Oracle和SQL Server存儲過程消息MSMQ（可以嗎？）

這將是很好，如果我可以調用在Oracle web服務和SQL Server存儲過程（可以嗎？）

這將是很好，如果我能使用的東西在Oracle和SQL Server存儲過程類似（究竟是什麼？）

我應該喜歡什麼軟件我要求？

UPD：一些TECHSPEC

這將是一個常規的同步過程。我想每天一次。

延遲並不重要（> 0.5-1小時可以）。

數據量：每個系統同步1-50 MB。

傳輸時需要加密。

Answer 1

我會建議創建一個SSIS包，在調用時將新數據從服務器A，B傳輸到新服務器。您可以按照每30分鐘從新服務器上安排的時間表啓動SSIS包。

如果A和B都是SQL Server，那麼Service Broker會有意義，以便提供非常低的延遲。但是其中一人是甲骨文，並沒有實時要求，因此失去了吸引力。作爲一個附註，你可以在這裏看到使用Service Broker的例子High volume real time contiguous ETL。

以SSIS包的方式進行傳輸可以方便維護（您可以相對容易地修改包），它不需要對現有系統進行侵入式更改，性能相當高，並且有大量的SSIS知道 - 如何在網上提供。

我會建議不要使用MSMQ有以下幾個原因：

• 時，需要交易的可靠性，你必須所有MSMQ相關的操作涉及到分佈式事務MSSMQ出隊和SQL服務器插件之間（DTC /在新的服務器上更新），這將減緩處理吞吐量顯着
• 你需要拿出相當幾行代碼進行編組/解組，並將δgram消息切碎到目標系統中（我知道codding是有趣，但是SSIS在這類工作上更好，並且更容易維護）
每個隊列2GB的
• MSMQ的限制是相當小的現實世界（填滿很快，如果你的流量的增加，你有一個停機維護時間）

真正的問題，我會擔心的是如何在發現變化A和B：當SSIS工作每30分鐘一次時，它如何知道哪些數據是新的？特別是，它如何檢測刪除...