小编Tra*_*y M的帖子

多年来，我们一直在使用 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

我们最近遇到了事务日志增长并最大化存储空间的问题。这发生在维护窗口期间（正在使用 Ola Hallengren 索引优化脚本。）出于某种原因，过去有人将事务日志备份设置为停止 3 小时，似乎是在索引作业运行时（它们是设置运行 3 小时）。

我的组织最近从 2008r2 迁移到 sql server 2016。负责迁移的人员将不做事务日志的窗口更改为缩短了 30 分钟，因此他们现在从早上 5:30 开始。我认为他认为他们正在停止进行完整备份。但我相信他们被停止是为了让索引维护运行。在这两种情况下都需要吗？似乎停止 tlog 备份弊大于利。

sql server 2008r2 计划是：

• 3:00am：事务日志备份停止
• 3:00am：每周索引
  优化作业开始（由于日志
  空间，这在 2 小时 30 分钟后失败）
• 4:00am：完整备份
• 早上 6:00/更改为早上 5:30：事务日志备份开始（但日志保持完整）

附加信息：

我的组织最近在 2008r2 中从 2008r2 升级到 sql server 2016，我们从未经历过这种情况（都是企业版）。这可能只是巧合还是升级会改变某些东西？任何人都可以提供有关检查原因的建议吗？服务器管理员已将作业设置回原始计划；从凌晨 3 点到早上 6 点没有 tran 日志备份，认为索引维护和事务日志备份的重叠导致了问题，这是真的吗？我对事务日志主题所做的研究越多，我们似乎就越应该在此维护窗口期间进行日志备份而不是将其关闭。我对为什么他们首先被阻止感到有些困惑，原来的管理员不再在公司工作。一世'