在尝试帮助一个应用程序开发团队解决 SQL 2000 服务器上的性能问题(来自不同应用程序服务器上的一堆 Java 应用程序)的过程中,我运行了 SQL 跟踪并发现对数据库的所有调用都充满了 API服务器游标语句(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 的角度来看,这很烦人(它用无用的垃圾使跟踪变得混乱),并且(我推测)会导致许多额外的应用程序到 SQL 服务器往返,从而降低整体性能。
他们显然确实测试了更改(只是大约 60 个不同的应用程序连接之一),selectMethod=direct
但遇到了一些问题(我没有详细信息),并且担心应用程序会中断。
所以,我的问题是:
selectMethod=cursor
正如我试图争论的那样,可以使用较低的应用程序性能吗?(通过增加已经有非常高的查询/秒的 SQL 服务器上所需的往返次数)selectMethod=
JDBC 连接上的应用程序透明设置吗?如果我们改变它,这会破坏他们的应用程序吗?- 更一般地说,什么时候应该使用
cursor
vsdirect
?
还交叉发布到 SF。
编辑:收到实际的技术细节,需要对标题、问题和标签进行重大编辑。
编辑:增加赏金。还为 SF 问题添加了赏金(此问题侧重于应用程序行为,SF 问题侧重于 SQL 性能。)谢谢!