永無止境的 OLEDB 等待連結伺服器
我們創建了一個連結伺服器來將 SQL Server 連接到我們的 ERP（執行 UniVerse 而不是 SQL Server）。過去它工作得很好，但現在對連結伺服器的任何查詢都會被 OLEDB 等待類型卡住（幾天）。
以前很少發生這種情況，重新啟動 SQL Server 始終可以解決該問題。但是，現在重新啟動伺服器要麼不能解決問題，要麼最多可以修復一兩個小時。
我們在 SQL Server 2016 和 2008 R2 中都遇到了這個問題。
我們可以使用與 SQL Server 相同的驅動程序在同一伺服器上使用其他工具查詢數據源。在一台伺服器上，我們正在執行 SQL Server 2008 R2 的兩個實例。一個能夠查詢數據源，而另一個則被 OLEDB 等待類型卡住。兩者上的連結伺服器的設置方式完全相同，並且它們使用相同的驅動程序。
我們嘗試過：
- 重新啟動 SQL Server
- 重新啟動數據源所在的伺服器
- 不同的驅動程序
- 重新創建連結伺服器
- 使用相同驅動使用不同工具查詢數據源（成功）
- 我們能夠從受影響的 SQL Server 的伺服器 ping 數據源伺服器
- 我們能夠使用 Telnet 從受影響的伺服器連接到數據源
對於 SQL Server 目標： 在目標伺服器（接收連結伺服器查詢的伺服器）上，執行sp_WhoIsActive並查看連結伺服器查詢。
如果查詢未顯示，則連結伺服器查詢出現問題，並且永遠無法到達目的地。
如果確實出現了，請查看等待列，看看等待類型是什麼。（它不會是 OLEDB。）這將幫助您解決它未完成的原因。請隨意將其與您的問題一起發布，我可以詳細說明該特定等待類型。
對於本例中的 IBM/Rocket 等非 SQL Server 目標：您將希望在該平台上與 sysadmin/DBA 合作，並讓他們檢查查詢的進度。當您在 SQL Server 發送端看到 OLEDB 時，您無法知道另一端的阻塞是什麼。
我們在這裡遇到了類似的問題。我們在伺服器上有一個儲存過程呼叫伺服器上的另一個儲存過程，並且在性能方面存在不同的問題。我們在目標伺服器上執行了 sp_WhoIsActive，沒有出現等待類型。然後我們添加了“SET ARITHABORT ON;” 在目標伺服器儲存過程中，這以某種方式解決了這個問題。似乎是因為參數嗅探。更多細節在這裡。主要是這塊……”您的應用程序連接 ARITHABORT OFF，但是當您在 SSMS 中執行查詢時，ARITHABORT 是 ON，因此您不會重用應用程序使用的記憶體條目，但 SQL Server 將重新編譯該過程，嗅探您目前的參數值，您可能會得到與應用程序不同的計劃“。