Have you ventured into turning on history table for your RTS?
If so have you looked at the contents of your history tables?
Your history table can accumulate a lot of data quickly depending on your stats interval setting (STATSINT); default being 20 mins.
So setting this interval to a bit less frequent will help, so this is in your control.
What is not in your control is the utilities and these can force many updates for the same instance of the object.
There is a link to the doco which talks about getting multiple rows in history for a single update to the RTS on "rare" occasions. I dont think this is so rare.
https://www.ibm.com/docs/en/db2-for-zos/13.0.0?topic=tables-temporal-versioning-db2-statistics-related-catalog
Have a look at this scenario:
- Reorg shrlevel change IC tape
- a failed image copy to tape
- successful image copy to tape
- a reorg shrelvel change to tape
Our results but can vary from every interaction as you can see here for copy: This is the output from the following temporal query
SELECT UPDATESTATSTIME,SYS_START,SYS_END,PARTITION
FROM SYSIBM.SYSTABLESPACESTATS
FOR SYSTEM_TIME FROM '2026-01-23-00.00.00.000000000000'
TO CURRENT TIMESTAMP
WHERE NAME='ATABLESP'
ORDER BY SYS_START, PARTITION DESC
UPDATESTATSTIME SYS_START SYS_END
* * *
-------------------------- -------------------------------- -----------------
2026-01-23-01.20.13.533411 2026-01-23-01.20.07.292609847002 2026-01-23-09.58. < reorg
2026-01-23-09.58.10.077604 2026-01-23-09.58.10.079867326002 2026-01-23-09.58.
2026-01-23-09.58.10.151688 2026-01-23-09.58.10.152486958002 2026-01-23-09.58.
2026-01-23-09.58.12.501062 2026-01-23-09.58.12.501831762002 2026-01-23-10.53. < copy failed
2026-01-23-10.53.33.341439 2026-01-23-10.53.33.341805129002 2026-01-23-10.53.
2026-01-23-10.53.33.350120 2026-01-23-10.53.33.350654448001 2026-01-23-10.53.
2026-01-23-10.53.33.398480 2026-01-23-10.53.33.399001376001 2026-01-23-10.54. < copy tape
2026-01-23-10.54.03.443227 2026-01-23-10.54.03.443440027001 2026-01-23-10.54.
2026-01-23-10.54.03.448374 2026-01-23-10.54.03.448546380001 2026-01-23-10.54.
2026-01-23-10.54.03.451820 2026-01-23-10.54.03.452339727002 2026-01-23-10.54.
2026-01-23-10.54.03.498052 2026-01-23-10.54.03.498242125001 2026-01-23-10.54.
2026-01-23-10.54.03.503492 2026-01-23-10.54.03.504005875002 2026-01-23-10.54.
2026-01-23-10.54.04.167713 2026-01-23-10.54.04.168242271002 2026-01-23-11.10. < reorg
2026-01-23-11.10.44.567171 2026-01-23-11.10.44.567371524002 2026-01-23-11.10.
2026-01-23-11.10.44.572809 2026-01-23-11.10.44.573384228001 2026-01-23-11.10.
2026-01-23-11.10.44.601308 2026-01-23-11.10.44.601814151001 2026-01-23-11.10.
2026-01-23-11.10.46.850309 2026-01-23-11.10.46.850854723001 9999-12-30-00.00. < current row
------------------------------
CRAIG MCKELLAR
------------------------------