相关疑难解决方法(0)

我在所有服务器上运行 Ola Hallengren 脚本以进行索引和统计维护。当我查看命令日志表时，我注意到命令结束和下一个命令开始之间的时间很长。有时这个间隔会超过一个小时。

有没有其他人在他们的系统上观察到这一点？我可以做些什么来缩短（我猜）要维护的项目之间的发现时间？下面是我运行它们的参数集。

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[IndexOptimize] 
@Databases = 'USER_DATABASES', 
@LogToTable = 'Y',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 50,
@FragmentationLevel2 = 80,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y' " -b

所以当我运行这个时：

SELECT DATEDIFF(MINUTE, cl.StartTime, cl.EndTime)
, *
FROM master.dbo.CommandLog AS cl
WHERE cl.StartTime > '2014-12-13'
ORDER BY cl.ID

我看到这个：

多年来，我们一直在使用 Ola Hallengren 的维护脚本对 OLTP 数据库进行索引优化。（我们在 sql server 2008 R2 上）2 周前，尽管这里的一位 DBA 创建了一个维护作业来单独更新统计信息，并且在索引优化作业之前每周运行一次。似乎在创建它之后，我们在少数存储过程中遇到了性能问题。我对统计维护不太熟悉，所以我想知道，是否真的有必要单独运行每周工作来更新所有统计数据？
这里的 DBA 似乎认为这是必要的，但我觉得在维护作业运行后的第二天早上，我们开始执行糟糕的存储过程，我经常需要每天至少重新编译相同的存储过程 1 或 2 次，以用于以下几个几天然后问题就停止了。我的理论指向之前发生的统计更新，但我找不到原因。无论如何，在进行一定量的更改或索引重建期间，统计信息是否会更新？为什么单独重新计算它们会导致问题？

有没有人能够澄清为什么每次更新统计信息时相同的存储过程都会发生这种情况？

这是用于统计作业的命令：

EXECUTE dbo.IndexOptimize 
    @Databases = 'DB_PRO', 
    @FragmentationLow = NULL, 
    @FragmentationMedium = NULL, 
    @FragmentationHigh = NULL, 
    @UpdateStatistics = 'ALL', 
    @OnlyModifiedStatistics = 'Y' , 
    @TimeLimit = 3600, 
    @LogToTable = N'Y'; 

然后索引维护作业运行如下：

    sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[IndexOptimize] 
    @Databases = 'DB_PRO', @TimeLimit = 10800, @LogToTable = 'Y'" -b