Oracle Bind查詢速度很慢

Question

我有一個Oracle綁定查詢，當它在我的C＃程序中執行時非常慢（大約2分鐘），但在SQL Developer中運行得非常快。它有兩個參數打表的索引：

select t.Field1, t.Field2 
from theTable t 
where t.key1=:key1 
    and t.key2=:key2 

另外，如果我刪除了綁定變量，創建動態SQL，它運行就像它在SQL Developer中。

有什麼建議嗎？

順便說一下，我正在使用ODP。

Answer 1

參數綁定到C＃中正確的數據類型？列key1和key2數字，但參數:key1和:key2是字符串？如果是這樣，查詢可能會返回正確的結果，但需要隱式轉換。這種隱式轉換就像使用一個函數to_char(key1)，這可以防止使用索引。

Answer 2

還請檢查查詢返回的行數是多少。如果這個數字很大，那麼C＃可能會獲取所有行，而另一個工具只能是第一個口袋。在這種情況下，獲取所有行可能需要更多的磁盤讀取，這比較慢。要檢查這個嘗試在SQL Developer中運行：

SELECT COUNT(*) FROM (
    select t.Field1, t.Field2 
     from theTable t 
    where t.key1=:key1 
     and t.key2=:key2 
) 

上面的查詢應該獲取數據庫塊的最大數量。

這種情況下的好工具是tkprof實用程序，它顯示了SQL執行計劃，在上述情況下可能會有所不同（但它不應該是這樣）。

也可能是您意外連接到不同的數據庫。在這種情況下，比較查詢結果是很好的。

由於您提出「綁定速度慢」，我假設您已經檢查了SQL，沒有綁定，速度很快。在99％的使用綁定使事情變得更好。請檢查具有常量的查詢是否會運行得很快。如果是，則問題可能是key1或key2列的隱式轉換（例如，t.key1是一個數字，並且：key1是一個字符串）。

Answer 3

如果您在sql developer中用靜態變量替換綁定變量，那麼您並不真正運行相同的測試。確保你使用綁定變量，並且如果速度太慢，你只是由於一個糟糕的緩存執行計劃而陷入困境。更新該表上的統計數據應該解決它。

但是，如果您實際上在SQL開發人員中使用綁定變量，請繼續閱讀。 TLDR版本是ODP.net運行的參數有時會導致稍微更悲觀的方法。從更新統計開始，但讓你的dba在兩種情況下捕捉執行計劃並進行比較以確認。

我從這裏重新發布我的回答：https://stackoverflow.com/a/14712992/852208 我認爲你標記爲重複的，但你的標題是有點更簡潔，因爲它識別查詢並在SQL Developer中跑得快。我會以另一種方式歡迎處理意見。

將以下內容添加到您的配置將發送odp。網絡追蹤信息記錄到日誌文件：

這可能只會是有益的，如果你能及時發現有很大的差距。實際上，行正在進入，只是速度較慢。

嘗試在連接字符串中添加「enlist = false」。我不認爲這是一個解決方案，因爲它會有效地禁用分佈式事務，但它應該可以幫助您隔離問題。您可以從Oracle forumns後得到一點點信息：

從ODP角度來看，所有我們真的可以指出的是，當OCI_ATR_EXTERNAL_NAME和OCI_ATR_INTERNAL_NAME 是底層的OCI連接上設置發生 行爲（當 distrib tx support啓用時會發生什麼情況）。

我猜你沒有看到的是，該執行計劃實際上是不同的odp.net調用和SQL Developer的通話之間（指實際的性能損失實際上是存在的服務器上）。讓dba跟蹤連接，並從odp.net調用和直接從SQL Developer調用（或使用enlist = false參數）獲取執行計劃。

如果您確認不同的執行計劃或者您想在黑暗中搶先拍攝，請更新相關表格的統計數據。在我的情況下，這糾正了這個問題，表明執行計劃生成並不真正遵循不同類型連接的不同規則，但是在涉及分佈式事務時，成本分析只是略微更加輕鬆。查詢提示以強制執行計劃也是一種選擇，但僅作爲最後的手段。

最後，它可能是一個網絡問題。如果您的odp.net安裝使用新的oracle主目錄（除非您進行了一些安裝後配置，否則我會期待），那麼tnsnames.ora可能會有所不同。 tnsnams中的主機名可能不完全合格，從而導致解決服務器更多延遲。我只希望在這種情況下第一次嘗試（而不是後續的嘗試）速度緩慢，所以我不認爲這是問題，但我認爲應該提及。