相关疑难解决方法(0)

我正在使用SQL 2005探查器进行一些测试.

我有一个存储过程,它只运行一个SQL查询.

当我运行存储过程时,它需要很长时间并执行800,000次磁盘读取.

当我对存储过程分开运行相同的查询时,它会执行14,000次磁盘读取.

我发现如果我使用OPTION(重新编译)运行相同的查询,则需要800,000次磁盘读取.

由此,我做出(可能是错误的)假设,即存储过程每次都重新编译,这就是导致问题的原因.

任何人都可以对此有所了解吗？

我已经设置了ARITHABORT.(这解决了stackoverflow上的类似问题,但没有解决我的问题)

这是整个存储过程:

CREATE PROCEDURE [dbo].[GET_IF_SETTLEMENT_ADJUSTMENT_REQUIRED]
 @Contract_ID int,
 @dt_From smalldatetime,
 @dt_To smalldatetime,
 @Last_Run_Date datetime
AS
BEGIN
 DECLARE @rv int


 SELECT @rv = (CASE WHEN EXISTS
 (
  select * from 
  view_contract_version_last_volume_update
  inner join contract_version
  on contract_version.contract_version_id = view_contract_version_last_volume_update.contract_version_id
  where contract_version.contract_id=@Contract_ID
  and volume_date >= @dt_From
  and volume_date < @dt_To
  and last_write_date > @Last_Run_Date
 )
 THEN 1 else 0 end)

 -- Note that we are RETURNING a value rather than SELECTING it.
 -- This means we …

我们正在尝试诊断复杂存储过程的缓慢(它有几个巨大的查询).

当我们从ASP.NET调用SP时,需要5秒钟.

当我们从SQL Management Studio(仅使用EXEC)调用它时,需要0.05秒.

我们已经在许多不同的方式和环境中持续测试了这种行为.

这是使用C#.NET.该数据库是MS SQL Server 2012.

问题在于网络应用程序,但我们编写了一个小型控制台应用程序作为测试工具,行为是相同的.

1)我们在C#.NET控制台应用程序中计算经过的时间,如下所示:

stopwatch.Start();
rdr = cmd.ExecuteReader();
stopwatch.Stop();

2)我们通过在查询之前和之后调用GETDATE()来计算SQL过程中的经过时间,然后将这些时间存储在一个小表中.我们可以在SQL Mgmt Studio中查询该表,以查看SP内部的查询所花费的时间.

通过这种方式,我们可以看到SQL与整体花费了多少时间,其中99%用于SQL.

但是,如果SQL Mgmt Studio中的速度也不慢,则很难调试和改进.

所以我的问题是,为什么差异？可能是SQL Mgmt Studio的锁定方式与控制台应用程序不同吗？

我们正在努力解决一个奇怪的问题:当原始SQL执行得相当快时,存储过程变得极其缓慢.

我们有

• SQL Server 2008 R2速成版SP1 10.50.2500.0,上面有几个数据库.
• 一个数据库(它的大小约为747Mb)
• 一个存储过程,它接受不同的参数并从数据库中选择多个表.

码:

