更新:对不起!我可能因为旧的描述而想念你。迁移后问题不存在,它在迁移后1周开始出现
我们最近将数据库和报表服务器迁移到新的数据库服务器和新的报表服务器。
配置之前:
配置现在:
迁移遵循MSDN迁移说明并最终起作用(尽管我们必须手动删除冗余扩展部署服务器(与旧服务器同名)以使其工作,我认为这是SSRS错误。)
迁移后1周,新报表服务器上的报表开始运行速度极慢。
所以我做了以下分析:
在旧报表服务器中执行报表(报表的数据库连接指向新数据库服务器)和新报表服务器,旧报表服务器像以前一样快速运行(1秒),但新报表服务器运行速度非常慢(31秒)。
直接执行报告所调用的存储过程,它与以前一样快(50毫秒)。
诊断[ReportServer $ Instance]。[dbo]。[ExecutionLog]数据库,旧服务器中TimeDataRetrival为50 ms,新服务器为30050 ms。
运行SQL Server Profiler,在旧服务器上执行报告,一切似乎都很好。在新服务器中执行报告,引起了我的注意。在每个批次的最后一个事件之后,它将在“审核注销”生成之前“挂起”(运行)很长一段时间。下面的示例实际运行10秒,但所有语句实际运行时间不到1秒。
我怀疑:a)。某些配置(如帐户访问权限)已更改,但未经我确认。 B)。新的报表服务器正在尝试对没有正确访问权限的用户进行身份验证,并在替代解决方案之前将其“挂起”几秒钟。
启动探查器输出:
审核登录 - 网络协议:TCP / IP 设置quoted_identifier 设置arithabort 设置numeric_roundabort关闭 设置ansi_warnings 设置ansi_padding 设置ansi_nulls 设置concat_null_yields_null 设置cursor_close_on_commit off 设置implicit_transactions关闭 设置语言us_english 设置dateformat mdy 设置datefirst 7 set transaction isolation level read committed
Report Server sa 1440 100 2013-04-16 16:10:14.393 0X2000002838F4010000000000
SQL:BatchStarting
声明@BatchID uniqueidentifier
set @BatchID = NEWID()
UPDATE [Event] WITH (TABLOCKX)
SET [BatchID] = @BatchID,
[ProcessStart] = GETUTCDATE(),
[ProcessHeartbeat] = GETUTCDATE()
FROM (
SELECT TOP 8 [EventID] FROM [Event] WITH (TABLOCKX) WHERE [ProcessStart] is NULL ORDER BY [TimeEntered]
) AS t1
WHERE [Event].[EventID] = t1.[EventID]
select top 8
E.[EventID],
E.[EventType],
E.[EventData]
from
[Event] E WITH (TABLOCKX)
where
[BatchID] = @BatchID
ORDER BY [TimeEntered]
Report Server sa 1440 100 2013-04-16 16:10:14.393
SQL:BatchCompleted
声明@BatchID uniqueidentifier
set @BatchID = NEWID()
UPDATE [Event] WITH (TABLOCKX)
SET [BatchID] = @BatchID,
[ProcessStart] = GETUTCDATE(),
[ProcessHeartbeat] = GETUTCDATE()
FROM (
SELECT TOP 8 [EventID] FROM [Event] WITH (TABLOCKX) WHERE [ProcessStart] is NULL ORDER BY [TimeEntered]
) AS t1
WHERE [Event].[EventID] = t1.[EventID]
select top 8
E.[EventID],
E.[EventType],
E.[EventData]
from
[Event] E WITH (TABLOCKX)
where
[BatchID] = @BatchID
ORDER BY [TimeEntered]
Report Server sa 0 7 0 0 1440 100 2013-04-16 16:10:14.393 2013-04-16 16:10:14.393
SQL:BatchStarting
声明@BatchID uniqueidentifier
set @BatchID = newid()
UPDATE [Notifications] WITH (TABLOCKX)
SET [BatchID] = @BatchID,
[ProcessStart] = GETUTCDATE(),
[ProcessHeartbeat] = GETUTCDATE()
FROM (
SELECT TOP 8 [NotificationID] FROM [Notifications] WITH (TABLOCKX) WHERE ProcessStart is NULL and
(ProcessAfter is NULL or ProcessAfter < GETUTCDATE()) ORDER BY [NotificationEntered]
) AS t1
WHERE [Notifications].[NotificationID] = t1.[NotificationID]
select top 8
-- Notification data
N.[NotificationID],
N.[SubscriptionID],
N.[ActivationID],
N.[ReportID],
N.[SnapShotDate],
N.[DeliveryExtension],
N.[ExtensionSettings],
N.[Locale],
N.[Parameters],
N.[SubscriptionLastRunTime],
N.[ProcessStart],
N.[NotificationEntered],
N.[Attempt],
N.[IsDataDriven],
SUSER_SNAME(Owner.[Sid]),
Owner.[UserName],
-- Report Data
O.[Path],
N.[ReportZone],
O.[Type],
SD.NtSecDescPrimary,
N.[Version],
Owner.[AuthType]
from
[Notifications] N with (TABLOCKX) inner join [Catalog] O on O.[ItemID] = N.[ReportID]
inner join [Users] Owner on N.SubscriptionOwnerID = Owner.UserID
left outer join [SecData] SD on O.[PolicyID] = SD.[PolicyID] AND SD.AuthType = Owner.AuthType
where
N.[BatchID] = @BatchID
ORDER BY [NotificationEntered]
Report Server sa 1440 100 2013-04-16 16:10:14.393
SQL:BatchCompleted
声明@BatchID uniqueidentifier
set @BatchID = newid()
UPDATE [Notifications] WITH (TABLOCKX)
SET [BatchID] = @BatchID,
[ProcessStart] = GETUTCDATE(),
[ProcessHeartbeat] = GETUTCDATE()
FROM (
SELECT TOP 8 [NotificationID] FROM [Notifications] WITH (TABLOCKX) WHERE ProcessStart is NULL and
(ProcessAfter is NULL or ProcessAfter < GETUTCDATE()) ORDER BY [NotificationEntered]
) AS t1
WHERE [Notifications].[NotificationID] = t1.[NotificationID]
select top 8
-- Notification data
N.[NotificationID],
N.[SubscriptionID],
N.[ActivationID],
N.[ReportID],
N.[SnapShotDate],
N.[DeliveryExtension],
N.[ExtensionSettings],
N.[Locale],
N.[Parameters],
N.[SubscriptionLastRunTime],
N.[ProcessStart],
N.[NotificationEntered],
N.[Attempt],
N.[IsDataDriven],
SUSER_SNAME(Owner.[Sid]),
Owner.[UserName],
-- Report Data
O.[Path],
N.[ReportZone],
O.[Type],
SD.NtSecDescPrimary,
N.[Version],
Owner.[AuthType]
from
[Notifications] N with (TABLOCKX) inner join [Catalog] O on O.[ItemID] = N.[ReportID]
inner join [Users] Owner on N.SubscriptionOwnerID = Owner.UserID
left outer join [SecData] SD on O.[PolicyID] = SD.[PolicyID] AND SD.AuthType = Owner.AuthType
where
N.[BatchID] = @BatchID
ORDER BY [NotificationEntered]
Report Server sa 0 7 0 0 1440 100 2013-04-16 16:10:14.393 2013-04-16 16:10:14.393
审核注销
报告服务器sa 0 3836 6 10140 1440 100 2013-04-16 16:10:14.393 2013-04-16 16:10:24.533
答案 0 :(得分:1)
您是否从等式中消除了参数嗅探?
尝试将匹配的假参数添加到sproc中,然后在开头为它们提供相应参数传入的值。查看报告是否以这种方式运行得更快。
答案 1 :(得分:1)
好的,我想我弄明白了如何解决它。我修改了报告文件(.rdl)并上传到新的报告服务器以覆盖现有的报告文件,它按预期运行得很快。
我怀疑是因为我们使用数据库备份/恢复将SSRS 2008迁移到SSRS 2012,而SSRS 2012没有自动升级文件格式,这导致了问题。