Re: Force Statistics Collection DB2/400?

Ryan Hunt wrote:

We are working on a new JDE install and the process involves a
lot of copying our main business data libraries from a prod LPAR
to a test LPAR, running conversion scripts, and engaging in CRP
testing. One thing I've noticed is that the QDBFSTCCOL job
generates a lot of activity once users get onto the system and
try to use it. I think this probably makes sense, maybe the stats
get abondoned during a RSTLIB on a library from a foreign
system...or maybe it's the conversion scripts. Either way, the
system behaves like there are next to no stats once the queries
start coming in.

Anyway, I'm curious if there is a way to force statistics collections on large business data libraries after the RSTLIB,
data conversion activies, etc.

Is the saved-from system running with no statistics collection and the restored-to system running with system-defined statistics collection? Or maybe *SYSTEM on save-from versus *ALL on restore-to? Also be sure access paths are being saved\restored. If the ACCPTH(*YES) is specified on the save but CPF3145 messages are logged to QHST after the restore [after some busy IDX activity in the runpty-52 QDBSRV## jobs], then some access paths were not being saved\restored as expected for some [possibly valid non-defect] reason.

The restored files can have their statistics updated by API invocations, to be enqueued or performed synchronous within the requesting job. The requests could be submitted after the restore, and before the query activity starts.

However AFaIK, the index & column statistics should be saved\restored [with the access paths for the index, and with the member for the columns], so given like-settings for QDBFSTCCOL across the systems, there should not be much requirement for QDBFSTCCOL to run to gather statistics over the restored database *FILE objects.

Regards, Chuck