ALTER Procedure [dbo].[spGetMovieShortDataList](
   @MediaID int = null,
   @Rfa nvarchar(8) = null,
   @LicenseWindow nvarchar(8) = null,
   @OwnerID uniqueidentifier = null,
   @LicenseType nvarchar(max) = null,
   @PriceGroupID uniqueidentifier = null,
   @Format nvarchar(max) = null,
   @GenreID uniqueidentifier = null,
   @Title nvarchar(max) = null,
   @Actor nvarchar(max) = null,
   @ProductionCountryID uniqueidentifier = null,
   @DontReturnMoviesWithNoLicense bit = 0,
   @DontReturnNotReadyMovies bit = 0,
   @take int = 10,
   @skip int = 0,
   @order nvarchar(max) = null,
   @asc bit = …

我们有一个特定的查询,在proc内部运行得慢得多.我必须在这里添加它,它被包含在一个两级游标中.但是,两个游标都有一行的迭代结果集.

让我先说明我们尝试过但失败的事情:

• 使用选项(重新编译)和选项(optiimize for(@var UNKNOWN)避免参数嗅探
• 这个帖子.似乎是问题的变量实际上是本地变量而不是proc参数.

这是从proc/cursors内部获取的查询.

 select @tpdim1 = dim1, @tpdim2 = dim2, @typecalc = typecalc
    from loyalty_policy where code=@loop2_loyalty_policy

注意:@ loop2_loyalty_policy是取自内部游标结果的var,并且有一个值.code是PK到loyalty_policy桌子.因此,@ tpdim1和@tpdim2各有一个值.

SET STATISTICS PROFILE ON 
SET STATISTICS    xml on           
                  insert into @tbl_loyal_loop2 (cnt, store, map, pda, insdate, line, item, loyalty_policy_data, loyal_calc, loyalty_policy)
                  select @cnt, t.store, t.map, t.pda, t.insdate, t.line, t.item, ld.tab_id,  
                  case @typecalc
                        when 1 then convert(bigint,round(isnull(t.valueFromTran,0.00) * ld.value , 0 ) )
                        when 2 then convert(bigint,round(isnull(t.netvalue,0.00) * ld.value , 0 ) …

我有一个存储过程,我最近在我的生产服务器上修改它开始表现不佳但是当我独立运行查询时它运行正常.时间差异很大,即比较5秒到10分钟是惊人的.

我读了这篇文章SQL Server:快速查询,但从程序缓慢,尝试用所有可能的解决方案解决我的问题,但仍然存储的proc不起作用它在时间上有相同的差异.

任何人都可以让我知道我应该更改什么,以便我的存储过程运行至少与查询一样快？我对SQL Server的这种行为感到有些惊讶

好计划

  |--Clustered Index Seek(OBJECT:([IndusLynk].[dbo].[Assessment].[PK_Assessment] AS [a]), SEEK:([a].[Assessment_Id]=[@AssessmentID]) ORDERED FORWARD)
  |--Compute Scalar(DEFINE:([Expr1009]=CONVERT_IMPLICIT(float(53),[Expr1008]-(1),0)))
       |--Compute Scalar(DEFINE:([Expr1008]=CONVERT_IMPLICIT(int,[Expr1012],0)))
            |--Stream Aggregate(DEFINE:([Expr1012]=Count(*)))
                 |--Stream Aggregate(GROUP BY:([ci].[Candidate_Instance_Id]))
                      |--Parallelism(Gather Streams, ORDER BY:([rr].[Candidate_Instance_ID] ASC))
                           |--Nested Loops(Inner Join, OUTER REFERENCES:([rr].[Candidate_Instance_ID]))
                                |--Sort(ORDER BY:([rr].[Candidate_Instance_ID] ASC))
                                |    |--Clustered Index Scan(OBJECT:([IndusLynk].[dbo].[Processed_Response].[PK_Processed_Response] AS [rr]), WHERE:([IndusLynk].[dbo].[Processed_Response].[Assessment_ID] as [rr].[Assessment_ID]=[@AssessmentID] AND [IndusLynk].[dbo].[Processed_Response].[Client_ID] as [rr].[Client_ID]=[@UserID]))
                                |--Stream Aggregate(DEFINE:([ci].[Candidate_Instance_Id]=ANY([IndusLynk].[dbo].[Candidate_Instance].[Candidate_Instance_Id] as [ci].[Candidate_Instance_Id])))
                                     |--Nested Loops(Inner Join, WHERE:([IndusLynk].[dbo].[Candidate_Instance].[Instance_Status] as [ci].[Instance_Status]=[status]))
                                          |--Clustered Index Seek(OBJECT:([IndusLynk].[dbo].[Candidate_Instance].[PK_Candidate_Instance] AS [ci]), SEEK:([ci].[Candidate_Instance_Id]=[IndusLynk].[dbo].[Processed_Response].[Candidate_Instance_ID] as [rr].[Candidate_Instance_ID]) ORDERED FORWARD)
                                          |--Table Scan(OBJECT:(@AssessmentStatuses))
  |--Table Insert(OBJECT:(@ItemDetailTable), SET:([Candidate_Id] = [IndusLynk].[dbo].[Candidate].[Candidate_Id] as [c].[Candidate_Id],[Instance_End_Time] …