Server索引与统计维护性能问题
我尝试在索引数量非常多(> 250.000)的数据库上使用IndexOptimize存储过程。存储过程收集需要处理的数据的初始步骤需要几个小时，即使我设置@Indexes参数以缩小工作范围。
Server维护解决方案版本: 2019-02-10 :40:47 Server 2017标准版，安装了最新的CU14。
在一个客户那里，我看到了一个具有> 500.000索引的数据库。12小时后，数据收集步骤仍在运行。
如果我将@ index设置为单个索引，则应该立即启动执行。
下面是我的存储过程调用的一个示例。
EXECUTE dbo.IndexOptimize
@Databases = 'db',
@Indexes = 'db.dbo.'
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 30,
@FragmentationLevel2 = 50,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@LogToTable = 'Y',
@LockTimeout = 60有人能和我分享他在一个索引数量很高的数据库中使用IndexOptimize的经验吗？
回答 1
Database Administration用户
发布于 2019-04-11 08:05:21
在不知道数据库大小的情况下，这是很难回答的，在此服务器上最后一次运行维护任务时，当前的索引碎片级别是多少。由于没有提供上述任何信息，我将尝试用通用术语回答。
由于您使用的是标准版，您将没有在线重建索引的选项。您可以尝试手动运行IndexOptimize过程，方法是传递几个表(使用逗号分隔)，并在非高峰时间内传递多个索引，并查看它是如何通过的。在上面的代码捕获中，选择的模式是dbo -意味着所有对象都将被包含，除非和直到您在db数据库上定义了多个模式。您还没有指定@pagecountlevel，它在根据表的大小选择表中起着很大的作用。万一你只想瞄准庞大的表，你应该把这个数字设置得相当高。
您可以在下面的文章中解释IndexOptimize过程的各种参数及其意义：
如果有大量的表作为堆，Ola的脚本将不会进行表重建。您可以参考下面的文章布伦特奥扎尔关于该脚本的各个方面。
更改默认值并根据此文章自定义它
- FragmentationLevel1 = 50%
- FragmentationLevel2 = 80%
- FragmentationMedium =‘INDEX_REORGANIZE，INDEX_REBUILD_ONLINE’
- FragmentationHigh =‘INDEX_REBUILD_ONLINE’
您还可以参考以下有关性能问题的详细信息的链接：
https://www.brentozar.com/archive/2017/12/index-maintenance-madness/
您可以使用他的脚本只更新统计信息，而不是进行索引重新组织/重建，如下所述：
https://www.sqlskills.com/blogs/erin/updating-statistics-with-ola-hallengrens-script/
如果上面有帮助，请告诉我们。
https://dba.stackexchange.com/questions/234520
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号