Ola的脚本与使用维护计划相比有哪些优缺点？

Question

你能帮我理解使用Ola的解决方案相比维护计划有哪些优缺点吗？我已经准备了一个基于SQL Pass（http://www.pass.org/DownloadFile.aspx?File=ebae1b31）的演示，我将在演讲中展示。

我还正在准备一些场景，Ola的解决方案可以解决而维护计划无法解决的问题。你们能帮我更加技术性地解释一下吗？

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

- Pat

---

我们是在讨论备份、索引/统计维护、数据完整性检查还是以上所有的内容？ - nkdbajoe

所有的。Ola编写的完整维护解决方案脚本。我使用Ola的脚本解决了维护计划中不必要的索引重建和统计更新问题。我只是想从其他数据库管理员那里获取一些更多的技术支持。谢谢。 - Pat

我个人认为最好的解决方案是既满足您的业务需求，又能在出现错误时解决的解决方案。总体而言，Ola的解决方案还不错，但我仍然更喜欢根据我的环境定制的解决方案。例如，在索引维护方面，我希望能够并行执行以节省时间。Ola的解决方案在这里不适用。我还希望进行增量统计更新，Ola的解决方案在这里也不适用。 - jyao

你有没有任何数据能够证明他们更好，还是只是凭感觉认为他们更好？解决这个问题的最佳方式是获取一些性能数据，以便能够展示为什么某种方法更好。 - Joe W

对于索引维护来说，很多时候限制因素是您的SAN和存储子系统。根据您的SAN配置，您可能无法在并行重建中看到任何改进。 - Alen

如果你没有数据来证明一种方法比另一种更好，那么很难向持不同观点的人解释这一点。此外，即使你认为时间安排得当，但在命令行运行时仍有可能发生死锁错误，而没有任何防止它发生的措施。 - Joe W

@Joe W. 在我之前的雇主那里，我成功将以前在 SQL Server 2008R2 上运行 10-12 小时的统计更新作业缩短到不到 90 分钟。通过维护计划无法仅更新已修改的列统计数据。在我现任的雇主那里，有一次我们从维护计划设置的索引重建作业失败了。除了在错误日志中看到的失败命令之外，我没有看到如何确保其他语句是否成功执行。使用 Ola 的解决方案，出现死锁或其他错误时，您可以在时间允许的情况下从 CommandLog 表中运行失败的命令。 - Pat

Answer 1

我在这里写了

维护计划并不是坏事，但当你的环境变得更大时，维护计划提供的有限灵活性和功能将不足以满足需求。

此外，

Ola的维护解决方案得到了社区和大型组织的广泛认可。 该解决方案是开源的，可以在github/issues上提出问题，并有很大可能得到迅速解决。 它具有灵活性和可伸缩性（即使您想将其部署到数百台服务器，只需使用dbatools的Install-DbaMaintenanceSolution命令）。 微软花了近十年的时间来修复本身就存在缺陷的维护计划GUI :-) 它拥有丰富的文档和常见问题解答，并且不断更新以适应更新的SQL Server版本。 在预览版本中，甚至可以并行运行备份。 对于索引维护解决方案，您甚至可以设置时间限制，例如如果执行时间超过X，则中止操作。

- Kin Shah

Answer 2

脚本解决方案的一个主要优势是部署的便利性，这在你们的情况下显然非常重要，因为你们有150多台服务器。试图在150台服务器上推出几个维护计划（至少2个，一个用于系统数据库，一个用于用户数据库）将是一场噩梦。一旦部署完成后，维护它们同样麻烦。 脚本解决方案在部署和维护方面要容易得多。 Ola的脚本相当全面，涵盖了大多数需求。它们为任何组织提供了一个很好的起点，可以根据自己独特的需求进行调整。 在我们的情况下，我们的DEV环境中有大约40个SQL实例，并且我们使用修改过的Ola脚本与SSMS的多连接功能结合使用，以便能够一键在所有40个实例上推出维护计划的更改。任何特殊情况都由我们的修改处理。

- Mike

Answer 3

我对他的脚本不是100%确定，但自定义脚本比维护计划要好得多。内置计划会重新构建表上的每个索引，无论碎片化程度有多小。如果你使用了Always On功能，这将导致大量的流量。 自定义脚本可以根据你的阈值重新构建超过20%的任何内容。一次重建较少的索引。发送到辅助副本的Always On数据较少。由于重建的索引较少，所以重建速度更快。需要更短的维护窗口时间。 上次我使用维护计划时，我有一个拥有3亿行数据的表，每当进行索引重建时，Always On总是落后几个小时，并且事务日志溢出的问题。回到使用脚本后，所有问题都解决了。

- Alen

---

我最初在2007年左右为SQL 2005编写了自己的脚本。我以在线书籍为基础进行了一些修改。当时似乎大多数人都在使用计划，而现在情况似乎已经反转。在我开始做DBA之前，我之前的DBA为SQL 2000编写了自定义脚本。唯一不同的是我重新构建了所有东西。与重新组织相比，重建超过20%或30%的任何内容速度更快。至于备份，我们一直使用第三方产品。 - Alen

Answer 4

除了上述原因外，我最喜欢的理由是能够自动切换备份类型，这样新的数据库在日志备份作业运行时将会有一个完整的备份，而不需要等到下一次完整备份作业运行。

- SQLDBAWithABeard

Answer 5

大多数情况下，维护计划就足够了。Ola Hallengren的脚本在大多数情况下也很好用。

在极少数情况下，你可能需要自己编写脚本。

正如Jyao所说，这取决于你最擅长使用哪种方法。如果你的同事最擅长使用维护计划，为什么要让自己陷入困境呢？

如果他已经从事数据库工作20多年了，那么他肯定已经编写了自己的维护脚本。在你学开车的时候，可能有一些穿着货物短裤和人字拖的年轻小子出现了，他们说：“嘿，老家伙，维护计划更好——还有，拉下你的裤子，你看起来很荒谬！”

然后可能会有一个为期4年的战斗，在这场战斗中，这个傲慢的年轻人会尽可能地插入维护计划。现在，另一个穿着紧身牛仔裤和领结的年轻小子告诉他回到脚本上。这足以让你的头发变灰。

有三件事需要考虑：

这些Hallengrenite优越性的例子是否适用于你的环境？

如果他使用维护计划，这会给你带来实际问题吗？

如果你说服他使用Hallengren的脚本，出现问题时他能自己解决还是需要打电话给你？

- James

---

回答前两个问题是的。我们已经遇到了维护计划的问题，并且我通过Ola的解决方案解决了这些问题。生产服务器上还有一个收缩日志任务，我立即将其禁用。至于第三个问题，我不知道。我不确定他是否能够解决维护计划本身造成的问题。当我问他，如果我们遇到了问题，应该怎么办？他的回答是打电话给微软支持。 - Pat

@Pat，啊，听起来他已经达到了彼得原理的极限。小心试图让他变得更好 - 他可能不会欣赏你的帮助。 - James