SQL數據加載 - 建議需要

我們正在設置一個SSIS包來加載格式化文本文件到SQL服務器。它將有大約1億行和文件大小（每個大約15 GB的多個文件）100 GB。文件格式與XML架構一致類似下面......它需要近72小時，在加載該文件到SQL Server表...

文件格式

EM | 123 | XYZ | 30 |銷售管理| 20000 |廣告| 1街1 | State | City1 | US | AD | 12Street 2 | state 2 | City2 | UK | CON | 2012689648 | CON | 42343435

EM | 113 | WYZ | 31 | Sales grade | 200 | AD | 12 Street 1 | State2 | City2 | US | AD | 1Street 22 | state 3 | City 3 | UK | CON | 201689648 | CON | 423435

EM | 143 | rYZ | 32 |銷售Egr | 2000 | AD | 113Street 1 | State3 | City3 | US | AD | 12Street 21 | state 4 | City 5 | UK | CON | 201269648 | CON | 443435

數據將以上述格式顯示。這意味着「EM」直到「AD」是員工詳細信息，如代碼，姓名，年齡，名稱，工資和「AD」是街道，州，城市，國家的詳細地址。地址數據對於同一個員工可以是多個...類似地，「CON」是具有也可以是多個的電話號碼的聯繫細節。

因此，我們需要在其他兩個表中的員工詳細信息和引用密鑰中將代碼作爲主鍵加載到單獨表中的地址詳細信息中，單獨表中的地址詳細信息和單獨表中的聯繫人詳細信息。

我們設計了一個包，像腳本組件一樣，使用.NET腳本逐行解析，併爲每個表創建多個輸出緩衝區，並在腳本中添加該行。將腳本組件輸出映射到3個OLE DB目標（SQL Server表）。

我們的服務器是四核，具有48 GB RAM虛擬化，我們有2個核心，24 GB專用於數據庫。我們的SQL服務器數據庫（簡單恢復模式）在SAN存儲的網絡共享位置中包含數據文件。爲了提高性能，我們創建了不同數據文件（主要和次要）中的每個表格，但仍需要大約72小時。

需要關於以下幾點的指導。

是否有可能使用BCP，如果是任何指針。（希望BCP將有更好的表現）
任何建議上指定的解決方案。
任何候補......

沒有在表中定義還沒有觸發指標......我們甚至已經架設defaultMaxbufferzie爲100 MB

期待着response..Any非常感謝幫助..

來源

2012-03-01 Saravanan

有什麼問題嗎？如何使這個更快？加載前是否禁用了索引？ – 2012-03-01 17:53:10

絕對檢查索引是否打開，以及是否在目標表上有一些時髦的觸發器或其他對象。 – wergeld 2012-03-01 18:10:21

第1步，扔掉你的源腳本，除非你確信你的團隊編寫的代碼比開箱即用的平面文件組件更嚴格。如果需要發送到多個目的地，請使用多播。你能澄清你的意思嗎？「在腳本中添加了這一行。」給出所提供的輸入數據可能是您的3個表的預期結果的例子將是有益的。 – billinkc 2012-03-01 19:05:12

1）如果有必要，簡化/ XSLT通過扁平化XML文件如下所示： http://blogs.msdn.com/b/mattm/archive/2007/12/15/xml-source-making-things-easier-with-xslt.aspx

2）使用XML源代碼如下所示： http://blogs.msdn.com/b/mattm/archive/2007/12/11/using-xml-source.aspx

3）刪除任何索引在目標表

4.）如果源數據是防彈，禁用經由在表上的約束：

ALTER TABLE [MyTable] NOCHECK CONSTRAINT ALL

5）通過OLEDB目標

6）加載數據重新啓用約束

7）重新創建索引

來源

2012-03-02 07:29:51

你說數據文件在網絡共享。一種改進是添加硬盤驅動器並在SQL服務器上運行作業，因爲您可以消除延遲。我想即使連接USB驅動器來讀取文件將比使用網絡位置更好。在我看來，肯定值得一試。

來源

2012-03-01 18:21:21 UnhandledExcepSean

SSIS在執行批量加載時非常快速，所以我懷疑這個瓶頸不是SSIS本身，而是關於數據庫/服務器配置的方式。幾點建議：

當你正在運行的進口，有多少行，你導入每秒（你可以導入，看看在做一個「SELECT COUNT（*）從READUNCOMMITTED yourtable」）請問這速度保持不變，還是減緩到最後導入？
正如其他人所說，你有目標表上的任何索引或觸發器？
當您運行導入時，您的磁盤是什麼樣的？在perfmon中，磁盤隊列是否瘋狂跳動，表明你的磁盤是瓶頸？正常性能測試期間，這些磁盤上的吞吐量是多少？我有過不適當配置iSCSI或不正確對齊SAN存儲的經驗，可能會將我的磁盤從400MB /秒降至15MB /秒 - 在正常使用情況下仍然很好，但速度太慢，無法進行批量操作。

你也在談論加載100GB的數據，這是不小的數量 - 它不應該花72小時加載，但它不會在20分鐘內加載它，所以有合理的期望。請權衡這些以及人們詢問的其他瓶頸，我們可能會幫助您分辨問題。

來源

2012-03-01 18:22:28 SqlRyan

如果你有過這樣的文件被創建，開始與任何控制，我會遠離你與|EM|和|AD|，|CON|的一個一對多的關係，移動，做這樣的事情：

|EM|EmpID|data|data|

|AD|EmpID|data|data|

|CON|EmpID|data|data|

而且，如果你可以分割記錄到三個不同的文件中，您將能夠使用具有固定規格的平面文件源組件來爲每個源批量處理數據。

來源

2012-03-01 21:32:51

SQL數據加載 - 建議需要

回答

相關問題