查询在SSRS 2008或BIDS 2008中不起作用，但在SSMS中起作用

问题描述 投票：7回答：5

Environment

DB Server (DWH prod & dev + SSRS prod)

  • 赢得XP SP3
  • SQL Server 2008 Ent
  • corporate LAN
  • 没有DWH的远程查询超时限制，即它们被设置为0
  • 为SSRS DB服务器设置远程查询超时的600秒
  • 并发连接没有限制，即它们设置为0
  • SQL Server的TCP / IP KeepAlive属性= 30000

Dev Box

  • 赢得XP SP3
  • BIDS 2008

Shared Data Source (used by the .rdl)

  • 使用服务器的计算机名称，没有别名
  • 权限都可以

Problem

BIDS在查看报告的“预览”选项卡时返回的错误在大约1分钟后出现（SSMS中的查询需要大约1分10秒 - 编辑：2012-10-16现在已经在SSRS中复制了错误通过将报告部署到Report Manager并尝试运行报告：下面添加了异常堆栈跟踪）：

本地报告处理期间发生错误。

报告处理期间发生错误。

数据集“MainData”的查询执行失败。

从服务器接收结果时发生传输级错误。 （提供程序：TCP提供程序，错误：0 - 指定的网络名称不再可用。）

  • 该查询已针对prod和dev db服务器的最终用户帐户（具有db_datareader权限）进行了测试，并且在SSMS中正常运行。
  • 此帐户用于最终用户在运行时执行.rdl。
  • SSMS用于验证查询在语法上是否正确，并返回完整且完整的结果集，没有错误且没有警告。

The Query Structure (listed as such for brevity)

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SET NOCOUNT ON
SET ANSI_WARNINGS OFF

/********************************************************** 
    CTE to be used to clean strings
***********************************************************/
;WITH
    CTE_1           AS  ( SELECT SomeData )
    ,CTE_2          AS  ( SELECT SomeData )
    ,Recursive_CTE  AS  ( SELECT SomeData )     -- String cleaning performed here
    ,CTE_3          AS  ( SELECT SomeData )

/**************************     
 Data set returned here
***************************/
SELECT
    Column_1
    ,Column_2
    ,Column_3
    .
    .
    .
    ,Column_n
FROM
    Fact
    INNER JOIN  Dimension_1     AS 1        ON Fact.Key_1   = 1.Key_1
    INNER JOIN  Dimension_2     AS 2        ON Fact.Key_2   = 2.Key_2
    INNER JOIN  Dimension_3     AS 3        ON Fact.Key_4   = 3.Key_3
    INNER JOIN  Dimension_5     AS 4        ON Fact.Key_4   = 4.Key_4
    LEFT JOIN   CTE_3           AS clean    ON 4.Key_4      = clean.Key_4   -- Clean names returned in query and used in GROUP BY clause    
WHERE
    Condition_1 = Test_1
    AND Condition_2 = Test_2
    AND Condition_3 = Test_3
    .
    .
    .
    AND Condition_n = Test_n
GROUP BY
    Group_1 
    ,Group_2
    ,Group_3
    .
    .
    .
    ,Group_n
ORDER BY
    Group_1 
    ,Group_2
    ,Group_3
    .
    .
    .
    ,Group_n

Notes (not sure if any of this will be helpful or not):

  • 递归CTE仅执行24次递归。
  • 所有的钥匙都是PRIMARY KEY CLUSTERED INDEXES

Question(s)

  1. 从哪里开始诊断问题究竟是什么？
  2. 一旦识别出来，如何解决问题？

What I have done so far...

2012-10-15

  • 在谷歌机器上猎杀无济于事。
  • 与已经看到这种情况发生的其他团队成员讨论，他们认为这可能与性能有关，即查询运行时间太长，或者他们认为SSRS或连接器可能执行更严格的SQL代码验证/语法检查它用。

2012-10-16

