這是我在修改這個問題上的最新努力。但是這一次，我試圖遵循Oded在他的文章Getting good answers on StackOverflow中給出的好建議。如何確定通信鏈路故障的根本原因TCP提供程序：指定的網絡名稱不再可用？
我需要找出我怎麼能確定的根本原因以下錯誤：
Communication link failure
TCP Provider: The specified network name is no longer available
不時，我跑了一組SSIS包時看到此錯誤。
- SQL Server代理出價的
完整的錯誤消息我看到招聘
SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "TCP Provider: The specified network name is no longer available.
".
SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005.
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "Protocol error in TDS stream".
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "Communication link failure".
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "TCP Provider: An existing connection was forcibly closed by the remote host."
這是如何我已經設計了ETL過程的概述：
- 兩臺服務器
- 兩者都是虛擬機
- SSIS包的應用程序服務器
- 的SQL Server數據庫住在數據庫服務器上
我使用OLE DB連接上運行管理器從應用程序服務器上的SSIS包連接到數據庫服務器上的SQL Server數據庫。
程序包在應用程序服務器上作爲文件系統部署運行，而不是作爲數據庫服務器上的數據庫部署運行。
這樣做的主要原因是ETL與一組在數據庫服務器上找不到且無法訪問的工具集成在一起。這些工具包括適用於Salesforce的Apex Data Loader和pgAdmin III。
到目前爲止，我不能始終如一地重現此錯誤。然而，這是我觀察到：
- 未能在正常營業時間
- 未能在下班時間
對於不經常發生更頻繁地發生約在星期五早上，我在兩小時內能夠成功地在特定的軟件包上重現錯誤。
如果啓用了大數據流之前的子包調用，則在大型數據流期間發生錯誤。
如果在大數據流之前的子包調用被禁用，則在同一個大型數據流期間不會發生該錯誤。
問題中的子包回叫數據庫以檢索用於電子郵件正文的少量信息，然後發送電子郵件。
感覺可能是資源限制被超過？
也許連接限制？
我想知道我應該用什麼工具來嘗試確定錯誤的根本原因。
有關所涉及的兩個服務器技術細節如下：
SQL服務器和數據庫服務器的信息：
的Microsoft SQL Server 2008 R2（SP1） - 10.50.2500.0（X64）2011年6月17日00 ：54：03版權所有（c）Microsoft公司企業版（64位）在Windows NT 6.1（內部版本7601：Service Pack 1的）（管理程序）
SSIS信息：
微軟的Visual Studio 2008版本9.0.30729.1 SP 的Microsoft .NET Framework 3.5版SP1
Application Server的信息：
OS名稱：Microsoft的Windows Server 2008 R2標準 版本：6.1.7601 Service Pack 1個的構建7601
我有研究了錯誤信息網上，發現這些，但真的想繼續之前得到專家的見解：
How to Disable TCP Chimney, TCPIP Offload Engine (TOE) or TCP Segmentation Offload (TSO).
Using Netsh Commands to Enable or Disable TCP Chimney Offload
任何幫助表示讚賞。
感謝
UPDATE：
進一步的測試表明，這不是「一個SSIS事」作爲同樣的錯誤以同樣的速度被認爲是使用SQL Server Management Studio時。查詢的複雜性不會使錯誤更可能或更不可能。在試圖解決，我們已經嘗試一個定位點（下圖）：
#1 How to Disable TCP Chimney, TCPIP Offload Engine (TOE) or TCP Segmentation Offload (TSO).
這是我們的第一次嘗試。現在，在應用程序服務器和數據庫服務器上禁用TCP煙囪。測試表明，以相同的速率發生相同的錯誤。
那麼從哪裏走？老實說，我不確定。一個看似不錯的選擇仍然是：
應用服務器和數據庫服務器SQL Server安裝不完全匹配
應用程序服務器=的SQL Server 2008（SP1） - 10.0.2531。0（X64）
數據庫服務器= SQL Server 2008 R2的（SP1） - 10.50.2500.0（X64）
該計劃是爲了升級應用程序服務器上的SQL Server安裝。它的一擊和希望，但在這一點上，這似乎是最好的選擇。我腦中的某些東西告訴我，這可以通過修復硬件問題來解決（我的意思是修理或更換），並且可能沒有硬件和軟件配置可以做的任何事情。
但是，我仍然不確定如何去確定根本原因。我仍然想知道我應該用什麼工具來診斷根本原因。
您是否對它進行排序？ – matcheek
@matcheek感謝您的詢問。很抱歉地說，還沒有......儘管我確實嘗試了一些東西並打破了一些東西。歡迎您從我的失敗中學習。我已經用目前的狀態更新了這個問題。 –
@santiago_jon，我在我的web服務器日誌中看到了同樣的錯誤。使用ADO與SQL 2008r2交談的Python代碼。全堆棧是虛擬機，所以它不可能是硬件問題。 – Manfre