标签: ola-hallengren

我们碰巧使用的是 SQL Server 2012 标准版。我还碰巧使用了 Ola Hallengren 的脚本来提供一个简单、更灵活的框架来进行备份和维护。

这个问题不是关于 Ola 的脚本，而是关于最佳实践。我意识到最终的答案是“这取决于贵公司的要求”。但我正在尝试就如何最好地满足我对公司要求的理解寻求社区的建议。

我希望每 15 分钟设置一次事务日志备份。这样我们希望丢失不超过 15 分钟的数据。我应该设置一项使用 ALL_DATABASES 的作业吗？还是为每个数据库设置一项工作并并行启动它们更好？我问，因为根据我如何看待 Ola 的脚本功能，我有一种感觉，即备份是串行启动的。串行的缺点是每个连续的备份都等待另一个完成。这可能会增加备份之间的时间量（即大于 15 分钟）。另外，我担心一个备份的失败会阻止其他备份的发生，我不希望出现这种情况。我希望其他人继续备份。

那么，Ola 的脚本是串行执行的，而且故障也会停止连续备份吗？

每个数据库都有一份工作是不是更好？还是做所有事情的单一工作？我倾向于单独的工作，但我希望了解 SQL Server DBA 通常倾向于做什么。

数据库 SQL Server 2017 Enterprise CU16 14.0.3076.1

我们最近尝试从默认的 Index Rebuild 维护作业切换到 Ola Hallengren IndexOptimize。默认的索引重建作业已经运行了几个月没有任何问题，并且查询和更新的执行时间在可接受的范围内。在IndexOptimize数据库上运行后：

EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'

性能极度下降。之前花费 100 毫秒的更新语句在之后IndexOptimize花费了 78.000毫秒（使用相同的计划），并且查询的性能也差了几个数量级。

由于这仍然是一个测试数据库（我们正在从 Oracle 迁移生产系统），我们恢复到备份并禁用IndexOptimize，一切恢复正常。

但是，我们想了解什么IndexOptimize与Index Rebuild可能导致这种极端性能下降的“正常”不同，以确保我们在投入生产后避免这种情况。任何关于寻找什么的建议将不胜感激。

更新语句缓慢时的执行计划。即
IndexOptimize 之后的
实际执行计划（即将推出）

我一直无法发现差异。
快速时为同一个查询做
计划 实际执行计划

在我们的环境中，我们有一些服务器在 Always On Availability Group 中，有些服务器是独立的。

我们通常备份到网络共享，但我们最近观察到随着数据库越来越大，花费的时间越来越长，这会减慢整个网络的速度。

Ola Hallengren 的脚本用于压缩和拆分备份文件。我只执行每日“完整”备份。备份将转到网络共享 EMC isilon 驱动器。

我对 EMC DD Boost 从不满意。唯一的选择是进行本地备份，然后复制到相同的网络共享。

除了上面的方法，还有其他有效的方法吗？

