Why am I seeing pause in auto-runstats execution?

Body

Lets talk about this strange behavior :
"Even that the online maintenance window has been enlarged to 12 hours we can see that Auto-runstats pauses for 2 hours although not all objects (the stats-views ) have been runstats'ed."

Auto-runstats is invoked by health monitor on a fixed timer, each timer 7500 seconds apart. auto-runstats consists of "iterations". In each iteration, we evaluate tables/views one by one, if a table is deemed needing stats, we will issue runstats and wait for the runstats to finish before we evaluate the next table. After we complete evaluating and potentially runstats on a table, we check how much time is left until the next timer (in other words, how much time is left in the current 7500 seconds interval). If there is less than 5 mins left. we stop this iteration. Then at the next timer health monitor will invoke auto-runstats, and auto-runstats will start another iteration.

If when we check the time, we already pass the next timer (i.e. time-left is negative), we'll realize that we've used up the 7500 seconds, and we'll end the iteration. But the problem is that we've missed the timer and we will have to wait for the next one. That is why the user observed the "pause". This (the fixed timer) is a limitation of the health monitor infrastructure. This behavior is working as design.

Someone might be curious to know - Is there any way to tell health monitor that "invoke me again immediately and don't wait for the next timer because I didn't finish my job in my last iteration"?

> There is nothing like this available right now in the infrastructure. If you add this, think about cases where there are multiple databases.
There is a maximum number of connections that any single client process can spawn and the db2acd process is instance-wide so you need to be careful not to starve other databases as well.