Re: Force Statistics Collection DB2/400?

[CRPence <CRPbottle@xxxxxxxxx>]

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