Ola的脚本与使用维护计划的利弊是什么？

您能否帮助我了解在维护计划中使用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/

我已经写在这里

维护计划还不错，但是当您的环境不断发展时，维护计划所提供的有限的灵活性和功能性将绰绰有余。

要添加更多，

• Ola的维护解决方案已被社区和大型组织广泛接受。
• 它的开源和问题可以在github / issues上提出，有可能非常快地修复它。
• 它的灵活性和可扩展性（即使您要将其部署到100台服务器中，也只需使用dbatools的Install- DbaMaintenanceSolution。）
• 微软花了将近十年的时间来修复维护计划GUI，而该GUI本身是错误的：-)
• 具有广泛的文档和常见问题解答，并且会不断更新以适应较新的sql服务器版本。
• 在预览版中，您甚至可以并行运行备份。
• 对于索引维护解决方案，您甚至可以对进程计时，例如，如果进程运行的时间超过X倍，则中止该进程。

基于脚本的解决方案的主要优点之一是易于部署-如果您拥有150台以上的服务器，那么这显然与您的情况相关。试图在150台服务器上推出多个维护计划（即至少2个维护计划，一个用于系统数据库，一个用于用户数据库）是一个噩梦。一旦将它们维护到位就很麻烦。

随着时间的推移，基于脚本的解决方案更容易部署和维护。Ola的脚本相当全面，可以满足大多数需求。对于任何组织而言，它们都是一个很好的起点，然后可以进行调整以满足自己的独特需求。

在我们的示例中，我们在DEV环境中大约有40个SQL实例，并且我们使用带有SSMS多重连接功能的经过修改的Ola脚本，从而能够一键将所有40个实例的更改部署到维护策略上。任何特殊情况均由我们的修改处理。

我不确定他的脚本是否100％可靠，但是自定义脚本比维护计划要好得多。内置计划将重建表上的每个索引，而不管碎片多少。如果您始终处于开启状态，则会造成大量流量。

自定义脚本可以重建超过20％或阈值的任何内容。一次重建的索引较少。更少的Always On数据发送给次级。由于重建的索引较少，因此重建速度更快。需要更短的维护时间。

上次使用维护计划时，我有一个3亿行表，并且每当索引重建开始且事务日志溢出问题时，Always On都会落后数小时。回到脚本，一切都消失了。

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

维护计划在大多数情况下都很好。Ola Hallengren的脚本在大多数情况下都能正常运行。

在极少数情况下，您可能必须自己成长。

正如Jyao所说，这取决于您最适合的工作方式。如果您的同事对维护计划最满意，为什么还要扭动您的短裤？

如果他已经使用数据库20多年，那么他已经编写了自己的维护脚本。就在您学习驾驶的那一刻，可能出现了一些穿着短裤和人字拖的年轻朋克，就像“嘿，您那老货，维护计划更好-放下裤子，看起来很可笑！ ”。

然后可能是一场为期4年的战斗，这名可怜的年轻人在任何可能的时候都参加了维护计划。现在，这另一个年轻的朋克搭配着紧身牛仔裤和一条freakin领结，正告诉他重新写剧本。足以使头发变灰。

要考虑的三件事：

这些Hallengrenite优势的例子是否真的适用于您的环境？

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

如果您说服他使用Hallengren的脚本，并且有问题，他将能够自己解决该问题，还是必须给您打电话？