请您帮我了解使用 Ola 的解决方案而不是维护计划的利弊吗？我准备了一个基于 SQL Pass ( http://www.pass.org/DownloadFile.aspx?File=ebae1b31 )的演示文稿，我将展示它。

我还准备了一些 Ola 解决方案解决而维护计划解决方案没有解决的场景。大家能帮我从技术上解释一下吗？

顺便说一下，我们正在使用 Ola 的解决方案管理近 150 多台服务器（2008/2012/2014/2016 的组合），其中至少有 75%。我喜欢 Brent Ozar 的这篇文章。但在评论中，Brent 建议对我们拥有的服务器数量使用基于脚本的解决方案。https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/

我无法理解Ola Hallengren 服务器维护解决方案中的CleanupTime选项的确切期望。我正在寻找一些相关的问题和详尽的答案，但这些解释仍然让我有些困惑。

具体来说：

我正在做每周完整备份、每日 DIFF 备份和每小时日志备份。完整备份使用默认值CleanupTime24 小时。DIFF 和 LOG 备份的 NULL 为CleanupTime。

从CleanupTime 参数的文档中，我无法理解是否设置FULLCleanupTime备份的设置BackupType也会删除旧的 DIFF 和 LOG 备份文件，或仅删除FULL 备份文件。

指定删除备份文件之前的时间（以小时为单位）。如果未指定时间，则不会删除任何备份文件。

后一段让我认为设置FULLCleanupTime备份BackupType也会删除旧的事务日志。然而，不清楚这一段是只适用于BackupTypeLOG的备份，还是也适用于BackupTypeFULL的备份。

DatabaseBackup 有一个检查来验证比最近的完整或差异备份更新的事务日志备份没有被删除。

我想要实现的是，我可以进行长达 1 周的时间点恢复。（我们有一个非常缓慢变化的数据库，所以这是可行的）按照我现在的理解，这需要一周的完整备份，以及一周的事务日志备份。由于完整备份和差异备份只能用于恢复到一个特定的时间点。

那么，我应该将CleanupTime完整备份作业的选项设置为24*7吗？我现在猜测的是，将其设置为 24 小时，将导致下一次完整备份删除所有较旧的完整、差异和事务日志备份文件，从而使我的时间点恢复窗口为 ... 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

我看到这个：

首先，我意识到有人问过类似的问题，并且对于 679 页的索引，海报的页数设置为 1000；不是怎么回事。

我将 Ola 的脚本设置为

@Databases nvarchar(max)
,@FragmentationLow nvarchar(max) = null
,@FragmentationMedium nvarchar(max) = 'INDEX_REORGANIZE'
,@FragmentationHigh nvarchar(max) = 'INDEX_REBUILD_ONLINE'
,@FragmentationLevel1 int = 50
,@FragmentationLevel2 int = 75
,@PageCountLevel int = 400
,SortInTempdb nvarchar(max) = 'N'
,maxdop int = null
,fillfactor int = null
,PadIndex nvarchar(max) = null
,LOBCompaction nvarchar(max) = 'Y'
,UpdateStatistics nvarchar(max) = 'ALL'
,OnlyModifiedStatistics nvarchar(max) = 'Y'
,StatisticsSample int = null
,StatisticsResample nvarchar(max) = 'N'
,PartitionLevel nvarchar(max) = 'Y'
,MSShippedObjects nvarchar(max) = 'N'
,Indexes nvarchar(max) = …

我们通常使用 Ola Hallengren 的解决方案来处理我们拥有的索引优化作业中的更新统计信息。我们将它安排在所有服务器（1500+）的每个星期日午夜作为标准做法。

现在，有几台服务器在周中出现了很多性能问题，当因性能问题引发事件时，我们为该特定数据库运行 sp_updatestats。我们有一个巨大的环境，其中使用了 2000 到 2016 年的所有版本。在 2012 年和 2014 年的版本中，我们一直在周中手动运行特定数据库的更新统计信息。

最近，由于反复出现的问题，我们还不得不为一些非常活跃的数据库每天安排 sp_updatestats。

我的问题：

1. 我们应该多久安排一次？
2. 过于频繁地安排它有什么缺点？
3. 有没有办法避免定期更新运行如此频繁的缺点，因为我听说编译需要更多时间并且可能会在一段时间内降低性能？

请帮助我了解您在这方面的经验。

当我将 Ola Hallengren 的备份脚本部署到我的服务器时，我总是将@CleanupTime日志备份的参数设置为零。这样，每次运行日志备份作业时，它都会检查早于上次完整备份的日志备份文件并将其删除。但是，对于完整COPY_ONLY备份也是如此！COPY_ONLY为了删除旧的日志备份文件，日志备份作业应该只检查最后一次非完整备份。

只是想知道我是否是唯一遇到这种情况的人，或者我的建议是否合理。如果我需要在中间进行完整副本备份以 IDK 刷新 TEST 数据库，则该仅副本备份不应影响常规的每日备份顺序。请让我知道你的想法。

在我们的 AWS RDS 实例上设置 SQL Server 索引和统计维护代码的过程中，我设法设置了脚本并且可以从 SSMS 运行它。

考虑到RDS的限制，请教如何设置SQL Server Agent？