【问题标题】:Replacing a parameter in 2008 R2 SSRS替换 2008 R2 SSRS 中的参数
【发布时间】:2017-05-15 15:20:23
【问题描述】:

我正在使用 SSRS 2008 R2 和报表生成器 3.0。我有一个需要帮助的级联报告问题。第一份报告运行良好。单击报告中的链接会将@processID 参数传递给后续报告。

现在,当使用字符串而不是直接在 SSMS 中的参数运行查询时,它需要不到 1 秒的时间。当我使用参数通过 SSRS 运行它时,大约需要 15 分钟。我读过SSRS不能很好地处理参数。我想做的是找到一种方法将参数更改为字符串,然后发送它,或者如果有人知道更好的方法。

以下是报表正在运行的查询:

SELECT     ResultDetail_View.processOid, ResultDetail_View.applicationId, outputItem.outputValue, ResultDetail_View.startTime, ResultDetail_View.resultStatus, 
                      ResultDetail_View.statusMessage, ResultDetail_View.endTime, ResultDetail_View.ErrRec, COUNT(Summary.Id) AS SumRec

FROM         ResultDetail_View LEFT OUTER JOIN
                      Summary ON ResultDetail_View.processOid = Summary.Id LEFT OUTER JOIN
                      outputItem ON ResultDetail_View.outputOid = outputItem.outputItemOid

GROUP BY ResultDetail_View.processOid, ResultDetail_View.applicationId, outputItem.outputValue, ResultDetail_View.startTime, ResultDetail_View.resultStatus, 
                      ResultDetail_View.statusMessage, ResultDetail_View.endTime, ResultDetail_View.ErrRec

HAVING      (ResultDetail_View.processOid = @processID)

ORDER BY ResultDetail_View.startTime

【问题讨论】:

  • 您如何在报告中运行查询?它是存储过程吗?如果是这样,这看起来很像Parameter Sniffing,这将妨碍 SQL Server 选择最佳查询计划的能力。
  • 不幸的是,这些是继承的报告。这些是临时格式,而不是存储过程。我发布的代码实际上是运行的数据集查询。我还没有找到参数嗅探。为了以防万一,我进行了重新编译,但在 SSRS 和 SSMS 中仍然花费了相同的时间。
  • 您是否在 sql server 实例上运行过跟踪,以准确查看报表运行时服务器上正在执行的查询。一旦你有了它,如果你直接在同一台服务器上的 SSMS 中运行它,你应该得到完全相同的性能(无论是好是坏)。这不是答案,但至少应该可以帮助您调查问题。

标签: sql-server sql-server-2008 reporting-services ssrs-2008-r2


【解决方案1】:

不管最初的问题是什么,看起来您可以在不更改查询结果的情况下将您的 having 更改为 where?如果是这种情况,肯定会对性能有所帮助。

关于参数嗅探,您是否尝试过设置本地nvarchar 变量并在报告中以这种方式运行查询?

delcare @processIDLocal nvarchar(50) = @processID;

select r.processOid
      ,r.applicationId
      ,o.outputValue
      ,r.startTime
      ,r.resultStatus
      ,r.statusMessage
      ,r.endTime
      ,r.ErrRec
      ,count(s.Id) as SumRec
from ResultDetail_View as r
    left outer join Summary as s
        on r.processOid = s.Id
    left outer join outputItem as o
        on r.outputOid = o.outputItemOid
where r.processOid = @processID
group by r.processOid
        ,r.applicationId
        ,o.outputValue
        ,r.startTime
        ,r.resultStatus
        ,r.statusMessage
        ,r.endTime
        ,r.ErrRec
order by r.startTime;

【讨论】:

  • 这并没有随着它的运行而改变任何东西。这不是参数嗅探问题,因为直接在 SSMS 上运行的相同查询以毫秒为单位运行。
  • @bwilliamson "因为直接在 SSMS 上运行的相同查询以毫秒为单位运行" 这几乎是参数嗅探的最大指标......
  • 如果我在两个位置运行相同的查询并重新编译,它不应该为每个位置选择最佳计划吗?此外,如果我将报表生成器中的数据集查询更改为仅使用字符串值而不是 @parameter,它也会在一两秒内运行,而不是 13 分钟。执行计划显示了整个流程的 1 行和 1100 万行之间的差异。
  • @bwilliamson 请阅读this article。您实际上是在描述参数嗅探,您只是没有做实际推荐的有助于缓解它的事情,例如使用本地参数。您看到预期行数的巨大差异是导致计划选择不佳的原因。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多