I find the -tablerangesize and -indexrangesize startup params to be very useful in locating application hotspots and indexing mistakes, so I put them on any production database I touch if they're not already there. The shared memory cost of doing so is pretty small.
It's a good idea to leave a little room for growth, i.e. set them higher than the actual table/index counts, so you don't have to keep updating them as you do schema changes (if you add tables or indexes often). Also remember to set the index count to at least (app. index count + 7), as the first seven indexes in the database belong to the meta-schema.
In the meantime, you could still check the stats and see if any numbers for creates are very high. Without -tablerangesize or -indexrangesize specified you still get stats for your first 50 tables and indexes, so you might get lucky.
And back to RHD's suggestion, until you get those startup params back on and restart your best bet is to run a couple of proutil tabanalys reports, say a day or two apart if you think that will reflect meaningful growth, and crunch the numbers in Excel to find which tables are growing. Since you know which area it is, you don't have to run the report for the whole DB; you can run it for that one area:
Code:
proutil [I]dbname[/I] -C tabanalys area [I]"area name"[/I] > [I]output_file.txt[/I]