[SQL][Troubleshooting]SSIS 無法連線
這一陣子手邊都是講課和問題處理的行程，導致沒有時間好好來整理一下 Blog 的資料，趁著今天剛好因為颱風假停止上班，讓我有一點時間來整理一下這兩個月遇到的問題，跟大家分享一下處理經驗。
這幾個案例都很類似，都是在執行 SSIS 的 Package 的時候，會不定時出現有錯誤訊息，但是當我們利用同樣的資料單獨對有問題的 Package 再重新測試，卻都是正常的。
而我們查看每次的錯誤資訊，發現每次錯誤的訊息都是類似下面這樣，並不是在 Package 處理中發生異常，都是無法連線的狀況：
Executed as user: BIDB\SYSTEM. ...ersion 9.00.5000.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 下午 11:51:36 Error: 2013-07-15 23:53:05.90 Code: 0x00000000 Source: U_d_source_dim DSCExecutePackageTask:U_d_source_dim Description: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005. An OLE DB record is available. Source: "Microsoft SQL Native Client" Hresult: 0x80004005 Description: "Unable to complete login process due to delay in opening server connection". End Error Error: 2013-07-15 23:53:05.90 Code: 0x00000000 Source: U_d_source_dim DSCExecutePackageTask:U_d_source_dim Description: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "edw" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection m... The package execution fa... The step failed.
而再仔細觀長這樣的情況，發現多半都是在會當 Job 裡面，他有多個 Package 要執行的時候，放在中間執行的幾個 Package 才會有問題，但要是只單獨跑這個 Package 的時候就不會有錯。從這些線索看起來，初步推斷應該不是某一個 Package 所發生問題，有可能是前面 Package 可能做了一些大量處理，導致 SQL Server 過於忙碌，使得在後面要接著做的 Package ，當要連接 SQL Server 的時候發生無法連線，才會發生錯誤。但到底是甚麼讓 SQL Server 忙碌到沒有辦法回應，這樣的狀況實在很令我好奇。
為了要釐清這個問題，因此我請想關人員協助先將 SQL Server 的 Errorlog 檔案給取回，想先從這裡來看有沒有任何蛛絲馬跡的線索，如果沒有的話再來使用 Perfmon 來做監控。結果很幸運的是在當我們對照發生錯誤的時間，意外的發現似乎在每次在 "連續" 執行封裝之後，都會在 SQL Server 的 Error Log 中有看到類似以下的訊息
而這樣的訊息看起看來應該是資料庫所在的磁碟 I/O 沒有辦法解決大量的寫入需求，因此我們將問題的矛頭指向是是磁碟上的寫入效能不佳，懷疑是導致在封裝執行時有大量寫入資料的處理之後，可能 SQL Server 發生 Checkpoint 需要將 Log 內的資料寫入 MDF 內，此時 SQL Server 等待 I/O 的處理造成 CPU 過忙，導致後續的 Package 連接 SQL Server 時候才發生沒有回應造成錯誤。
如果按照我們的推斷，那要怎麼來測試 I/O 是否真的有瓶頸呢，一般書上都是建議採用 SQLIO ( 可參考德瑞克老師的文章 )，但我個人比較懶惰一點，因為 SQLIO 還要下指令，因此就偷懶一點請服務人員直接用 CrystalDiskMark 這套工具來測試，測試出來的結果如下：
只是這樣的數據是好還是不好呢 ? 我提供幾個範例給大家參考看看，下面這個是在 8 顆硬碟在 RAID 5 上且有配合 Write Cahce 的狀況
而下面這個是一般 SATA II 的普通 PC 用硬碟。
所以綜合這兩種狀況，因此在一般狀況下大部分的主機 I/O 效能大概都會介於這兩者之間，而在第一個的狀況，就明顯不在這個範圍內。因此我們就可以比較清楚有問題的應該是儲存設備上，而在最近所遇到的這幾個問題，設備寫入速度會特別慢的通常有幾種：
1. 利用 iSCSI 連接 NAS 上的 LUN 來使用，但網路瓶寬受限。
2. 同時間 Storage 太過於忙碌，導致效能不佳
3. RAID 卡上面沒有電池，導致無法開啟 Write Cache
因此在跟客戶確認可能是相關設備上有異常，並請負責廠商排除上述這些問題之後，問題果然就順利解決了。