2017-08-11 61 views
0

我正在構建一個SSIS軟件包以將數據從BMC Remedy數據庫(通過AR系統ODBC驅動程序)提取到我的SQL Server數據庫中的表中。請注意,處理此數據源時存在一些特殊的限制。ssis dt_text列導致軟件包掛起

我遇到的問題是我需要拉入的一列顯示爲dt_ntext(Unicode文本流)。該字段的數據類型(在TOAD中查看時)是「longvarchar」。該字段可以包含數千個字符的字符串。

只要省略這一列,我可以將所有其他字段導入到我的SQL Server表中。如果我包括這個,那麼包無限期地掛起(在BIDS和在服務器上的生產中)。我已經讓它運行了超過12個小時,並且從未取得任何進展。沒有這一列,它需要一分鐘。在BIDS中,我可以看到它掛在數據流任務的「源」步驟上,「執行階段開始」。它掛在那裏,不管目的地是什麼(相同的結果轉儲到文本文件)。

我不需要來自該字段的所有數據。前200個字符實際上就足夠了。但是,我沒有選擇更改我的源SQL語句,因爲沒有函數(即子字符串)允許(上述限制之一)。我試着在源文件上打開高級編輯器,並將該列的輸出屬性更改爲長度爲200的Unicode字符串。它不會導致錯誤,但結果是相同的(掛起)。我認爲這意味着數據仍然需要「引入」,然後截斷爲200,這對我沒有好處。

數據不是那麼大......我可以在TOAD中運行查詢,並在一分鐘內返回所有行,而不會冒煙從我的機器中流出。因此,我覺得這是某種SSIS優化問題。

我看到它的方式,我需要兩件事情之一。 1)在數據進入內存之前截斷數據(在我的SELECT語句中不這樣做),或者2)對我的包進行一些配置更改(緩衝區大小/行?),以便它可以運行在合理的數量的時間。我不知道如何實現這些。任何指導將不勝感激。

感謝, 埃裏克

+0

是否有可能用腳本任務替換源代碼?通過代碼接近領域可能會讓您更好地控制發生的事情。 – Greenspark

+0

如,在代碼中創建一個記錄集,然後遍歷並將每個追加到我的數據庫?這可能會奏效,但不知道效率如何。我會調查.. –

+0

沒有太多的運氣與此。我循環遍歷記錄集,並且當我到達特定行中有問題的字段(Work_Log)時,任何嘗試讀取數據都會導致代碼掛起。例如: strTemp = Mid(dr(「Work_Log」),1,100) –

回答

1

最後,我不是能夠在Visual Studio/BIDS二千零十二分之二千零八設計師之內解決這個問題。但是,我們正在遷移到SQL 2016.作爲該過程的一部分,我們安裝了具有「ODBC源」對象(與之前可用的ADO Net源相對)的SSDT 2015。一旦我切換到ADO Net Source,長列不再導致程序包掛起。

但值得注意的是,我在我的數據流中使用數據轉換步驟將文本unicode文本流轉換爲字符串。我還截斷了數據轉換的輸出,如下所示:右鍵單擊數據轉換步驟,選擇「高級編輯器」,轉到輸入和輸出屬性,轉到數據轉換輸出 - >輸出列 - >複製Work_Log( Work_Log是我有問題的列名稱),將TruncationRowDisposition更改爲RD_IgnoreFailure,將DataType更改爲字符串[DT_STR]並將Length更改爲500.然後將Data Conversion步驟連接到輸出並使用「Copy of」列,而不是原始列。我不是100%確定截斷是否有必要避免我得到的錯誤,但是我的目的地已經只設置了500個字符,就像我的情況一樣,我知道我需要的數據將在頭幾百個字符內,但認爲無論如何都值得一提。

我還注意到一些有趣的事情。我的ODBC源任務顯示一個感嘆號(警告)。當我把鼠標懸停在它上面時,我看到警告:「Row by fetch方法被執行,因爲表中有LOB列,Column Work_Log是LOB。我在2008/2012年的設計師中沒有看到這個(或任何類似的東西),所以顯然新的ODBC源代碼足夠聰明,可以更寬鬆地處理寬列(Row by Row?)。我不確定在這種模式下運行是否存在負面/性能成本,但在我的情況下它運行良好。