var*_*ble 2 sql-server maintenance ola-hallengren
我已经配置了 Ola Hallengren 的备份和完整性检查脚本。
但是，我想了解是否需要设置 SQL Server 索引和统计维护脚本，因为我的 SQL 服务器在 SAN 基础架构上运行，并且我读到将填充因子设置为小于 100% 没有任何好处，或者当数据文件位于 SAN 存储上时执行索引重组或索引重建。任何建议将被认真考虑。
统计信息维护是由 SQL Server 自动完成的，因此我看不出配置 Ola 脚本进行统计信息维护有任何好处。
请注意，SAN存储意味着涉及多个磁盘，数据（无论表是否有索引[堆]或聚集索引或非聚集索引）分散在多个磁盘上。
Ola 安装脚本创建的“索引优化”作业侧重于碎片整理，而不是统计更新。它将执行以下操作：
您可以通过重建获得新的统计数据，但不能通过重组获得。请注意，您可以对索引进行大量修改，而这些索引不会被碎片化，因此不会导致重建发生，从而使您获得过时的统计信息。
正如您可能知道的，我非常怀疑碎片整理的价值，我也在这里写过。
除了 Ola 的安装脚本创建的作业之外，我建议您再创建一项作业，并且该作业专注于更新统计信息。它可能如下所示：
EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = NULL,
@FragmentationHigh = NULL,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@LogToTable = 'Y'
确实，如果您的数据库架构正确，那么索引碎片基本上已成为过去的事情，这使得索引维护现在几乎没有意义，尤其是在现代硬件中。我见过的一个需要维护索引的例子是在第三方应用程序的数据库上，他们不相信聚集索引，因此他们所有的表都是堆，这些表会不断地出现超过 90% 的碎片并且性能很差。但这就是为什么我在第一句话中添加了免责声明“如果您的数据库架构正确”。（请注意，这当时可能位于机械存储上，这可能会更加暴露完全碎片堆的问题。）
统计维护是一个不同的目标，但在今天仍然具有现实意义。当 SQL 引擎选择执行计划来处理查询时，拥有最新的统计信息有助于更好地估计基数。由于执行计划中做出的许多不同的不正确决策，糟糕的基数估计（通常当它们偏离一个数量级或更多时）可能会导致性能非常差（无论您的服务器使用哪种硬件）。
例如，当引擎认为给定查询将返回的行数被低估时，它可能会请求处理该查询所需的内存量，这将使执行计划缺乏足够的资源来执行该查询。跑步。相反，过高的估计可能会导致向查询的执行计划过度配置资源，这也需要时间来分配，然后从服务器的其余部分占用这些资源。如果我没记错的话，单个查询最多可以占用实例分配内存的 25%。
基数估计不佳可能导致的另一种性能瓶颈是在所选执行计划中使用了不正确的操作，尤其是在将数据连接在一起时。例如，低估可能会导致选择 Nested Loops Join 运算符，因为它通常对于较小的数据集性能更高，但如果基数估计的话，在这种情况下 Hash 或 Merge Join 运算符实际上会性能更高是准确的。
统计数据并不是保证始终具有良好基数估计的全部目的，但它是可以帮助（或在表的统计数据过时时损害）这些估计的因素之一。更新统计数据的频率与数据的大小以及这些表更改的频率相关，这一点是关键。更新统计信息不是阻塞操作，但它可以利用大量的服务器资源来执行此操作。
关于 Ola Hallengren 的脚本，我不是专家，因为我个人还没有使用它们，但我的理解是它们提供了更好的粒度和可配置性，可以更适合您的用例安排维护。它们还应该比使用开箱即用的维护计划安排维护更可靠。由于这些原因，我相信它们是更受欢迎的维护选择。