If you have ProTop you can run the control-r reports. (Make sure that fresh dbanalys data is available first.) This will create $PROTOP/rpt/dbname.rmchain.rpt that might look something like this:
Code:
RM Chain Summary for tpl /db/tpl/tpl
Table Name Size (bytes) Num Recs RM Chain Avg Row RPB xRPB Frag% Ideal Blks RM:Blk Create Toss xToss
-------------------- ----------- ------------ ------------ ------- --- ---- ------- ---------- --------- ------- ------ ------
ws-inbound-log 1610612736 1521491 200890 1059 16 8 0.47% 196608 1.02 150 300 1164
ar-trans-d 50017075 146652 2247 341 32 32 0.00% 6106 0.37 150 300 375
wb_funct-log 219886387 1543729 606 142 16 64 0.00% 26842 0.02 150 300 157
po-trans-d-prod 225758413 2227660 575 101 64 128 0.00% 27559 0.02 150 300 111
wm-location 170 2 508 85 64 128 0.00% 1 508.00 150 300 94
s_port 69 1 508 69 64 128 0.00% 1 508.00 150 300 76
loc-group 60 1 508 60 64 128 0.00% 1 508.00 150 300 66
s_field-lang 308 4 508 77 64 128 0.00% 1 508.00 150 300 85
. . .
"RPB" is your actual rows per block. "xRPB" is what ProTop thinks you _should_ be using.
"Ideal Blocks" is the number of blocks that you could have packed this data into if everything were well organized.
RM:Blk is the ratio of RM Chain blocks to that ideal size mentioned above.
"Create" and "Toss" are the current values of the create and toss limits.
"xToss" is a suggested possible alternative Toss limit based on making it 110% the size of the average row.
In the example above ws-inbound-log has a very high number of blocks on the RM Chain. The current rows per block is too large so the first thing to do would be to change it to 8. To do that you will need to dump and load that table which is also the only supported way to zero out the RM Chain. The suggested value for the Toss limit is quite different from the default and the usage of this table has clearly been causing the RM chain to grow very large so I would change that.
The rest of the tables I probably wouldn't worry about from a Toss Limit perspective.