如何從遠程系統複製和驗證數據到SQL Server中

Question

我有一個任務可以爲數據庫創建某種邏輯。今天有一個IBM MQ系列設置可以複製來自幾個遠程系統的數據。目前它在遠程系統中發生變化，並將數據轉儲到SQL Server 2005數據庫中的登臺表中。

我想驗證數據根據一些簡單的驗證邏輯（必填字段和數據格式）和一些更高級的數據層次結構的檢查。被導入的數據是分層的，其中一些數據之間存在父子關係。分層驗證應檢查登臺表和生產表中當前可用的數據，以確保導入完成後將有一個有效的層次結構。

如果記錄驗證失敗，應以某種方式記錄失敗，並且不應導入失敗的記錄，但其餘記錄應該。如果當前生產表中的記錄具有相同的ID，則應該用新記錄替換。在數據出現在登臺表中之後，應儘快進行登臺表中的數據傳輸。

據我所知，生產表中的記錄總數不會超過100萬，每批更新的物品的可能數量最多爲幾千行。

我的問題是什麼解決方案最適合導入數據？

我想到了幾個可能的解決方案：

開始傳輸的

方式：

• Windows服務輪詢每隔一定的時間 的 臨時表，並揭開序幕某種轉移當插入新數據 時， 處理。
  ：
  • 在插入新的數據到 表
  • 調度的SSIS工作，每隔一定的時間驗證和轉移數據的

  方式運行充分利用MQ開球轉移過程

• 創建一個SSIS作業
• 創建存儲過程
• 自定義.NET代碼

我的主要問題是，層次結構必須始終在生產表中始終保持完整，並且數據應該在臨時表中出現後不久才能在生產表中使用。我無法確定在臨時表中始終可以使用完整的層次結構。

Answer 1

我們對這類工作使用了一個封閉的流程。

從遠程系統獲取數據到暫存表，導入到產品表中。

如果有什麼事情可以插入隨意分期表，有子表，再有就是，你可能導入生產DB在臨時表中創建所有的子記錄之前的風險。

如果您可以自由將列添加到Staging Tables（遠程端將忽略），或者如果登臺表具有唯一/不重複的IDENTITY或GUID，則可以創建一個並行表。

理想情況下，在臨時表中創建行的例程將使用批號，然後在成功時創建「批號完成」記錄。所以你有一個信號量來阻止你導入，直到所有關聯的記錄都在。

（它們可以被插入到一個事務塊中，但你必須確信插入到Staging Table中的所有進程都符合）。

鑑於IDENTITY/GUID，我會創建一個1：1的「錯誤表」來存儲任何描述導入失敗的消息。

您可以選擇將失敗的行移動或複製到單獨的失敗登臺表，以便主登臺表不會被阻塞，並且更容易確保排除故障（通過我假設的人類）。

說了，這裏是我們的具體過程的詳細描述：

爲了儘量減少帶寬和更新（即減少阻塞，減少不必要的事務日誌條目等）我們做了以下內容：

在源機器保存正在傳輸的表格的副本。這有更多的列更新和行動（更新或刪除標誌 - 更新包括插入和插入可能已被更新之前，目的地獲得該行...）

插入此表的新 ，行都OK

只有當至少有一列存在差異時纔會對此表進行更新 - 因此，如果將整個源表與臨時表進行比較以確定發生了什麼變化。更新設置了Updated-on列。 （小心當時鍾返回）

定期我們標記暫停表行Action =刪除，如果他們不能在源表中找到。

將數據從Source複製到Destination上的相同表中，其中Updated-on在上次傳輸之後。

在目標服務器上的數據，並將其導入檢查生產常規，專司更新上日期（過程一切自上次更新上）

所有臨時表是在一個單獨的數據庫它具有最少的日誌記錄 - 如果數據庫恢復，數據庫將自動從「上次更新的日期」進行刷新，因此我們的目標是最大限度地減少事務日誌。我們不要將臨時表存儲在生產數據庫（它將具有完整的事務日誌記錄），以避免腫脹TLogs

同樣，如果這些過程是連續的，以便它們不能同時發生，需要使用批次號來防止在存在父/子表的情況下傳輸部分完成的批次。

我們以源數據庫的樣式傳輸數據，並僅在目標端進行數據操作。原因是如果數據操作錯誤，我們修復它，我們只需要在目標端重新運行它 - 源數據全部出現在目標端的登臺表中。如果我們在源端進行了操作，我們將不得不再次重傳所有數據。

對於在Staging表中使用Updated-on date的調試很有幫助。我們經常得到「爲什麼這是不同的」，看到更新開始告訴我們目標端的操作是否有問題（即我們最近的數據顯示了預期的源數據）還是源端（沒有找到最新的數據！ ）