Ola Hallengren IndexOptimmize is running and completes without failure -- but is not doing anything. No actions are performed. #937
Unanswered
lewisrl3273
asked this question in
Questions & Answers
Replies: 1 comment 1 reply
-
Have you checked the log file of the index maintenance job? It will show what was actually ran on the SQL instance. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
The IndexOptimize job IS running every day for 4-5 hours or more, but no actions are being performed and nothing is being done.
SQL Server is v2019 CU30. Ola Hallengren product version is 2025-04-26. The nightly maintenance has been running long for a particular customer, so I logged in to review the CommandLog table and identify where the time was being spent. Unexpectedly, I found that there hadn't been any index-related commands recorded in the CommandLog table since 6/22. The IndexOptimize job IS running every day for 4-5 hours or more, but nothing is being recorded. @LogToTable is set properly and the commands are going in for the backups and checkdb, but nothing is being recorded for indexes. I've checked everything and I cannot find an explanation. These are my observations:
IndexOptimize runs daily for 4–6 hours
Long runtime suggests it’s spending time on internal object discovery, not actual work
No index/stats entries logged since 6/22
Strong indicator that execution never reaches ALTER INDEX or UPDATE STATISTICS commands for user objects
CommandLog contains backup and checkdb entries
Confirms shared logging mechanism is intact, not permissions-related
Fragmentation is high (60–99%) across many large indexes
Suggests no recent ALTER INDEX activity is occurring despite job duration
Statistics are not being updated
Affirms that nothing is being done while the task is running
sys.dm_db_index_physical_stats shows many pages
Indicates fragmentation thresholds and page counts are met for processing — so indexes should qualify
Execution for dbo.IndexOptimize with @objects = 'CommandLog' works instantly
Confirms procedure is not broken, but scope on large DBs is overwhelming object discovery step
I run sp_whoisactive while it is running and only see the metadata SELECT. It is never performing any update statistics or alter index statements.
To recap, the job is running every day with the normal job definition that is in place on countless other instances and running effectively -- yet in this instance, nothing is being done. It is not failing. It simply isn't doing anything. The job log for a full call is below. You can see it is looking at each database, but doing nothing.
The only other thing that could be relevant is that I did a full index rebuild and update stats w/full scan on the database in question on 5/13/2025. I don't know if that is a factor but it is the only other variable that I have. The index maintenance has been in place for years, was running fine until 6/22, after which it continued running but was no longer performing any actions while doing so. The job run for hours and complete without error (see log pasted below), but nothing is being done.
Does anyone have any ideas?
-- IndexOptimize job log
Job 'DBA_IndexOptimize - USER_DATABASES' : Step 1, 'IndexOptimize - USER_DATABASES' : Began Executing 2025-07-15 18:15:00
Date and time: 2025-07-15 18:15:00 [SQLSTATE 01000]
Server: servername [SQLSTATE 01000]
Version: 15.0.4415.2 [SQLSTATE 01000]
Edition: Enterprise Edition: Core-based Licensing (64-bit) [SQLSTATE 01000]
Platform: Windows [SQLSTATE 01000]
Procedure: [DBA].[dbo].[IndexOptimize] [SQLSTATE 01000]
Parameters: @databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE, INDEX_REBUILD_ONLINE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE', @FragmentationLevel1 = 5, @FragmentationLevel2 = 30, @MinNumberOfPages = 300, @MaxNumberOfPages = NULL, @SortInTempdb = 'N', @MaxDOP = NULL, @FillFactor = NULL, @PadIndex = NULL, @LOBCompaction = 'Y', @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @StatisticsModificationLevel = NULL, @StatisticsSample = NULL, @StatisticsResample = 'N', @PartitionLevel = 'Y', @MSShippedObjects = 'N', @indexes = NULL, @Timelimit = 18000, @delay = NULL, @WaitAtLowPriorityMaxDuration = NULL, @WaitAtLowPriorityAbortAfterWait = NULL, @Resumable = 'N', @AvailabilityGroups = NULL, @LockTimeout = NULL, @LockMessageSeverity = 16, @StringDelimiter = ',', @DatabaseOrder = NULL, @DatabasesInParallel = 'N', @ExecuteAsUser = NULL, @LogToTable = 'Y', @execute = 'Y' [SQLSTATE 01000]
Version: 2025-04-26 17:20:34 [SQLSTATE 01000]
Source: https://ola.hallengren.com [SQLSTATE 01000]
[SQLSTATE 01000]
Date and time: 2025-07-15 18:15:00 [SQLSTATE 01000]
Database: [DBName] [SQLSTATE 01000]
State: ONLINE [SQLSTATE 01000]
Standby: No [SQLSTATE 01000]
Updateability: READ_WRITE [SQLSTATE 01000]
User access: MULTI_USER [SQLSTATE 01000]
Recovery model: SIMPLE [SQLSTATE 01000]
[SQLSTATE 01000]
Date and time: 2025-07-15 23:59:54 [SQLSTATE 01000]
Database: [DBA] [SQLSTATE 01000]
State: ONLINE [SQLSTATE 01000]
Standby: No [SQLSTATE 01000]
Updateability: READ_WRITE [SQLSTATE 01000]
User access: MULTI_USER [SQLSTATE 01000]
Recovery model: SIMPLE [SQLSTATE 01000]
[SQLSTATE 01000]
Date and time: 2025-07-15 23:59:54 [SQLSTATE 01000]
Database: [OLTPIMTDEV] [SQLSTATE 01000]
State: ONLINE [SQLSTATE 01000]
Standby: No [SQLSTATE 01000]
Updateability: READ_WRITE [SQLSTATE 01000]
User access: MULTI_USER [SQLSTATE 01000]
Recovery model: SIMPLE [SQLSTATE 01000]
[SQLSTATE 01000]
Date and time: 2025-07-15 23:59:54 [SQLSTATE 01000]
[SQLSTATE 01000]
Job 'DBA_IndexOptimize - USER_DATABASES' : Step 2, 'SendNotification - Complete' : Began Executing 2025-07-15 23:59:54
Mail (Id: 13651) queued. [SQLSTATE 01000]
Beta Was this translation helpful? Give feedback.
All reactions