Updating partition key column
If the new key indicates that the row should exist in another partition, DB2 will move it for you. If you mean will the statistics be updated simply because a row was moved to another partition, the answer is "no". This may or may not matter, especially if you are frequently updating they keys-what matters is the current distribution among the partitions.When the row distribution gets out of balance, meaning the rows are not more or less evenly distributed among the partitions (for very large tables), that is when you need to to redistribute the partitions.By creating a partition key that is flexible (via an algorithm) we can adjust performance for particular clients, without redefining partition ranges. it is recommended to run runstats regulary in order to keep the statistics updated, but you should consider the beneift when doing so.if you only move 5% of the rows from one partition to another partition, then maybe you should not run runstats, especially if your partitions are very big, and runstats will consume alote of resources.
instead if you rebalance using the reorg utility, it would go faster, you would be able to recluster the data, reallocate the free space, and run runstats while running reorg.All this is possible, but it begs the question of why would you choose a column as the partitioning key if you know in advance that you are going to frequently update it?Not only will this create loads of additional work for you, but from a design point of view its a poor choice.In OLTP systems, you also tend to partition by date the most (probably not in the PK), but potentially also regionally or by some kind of organizational division (maybe in the PK if you aren't using a surrogate). It has to be part of a Candidate Key if not part of the Primary key itself.
Idea being, your partitioning should align itself with the primary key.
Does a row move to another table, or is row movement constrained to the row's container (i.e., a table)?