我下载了Ola Hallengren的脚本并部署到主数据库中。我用下面的..。
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我在SSMS中得到了这个输出,但是索引还没有被重建。碎裂程度仍然很高。我是不是遗漏了什么?
Date and time: 2015-03-01 14:07:24
Server: TestSvr
Version: 10.50.2500.0
Edition: Standard Edition (64-bit)
Procedure: [master].[dbo].[IndexOptimize]
Parameters: @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,
@PageCountLevel = 1000, @SortInTempdb = 'N',
@MaxDOP = NULL, @FillFactor = NULL, @PadIndex = NULL,
@LOBCompaction = 'Y', @UpdateStatistics = NULL,
@OnlyModifiedStatistics = 'N', @StatisticsSample = NULL,
@StatisticsResample = 'N', @PartitionLevel = 'Y',
@MSShippedObjects = 'N',
@Indexes = NULL, @TimeLimit = NULL, @Delay = NULL,
@WaitAtLowPriorityMaxDuration = NULL,
@WaitAtLowPriorityAbortAfterWait = NULL, @LockTimeout = NULL,
@LogToTable = 'N', @Execute = 'Y'
Source: https://ola.hallengren.com
Date and time: 2015-03-01 14:07:24
Database: [TestData]
Status: ONLINE
Standby: No
Updateability: READ_WRITE
User access: MULTI_USER
Is accessible: Yes
Recovery model: SIMPLE
发布于 2015-03-01 20:45:10
您的索引只有679页。Ola的解决方案被设置为忽略不足1000页的索引(请参见@PageCountLevel参数)。您可以覆盖它,这样它就会关心不到1000页的索引,但是为什么呢?浪费精力IMHO。
我将不再担心这样的小表--让Ola的解决方案完成它的工作,当您能够实际证明它正在对特定的索引造成明显的性能问题时,就会担心它的碎片。“碎片化程度高”本身并不是一个问题。
https://dba.stackexchange.com/questions/94110
复制相似问题