Profiler显示我的服务器因sp_cursorfetch的大量调用而过载,但我想知道哪些查询导致了所有这些流量。
答案 0 :(得分:3)
在这种情况下,Profiler不起作用。
我跑了一个来测试它,然后查询我用它创建的表:
选择CPU,TextData FROM cpu,其中LoginName ='db_name_here'按CPU desc排序
//确保替换db_name_here
结果我得到了这样的东西:
CPU----TextData-----------------------------
0------exec sp_cursorfetch 180150000, 16, 7415, 1
*注意:上面的“ - ”只是为了格式化它,所以它在这个网站上实际上是可读的。
======
我在此找到的唯一答案是:
选择语句是这些游标提取的唯一原因,检查最常用表的索引是解决问题的良好开端
您可以在cursorfetch调用的SPID上过滤跟踪,以查看在运行sp_cursorfetch之前和之后它正在执行的操作。
仅获取当前总RecordSet的子集。说你现在抓100行。只抓10,因为10是用户在任何给定时间都能看到的最多。
答案 1 :(得分:1)
回应评论:
Thanks for your suggestions, all of which are helpful. Unfortunately the queries in question are from a third party application, of which I do not have direct access to view or modify the queries. If I find a query that is a particuar problem, I can submit a support request to have it reviewed. I just need to know what the query is, first. – Shandy Apr 21 at 8:17
您无需访问该应用程序即可试用我提到的大多数建议。让我们来看看:
选择语句是这些游标提取的唯一原因,检查最常用表的索引是解决问题的良好开端
您可以在cursorfetch调用的SPID上过滤跟踪,以查看在运行sp_cursorfetch之前和之后的操作。
仅获取当前总RecordSet的子集。说你现在抓100行。只抓10,因为10是用户在任何给定时间都能看到的最多。
您运行的SQL Server版本是什么?在我的情况下,解决方案最终成为SQL Server 2008的升级。我会尝试看看它的位置。
由于您无权访问该应用程序,因此最有可能解决游标使用问题。如果您查看http://sqlpractices.wordpress.com/2008/01/11/performance-tuning-sql-server-cursors/,您会发现大多数备选项都涉及编辑运行的应用程序查询。
真正的问题是什么?你为什么要分析数据库?
答案 2 :(得分:0)