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

时间：2012-10-15 06:00:11

标签： sql-server-2008 ssrs-2008 bids

环境

数据库服务器（DWH prod＆amp; dev + SSRS prod）

  • Win XP SP3
  • SQL Server 2008 Ent
  • 企业局域网
  • DWH没有远程查询超时限制，即它们设置为0
  • 600秒为SSRS数据库服务器设置远程查询超时
  • 对并发连接没有限制，即它们设置为0
  • SQL Server的TCP / IP KeepAlive属性= 30000

开发框

  • Win XP SP3
  • BIDS 2008

共享数据源（由.rdl使用）

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


问题

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

  

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

     

报告处理期间发生错误。

     

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

     

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

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


查询结构（为简洁而列出）

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


注意事项（不确定是否有任何帮助）：

  • 递归CTE只执行24次递归。
  • 所有密钥均为PRIMARY KEY CLUSTERED INDEXES


问题（S）

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


    3. 到目前为止我做了什么......

    2012年10月15日

    • 在Google计算机上搜索无效。
    • 与已经看到这种情况的其他团队成员发言，他们认为这可能与性能有关，即查询运行时间太长，或者他们认为SSRS可能会执行更严格的SQL代码验证/语法检查，或它使用的连接器。

    二零一二年十月十六日 

    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 ---
    • 上述异常在同一数据集的日志中多次出现 - ＆gt;可能的原因可能是CTE中的递归
    • 我检查了DWH数据库服务器和SSRS数据库服务器级别的TCP / IP设置。两者都将KeepAlive属性设置为30000，即30秒 - ＆gt;丢失连接的可能原因是什么？
    • 类似的问题解决方案（基于堆栈跟踪）发现here用于针对Visual Studio 2005的查询。我取消选择Tools > Options > Database Tools > Query and View Designers > Cancel long running query（设置为30秒）。没有变化（这个客户端设置也不会影响报告一旦部署到SSRS服务器我相信，但我想我会试一试）
    • 找到OBDC connection attempt when server is not ready to process a new local connection, possibly due to overload的{​​{3}} - ＆gt;当SSRS将查询提交给DWH服务器时，递归CTE会导致这样的重载（即使我没有进行ODBC连接）??
    • 发现this表示SSRS不喜欢虚拟表（未提及原因，并未提供参考） - ＆gt;可能需要重新编写查询吗？
    • 回应评论re：网络诊断

5 个答案:

答案 0 :(得分：0)

首先，你必须找到问题。

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

答案 1 :(得分：0)

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

在所有情况下，使用SQL Server Profiler和其他诊断工具来查看数据库实际上在做什么。

答案 2 :(得分：0)

似乎是超时问题......但请尝试以下方法：

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

这可能/可能不会导致解决问题但至少你会缩小范围并检索你在SSMS中所做的数据。

答案 3 :(得分：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提示。如果这样可以提高性能，那么您可能会遇到与我遇到的同样的死锁问题。
  • 从长期来看，您可能希望从不繁重的数据库中读取数据，例如。包含夜间数据的数据库报告版本。

答案 4 :(得分：0)

一个新答案提示我写这个答案以结束问题，尽管尚未完全验证，但尽我所能，更高版本的SQL Server工具中不会出现此问题知识（即现在将在各种工具上产生相同的结果）。

（从内存中）原因是SSMS vs 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
相关问题
最新问题