I’ve read some plausible explanations for why a DB2 runstats isn’t absolutely necessary following a reorg, but I’m not convinced.  Nearly all agree that runstats before (or as part of) a reorgchk is often wise, but some say it isn’t necessary after the reorg itself.  Sometimes the “evidence” centers around static tables that weren’t terribly fragmented in the first place, or even things like MDCs where reorgs aren’t needed anyway.

A call came in early this morning from a customer who had reorg’ed some very large tables over the long weekend but did not update statistics afterward.  They were greeted after the holiday with hung SQLs against one particular table, and had to page-awaken the DBA for authorized access.  In this case, the problem was corruption, which affected runstats itself.  That’s a nice side benefit: if a reorg resulted in index or table corruption, a good runstats (with distribution statistics) will often so fully cover the table that it’ll flush it out.  Runstats during the weekend maintenance would have identified the problem early and avoided production impacts later.

Runstats is usually so quick and easy that I come down on the side of pragmatism.  Who cares if theoretically it might not be necessary?  Do it for your health.  Or at least for a few extra hours sleep.