JDBC连接到非常繁忙的SQL 2000:selectMethod = cursor vs selectMethod = direct？

Question

在尝试帮助应用开发团队在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连接上是应用程序透明设置吗？如果我们改变它,这会打破他们的应用吗？
• 更一般地说,什么时候应该使用cursorvs direct？

也交叉发布到SF.

编辑:收到实际技术细节,保证对标题,问题和标签进行重大编辑.

编辑:添加赏金.还为SF问题添加了赏金(这个问题主要集中在应用程序行为上,SF问题主要集中在SQL性能上.)谢谢!!

Answer 1

简单地说,

1. selectMethod=cursor
   • 理论上需要更多服务器端的资源比selectMethod=direct
   • 只能将大多数批量大小的记录一次加载到客户端内存中,从而产生更可预测的客户端内存占用量
2. selectMethod=direct
   • 理论上需要的服务器端资源少于 selectMethod=cursor
   • 将客户端应用程序迭代之前,将整个结果集读入客户端内存(除非驱动程序本身支持异步结果集检索); 这可以通过两种方式降低性能:
     1. 如果客户端应用程序的编写方式是在遍历结果集的一小部分之后停止处理(因为direct它已经支付了检索数据的成本,它将基本上丢弃; cursor浪费是限制为最多批量大小 - 1行 - 提前终止条件可能应该在SQL中重新编码,例如as SELECT TOP或window函数)
     2. 由于可能的垃圾收集和/或与内存占用增加相关的内存不足问题导致大型结果集的性能降低

综上所述,

• 可以使用selectMethod=cursor较低的应用性能？ - 由于不同的原因,任何一种方法都会降低性能.cursor超过一定的结果集大小,可能仍然是优选的.请参阅下文,了解何时使用其中一个
• selectMethod=JDBC连接上是应用程序透明设置吗？ - 它是透明的,但是如果内存使用量增长到足以占用他们的客户端系统(相应地,你的服务器)或者完全崩溃客户端,它仍然会破坏他们的应用程序
• 更一般地说,什么时候应该使用cursorvs direct？- 我个人cursor在处理潜在的大型或其他无限结果集时使用.然后,给定足够大的批量大小,可以分摊往返开销,并且我的客户端内存占用量是可预测的.我direct知道,我所期望的结果集的大小不如我使用的任何批量大小cursor,或以某种方式绑定,或者当内存不是问题时使用.