RUNSTATS frequency for high-insert tables - metric guidance

Dear colleagues,

Our warehouse fact table receives approximately four million inserts per day. Current RUNSTATS executes weekly via a scheduled utility job. We are observing suboptimal access paths on queries filtering by BUSINESS_DATE after the third day post-RUNSTATS.

Sample utility control card:

jcl
//STEP1 EXEC PGM=DSNUTILB,REGION=0M
//STEPLIB DD DSN=DB2.RUNLIB.LOAD,DISP=SHR
//SYSIN DD *
  RUNSTATS TABLESPACE DSNDB04.FACTTS
            TABLE(WAREHOUSE.SALES_FACT)
            SHRLEVEL CHANGE
            UPDATE ALL
/*

IBM documentation notes:

SHRLEVEL CHANGE allows concurrent DML during RUNSTATS but may produce statistics that reflect an intermediate state.

Regards,
Elena

We monitor NPAGESF drift and insert volume since last RUNSTATS. When inserts exceed twenty percent of table cardinality, a trigger job queues RUNSTATS for that tablespace overnight.

Real-time statistics helped on two pilot tables but licensing and overhead must be justified per object.

Thank you. Would you share whether you use RTS on the insert-heavy tables only, or broadly across the subsystem?

Insert-heavy and tables with volatile distribution on leading index columns only. Static reference tables remain on weekly batch RUNSTATS.