Ola Index and Update stats

Depending on your version of SQL Server, maintenance plans reorganize or rebuild all of the indexes (I believe that starting w/ 2016 you can set thresholds to only process indexes with a certain level of fragmentation).

So, with Ola's scripts, you've got indexes that aren't badly fragmented enough to be rebuilt. While Ola's scripts allow you to update all statistics (depending the parameters you provide), the job may be finishing up faster than it did in the past. Therefore, some other job that makes many changes may not be done at the point when the statistics are being updated, causing enough changes to throw off the validity of the statistics.

(Aside - you noted that you were using @OnlyModifiedStatistics = 'Y'; you might see what happens if you change that to 'N', just as an experiment.)

Alternately, if (for example) you've limited the set of indexes to be considered, Ola's script will put the same limits on the statistics to be updated.

You can set up a job to update statistics using either T-SQL or maintenance plans. That could be run more often than the rebuild job.

UPDATE: I had originally presumed that Ola's script would only update statistics for indexes it had rebuilt/reorganized; it does not look like that's the case. Pulled in info I'd added to the comments.

The suggestion remains the same: have a separate job to update statistics, and run that during the week (daily, if you want to and the job doesn't take too long), and complaints should go down.

For multi terabyte databases with big indices, many partitions, and a small interval of schedule times I observed that the script always tends to rebuild same indices and never finishes.

This is very common for VLDBs. You can be a bit smatter and follow Paul Randal's Quick list of VLDB maintenance best practices. You can rebuild indexes ONLINE in Enterprise edition.

In your case since you are using Ola's Index Optimization scripts, you are running into endless index defragmentation which you can solve by being analyzing CommandLog table

I have given few more thoughts on Is a weekly rebuild of indexes a good idea? covering maxdop option.

I would say, if your databases are extremely big (TB size), atleast do a reorg instead of rebuild and manually update stats. This will put you in a good reasonable state since a reorg will start from where it got killed.

For running in parallel threads, you can drive of commandLog table and use powershell runspace (be careful of not spawing many threads - see Notes on usage of using runspace).