[英]JDBC connection to very busy SQL 2000: selectMethod=cursor vs selectMethod=direct?
在嘗試幫助應用開發團隊在SQL 2000服務器(來自單獨的應用服務器上的一堆Java應用程序)上遇到性能問題的過程中,我運行了一條SQL跟蹤並發現所有對數據庫的調用都充滿了API Server Cursor語句(sp_cursorprepexec,sp_cursorfetch,sp_cursorclose)。
看起來他們正在指定一些強制使用服務器端游標的連接字符串屬性,一次只檢索128行數據:(來自http://msdn.microsoft.com/en-us/library/Aa172588 )
當API游標屬性或屬性設置為默認值以外的任何值時,SQL Server的OLE DB提供程序和SQL Server ODBC驅動程序使用API服務器游標而不是默認結果集。 每次調用獲取行的API函數都會生成到服務器的往返,以從API服務器游標中獲取行。
更新 :有爭議的連接字符串是JDBC連接字符串參數, selectMethod=cursor
(它啟用我們上面討論的服務器端游標)與替代selectMethod=direct
。 他們一直使用selectMethod=cursor
作為所有應用程序的標准連接字符串。
從我的DBA角度來看,這只是令人討厭(它使用無用的垃圾混亂了跟蹤),並且(我推測)導致許多額外的app-to-SQL服務器往返,降低了整體性能。
他們顯然做了測試更改(只有60個不同的應用程序連接中的一個)來selectMethod=direct
但遇到了一些問題(我沒有詳細說明)並關注應用程序中斷。
所以,我的問題是:
selectMethod=cursor
降低應用程序性能,正如我試圖爭論的那樣? (通過增加已經具有非常高的查詢/秒的SQL服務器上所需的往返次數) selectMethod=
JDBC連接上的應用程序透明設置嗎? 如果我們改變它,這會打破他們的應用嗎? cursor
vs direct
? 也交叉發布到SF 。
編輯 :收到實際技術細節,保證對標題,問題和標簽進行重大編輯。
編輯 :添加賞金。 還為SF問題添加了賞金(這個問題主要集中在應用程序行為上,SF問題主要集中在SQL性能上。)謝謝!!
簡單地說,
selectMethod=cursor
selectMethod=direct
更多的服務器端資源 selectMethod=direct
selectMethod=cursor
需要更少的服務器端資源 direct
它已經支付了檢索數據的成本,它將基本上丟棄;使用cursor
廢物限制在最多批量大小 - 1行 - 提前終止條件可能應該在SQL中重新編碼,例如SELECT TOP
或window函數) 綜上所述,
selectMethod=cursor
降低應用程序性能嗎? - 由於不同的原因,任何一種方法都會降低性能。 超過某個結果集大小, cursor
可能仍然是優選的。 請參閱下文,了解何時使用其中一個 selectMethod=
JDBC連接上的應用程序透明設置嗎? - 它是透明的,但是如果內存使用量增長到足以占用他們的客戶端系統(相應地,你的服務器)或者完全崩潰客戶端,它仍然會破壞他們的應用程序 cursor
vs direct
? - 我個人在處理可能很大或無限制的結果集時使用cursor
。 然后,給定足夠大的批量大小,可以分攤往返開銷,並且我的客戶端內存占用量是可預測的。 當我所期望的結果集的大小已知不如我用於cursor
任何批量大小,或以某種方式綁定,或者當內存不是問題時,我使用direct
。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.