ERROR: Throwing Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Query execution failed for dataset 'DataSet1'., ;
 Info: Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Query execution failed for dataset 'DataSet1'. ---> System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
   at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
   at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
   at System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket()
   at System.Data.SqlClient.TdsParserStateObject.ReadBuffer()
   at System.Data.SqlClient.TdsParserStateObject.ReadByte()
   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
   at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior)
   at Microsoft.ReportingServices.DataExtensions.SqlCommandWrapperExtension.ExecuteReader(CommandBehavior behavior)
   at Microsoft.ReportingServices.OnDemandProcessing.RuntimeDataSet.RunDataSetQuery()
   --- End of inner exception stack trace ---
  • 上述异常在同一数据集的日志中多次出现 - >可能的原因可能是CTE中的递归？
  • 我检查了DWH数据库服务器和SSRS数据库服务器级别的TCP / IP设置。两者都将KeepAlive属性设置为30000，即30秒 - >可能导致连接断开？
  • 类似的问题解决方案（基于堆栈跟踪）发现here用于查询Visual Studio 2005.我取消选择Tools > Options > Database Tools > Query and View Designers > Cancel long running query（设置为30秒）。没有变化（这个客户端设置也不会影响报告一旦部署到SSRS服务器我相信，但我想我会试一试）
  • 找到this，声明OBDC connection attempt when server is not ready to process a new local connection, possibly due to overload - >当SSRS将查询提交给DWH服务器时，可能递归CTE导致这样的重载（即使我没有进行ODBC连接）？
  • 发现this表示SSRS不喜欢虚拟表（没有提到原因，并没有提供参考） - >可能需要重新编写查询？
  • 回复评论：网络诊断
sql-server-2008 ssrs-2008 bids
5个回答
0
投票

首先，您必须找到问题所在。

您可以查看运行Profiler打开报表时发生的情况吗？使用事件启动跟踪审核登录，审核注销，异常，SQL：Stmt：正在启动/已完成。在您尝试打开报告后，请检查结果并告知我们。

0
投票

建议：当查询变得复杂并且SSRS开始抱怨时，将查询包装到数据库内的视图或存储过程中，在SSMS中测试新的（更简单的）查询，然后查看相同的简单查询是否在SSRS中有效。

在所有情况下，使用SQL Server Profiler和其他诊断工具来查看数据库实际执行的操作。

0
投票

看起来像超时问题...但请尝试以下方法：

如果要确保不使用相同的执行计划，请尝试选项（重新编译）以使用其他计划。

这可能/可能不会导致解决问题，但至少您将缩小范围并检索您在SSMS中执行的数据。

0
投票

尝试从写入数据库中读取时遇到此错误。

SQLEXCEPTION: Transaction was deadlocked on lock resources with another process and has been chosen as the deadlock victim.

这将导致您描述的SSRS行为，并在日志中显示此线索：

---> System.Data.SqlClient.SqlException: A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)

如果这是您的问题，请尝试以下方法：

  • 创建没有索引的临时表，以镜像查询中的事实和暗淡表。使用您需要的数据填充它们而不进行任何连接，然后添加索引。仅在这些临时表之间执行连接。
  • 考虑使用READ UNCOMMITTED事务隔离调试问题，或者向查询添加NOLOCK提示。如果这改善了性能，您可能遇到了我遇到的同样的死锁问题。
  • 长期而言，您可能希望从非重写的数据库中读取，例如。包含夜间数据的数据库报告版本。
0
投票

一个新的答案促使我写这个答案来解决这个问题，虽然这还没有完全验证，但据我所知，在更高版本的SQL Server工具中不会出现这个问题（即现在跨工具的相同结果）发生）。

原因（来自内存）是SSMS与SSRS使用不同的客户端连接，在2008版本中我认为SSRS使用ADO.Net连接器而SSMS使用的是不同的东西（不记得它现在是什么）。

在研究这个问题（5 - 6年前）时我遇到了一篇旧文章，它基本上在SQL Server堆栈工具之间布置了不同的客户端连接类型（我现在尝试再次搜索30分钟才找到它，但是鉴于这些工具现在已有10年历史，我找不到它是不成功的。我还记得在2012年或2014年发布时，微软发表了一篇文章，称客户类型将在所有工具中标准化。

因此，除非您使用的是2008工具（或更低版本），否则您将无法遇到SSMS中工作但SSRS失败的问题，它可能在两者中都失败，或者在两者中都有效。

如果您仍在使用SSMS 2008，我相信您可以设置高级查询执行选项，请尝试在以下位置查找连接客户端类型选项：

  • Tools > Options... > Query Execution > SQL Server > General
  • Tools > Options... > Query Execution > SQL Server > Advanced
最新问题
© www.soinside.com 2019 - 2024. All rights reserved.