2011-01-12 104 views
3

我有多個相同的數據庫(分佈在多個服務器上),並需要將它們收集到一個單一的點做數據挖掘等多個表複製到一個表(從多個數據庫)

的想法是從每個數據庫中取出Table1,Table2,...,TableN併合並它們並將結果放入一個單獨的大數據庫中。

爲了能夠編寫查詢並知道每行來自哪個數據庫,我們將向目標表添加一列DatabaseID,描述該行來自哪裏。 編輯源表不是一個選項,它屬於一些專有軟件。我們有〜40個服務器,〜170個數據庫,需要複製〜40個表格。

現在,我們應該如何實現這個給定的,它應該是:

  • 易於安裝
  • 易於維護
  • 最好調整方便,如果數據庫架構改變
  • 可靠,記錄/如果某件事失敗,報警
  • 不難太難複製更多表格

我們研究過SSIS,但似乎我們不得不將每個表添加爲源/轉換/目的地。我猜它也會與數據庫模式緊密相關。對?

另一個選擇是使用SQL Server複製,但我看不到如何將DatabaseID列添加到每個表。它似乎只能複製數據,而不能修改它。 也許我們可以將所有數據複製到不同的數據庫中,然後在目標服務器上運行本地作業來合併這些表? 如果我們需要添加更多的表進行復制,這似乎還有很多工作要做,因爲我們必須爲每個數據庫重新分配新的出版物(手動工作?)。

最後一個選項(?)是爲我們的需要編寫自定義應用程序。更大的時間投入,但它至少會做我們想要的。

讓情況變得更糟......我們正在使用Microsoft SQL Server 2000. 我們將在6個月內升級到SQL Server 2008 R2,但我們希望該項目能夠更快實施。

讓我知道你們的想法!

UPDATE 20110721

我們結束了一個F#程序中打開到SQL Server,我們希望聚集數據庫的連接。從那裏我們查詢40個鏈接的SQL Server,以從某些表中獲取所有行(但不是所有列),並向每個表添加額外的行以表明該行來自哪個DatabaseID。 配置服務器以獲取哪些表和哪些列是文本文件配置和硬編碼值(heh:D)的組合。 這不是超快速(到目前爲止順序讀取),但它絕對可管理,我們後來做的數據處理需要更長的時間。

未來的改進可能是;

  • 如果事實證明是一個問題(如果服務器不在線等),則改善錯誤處理。
  • 執行並行讀取,以減少完成讀取的總時間。
  • 找出它是否足以只提取一些行,例如只添加/更新。

總而言之,它變得非常簡單,對其他產品沒有依賴性,並且在實踐中運行良好。

回答

4

沒有什麼幻想,但不能你做類似

DROP TABLE dbo.Merged 

INSERT INTO dbo.Merged 
SELECT [DatabaseID] = "Database1", * FROM ServerA.dbo.Table 
UNION ALL SELECT [DatabaseID] = "Database2", * FROM ServerB.dbo.Table 
... 
UNION ALL SELECT [DatabaseID] = "DatabaseX", * FROM ServerX.dbo.Table 

優勢

  • 易於安裝
  • 易於維護
  • 易於調整
  • 易於添加更多表

缺點

  • 性能
  • 可靠記錄
+0

值得一試!我擔心的是可靠性,並從「一般網絡錯誤」中恢復過來。但是,如果我們無法可靠地開展工作,就很容易嘗試放棄工作。謝謝! – 2011-01-12 14:37:06

0

我們有,我們採取不同的方法類似的要求。首先創建了一箇中央數據庫來收集數據。然後我們創建了一個庫存表來存儲目標服務器/數據庫的列表。然後是一個基於vb.net的小型CLR過程,它採用SQL查詢的路徑,目標SQL實例名稱和將存儲數據的目標表(這將消除添加新目標時鏈接服務器的設置)。這也爲結果集增加了兩列。目標服務器名稱和捕獲數據時的時間戳。

然後我們建立一個服務代理隊列/服務,並推送目標服務器列表進行intergate。

上面的CLR過程被包裝在另一個消除隊列的過程中,在提供的目標服務器上執行SQL。包裝程序然後配置爲隊列的激活過程。

有了這個,我們能夠實現一些並行性來捕獲數據。

優點:

  • 易於安裝易於管理(添加/刪除目標)
  • 相同的框架適用於多個查詢
  • 記錄表來檢查失敗的查詢。
  • 獨立於每個目標工作,所以如果其中一個目標未能對 作出響應,其他人仍會繼續。
  • 通過禁用隊列(中央服務器上的 維護),然後恢復集合 重新啓用它,可以優雅地暫停工作流。

缺點:

  • 需要服務的經紀人很好的理解。
  • 應正確處理有毒消息。

請讓我知道這是否有助於

相關問題